בעיית שעון בשרתי לינוקס

לאחרונה נתקלתי בבעיה עיקשת וקשה לפיתרון:
השעון של אחד השרתים שאני אחראי אליהם החליט שדיוק זה לא הקטע שלו, ונדד משהו כמו ארבע שעות בכל יום.
סינכרון NTP יומי גרם לקפיצת זמן של 4-5 שעות בכל פעם, וברור היה שצריך לפתור את הבעיה האמיתית.
החשוד המיידי בבעיות שעון בדרך כלל הוא הBIOS או הסוללה של הCMOS, והפתרון הכי זריז אם זו אכן הבעיה היא להעביר את הדיסק של השרת למכונה אחרת.
חברת ההוסטינג עשתה את זה, והתברר שזה לא פתר את הבעיה.
כדי לעשות דברים יותר מעניינים, אני אוסיף ואגיד שיש בחווה ארבעה שרתים, חלקם עם חומרה כמעט זהה לזו של השרת המאחר והם לא סבלו מהבעיה.
בנוסף, כל השרתים הריצו דביאן Etch עם קרנל 2.6.18 סטנדרטי של דביאן (שהיא הגרסא הרשמית של דביאן Etch), בהבדל אחד: המכונה המאחרת הריצה קרנל של 64 ביט.
לא משהו שאמור לגרום לכזו בעיה, אבל בכל זאת הבדל.
השוואה של קבצי הקונפיגורציה של הקרנלים (בדיביאן קרנלים סטנדרטיים מגיעים עם קובץ הקונפיגורציה שאיתו קומפל הקרנל והוא יושב בספריית /boot) הראתה הבדל מעניין בין הקרנל המאחר לבין אלו שלא:
הקרנל המאחר לא קומפל עם GENERIC_TIME, והאחרים כן.
עדיין לא מוכיח כלום, אבל מעניין.
מסתבר שבלינוקס יש כמה מקורות לעדכון השעון הפנימי, חלקם מדוייקים יותר, חלקם מדוייקים הרבה פחות.
המקורות של הקרנל שרץ כרגע זמינים בקובץ
[code]
/sys/devices/system/clocksource/clocksource0/available_clocksource
[/code]
במכונה המאחרת היה זמין רק מקור אחד עם שם מוזר: jiffies
שהוא גם המקור הכי לא מדוייק שיש (למעשה הקרנל מעדכן איזה משתנה פנימי בקצב שאמור להיות תואם את המציאות, מה שלא ממש עובד)

במכונות האחרות היו זמינים כמה מקורות: acpi_pm jiffies tsc pit

ברגע שעידכנתי את הקרנלים בכל המכונות לגרסא 2.6.26, הבעיה נפתרה ולכל השרתים היו את אותם מקורות שעון.

בוקסי

בוקסי היא מערכת מדיה סנטר שמבוססת על המערכת פתוחת הקוד xbmc ומפותחת על ידי.. בוקסי, סטארטאפ ישראלי.
כיאה למערכת שמבוססת על מערכת אחרת בקוד פתוח, בוקסי בעצמה היא פתוחת קוד ומשוחררת ברשיון GPL ותחת עוד כמה רשיונות קוד פתוח (למרות שלא הצלחתי למצוא אישוש להנחה הזו בשום מקום).
בנוסף, הצוות של בוקסי משחרר קוד כל הזמן לפרוייקט XBMC, למשל את הפורטים ללינוקס ואולי גם לMac הם תרמו חזרה לפרוייקט. (תרומה משמעותית במיוחד).

בוקסי נמצאת בשלב האלפא, מה שאומר שיש באגים ויש בעיות שמישות.
מצד שני, בוקסי נמצאת בפיתוח מהיר ומתמיד, ורואים שיפורים מגרסא לגרסא.

אחד הדברים הבולטים שמבדילים את בוקסי ממערכות מדיה סנטר אחרות הוא שבוקסי היא מערכת מדיה סנטר חברתית, שמאפשרת לכם לדעת במה החברים שלכם צופים, וכן להמליץ ולקבל המלצות מהחברים.
למי שמודאג מהפרטיות, אפשר להגדיר דרך האתר שבוקסי תחלוק מידע עם כל העולם, רק עם חברים או עם אף אחד.
בוקסי תומכת בהזרמת וידאו ממגוון שרותים כולל hulu, קומדי סנטרל ועוד.
Hulu חסום למי שאינו תושב ארצות הברית, אבל ניתן לקוות שבשלב מסויים תהיה לו חלופה שעובדת בארץ (קשה לי להאמין שהולו "ישדרו" אל מחוץ לארצות הברית).
אחד הדברים הנחמדים הוא שבוקסי מאפשרת צפייה בטריילרים של סרטים, אפילו של סרטים שיש לכם (יכול לעזור להחליט באיזה סרט בא לכם לצפות עכשיו).

המערכת פשוט יפהפיה, והממשק נוח מאוד ברובו ומתאים לשלט, למקלדת ולעכבר.
בזמן ניגון סרט, תוכלו לנווט בתפריטים כאשר הסרט ממשיך לנגן מתחת לתפריטים החצי שקופים. ממש איכות חיים.

המסך הראשי של בוקסי מחולק לארבעה חלקים:
* המלצות חברים, שמכיל המלצות אחרונות של חברים שלכם.
* פעילות חברים אחרונה, שמכיל את הדברים האחרונים שראו או שמעו החברים שלכם
* קבצים שנוספו לאחרונה לאוסף שלכם
* דברים שעשיתם לאחרונה – מה ראיתם או שמעתם.
חוץ מזה, יש בצד שמאל של המסך תפריט נסתר שמאפשר עייון באוסף שלכם, צפיה בוידאו מוזרם מאתרים (כן, גם מיוטיוב – הידד!), הגדרות של בוקסי ועוד.

בוקסי כוללת גם לקוח ביט טורנט מובנה, שמאפשר להוריד תוכן חוקי למהדרין.
ניתן להוסיף פיד רסס מכל מקום אחר, והמבין יבין.
השילוב עם לקוח הביט טורנט עדיין בסיסי ויש עוד מה לשפר, אבל זו התחלה טובה.

הדבר הראשון שבוקסי עושה אחרי שמפעילים אותה ומוסיפים כמה מקורות וידאו ומוסיקה (במילים אחרות, מספרים לבוקסי איפה ספריית המדיה שלכם) זה לסרוק את הספריה, ולאסוף עליה מידע דרך מגוון שרותים באינטרנט.
בוקסי תשיג את הארטוורק של עטיפות הסידים של המוסיקה שלכם, את ה"פוסטרים" של הסרטים והסדרות, ובמקרה והיא לא הצליחה למצוא היא פשוט תציג תמונה מתוך קובץ הווידאו במקרה של וידאו.
חוץ מגרפיקות, בוקסי גם תביא תקצירים של סרטים וסדרות, אפילו ברמת הפרק הבודד (!).
לפעמים בוקסי לא מצליחה לזהות, או אפילו טועה בזיהוי. במקרים האלו תוכלו לעזור לה ולתקן אותה.

בזמן ניגון סרט, בוקסי מאפשרת חיפוש כתוביות אוטומטית לפי הסרט או הסדרה או לפי שם הקובץ במידה והקובץ לא מזוהה.
החוויה ממש מרעננת, במקום ללכת למחשב ולהתחיל לחפש תרגום מתאים, אפשר לעשות את זה מהסלון עם השלט ישר מתוך בוקסי, ולהתחיל להשתמש בתרגום לסרט בזמן שהסרט רץ, בלי להחסיר פריים.

עוד תכונה מרעננת, במיוחד למורידי הסדרות הסדרתיים – היא היכולת לנגן סרט ישירות מתוך קובץ הRAR, אפילו אם מדובר בRAR עם כמה קבצים.
בוקסי מתחילה לנגן מיד, בלי לחכות שהקובץ יפרש (במילים אחרות, בוקסי עושה הזרמת וידאו ישר מתוך הRAR).
לא הבחנתי בירידת ביצועים בזמן הצפיה בסרט מתוך RAR.
הבעיה עם זה שנכון לכרגע בוקסי לא מזהה ולא מאפשרת לעזור לה לזהות קבצים בתוך RAR, אבל אני בטוח שהחברה הטובים בבוקסי יפתרו את הבעיה הזו.

נכון לכרגע, בוקסי תומכת רשמית בMac, בAppleTV ובאובונטו לינוקס, אבל החל מהגרסא האחרונה ששוחררה היא גם עובדת על דביאן לני.
צפויה גם גרסאת חלונות בעוד כמה חודשים.

בוקסי לא חפה מבעיות, אבל היא אלפא ולכן אפשר לסלוח.
חלק קטן מהבאגים שנתקלתי בהם:
* תרגומים בעברית מוצגים כג'יבריש, כנראה חסר פונט.
* המערכת די יציבה, אבל יש קריסות עקביות אצלי בניגון קבצי מוסיקה, וכן קריסות אקראיות בסיטואציות מסויימות שטרם הצלחתי לאפיין.

כאמור, המערכת באלפא וכדי לנסות אותה צריך הזמנה.
מי שרוצה הזמנה שיבקש, אני אנסה לשלוח (אני לא יודע אם יש הגבלה על מספר ההזמנות שאני יכול להוציא).

הנה סירטון קצר שמדגים את יכולות המערכת:

quick intro to boxee from boxee on Vimeo.

אם לסכם,
אני מת על המערכת הזו, שידרוג אסטרונומי מfreevo בו השתמשתי עד עכשיו.
מומלץ בחום.

שדרוג דביאן Etch לLenny

שדרגתי את השרת שמפעיל את הבלוג הזה ואת האתר של פיירסטטס מדביאן Etch לדביאן Lenny.
הסיבה היא שקצתי בחבילות ישנות, ספציפית יש לי בעיה באתר של פיירסטטס (שרץ על trac) שמאוד יכול להיות שנובעת מגרסא ישנה של python ו/או גרסא ישנה של sqlite.

בכל אופן, השדרוג לא היה חלק במיוחד, אבל נראה שהוא הסתיים בהצלחה.
באופן רגיל, שדרוג של הפצת דביאן מתבצע כך:
משנים את /etc/apt/sources.list ומחליפים כל אזכור של etch בlenny.
מבצעים apt-get update
מבצעים apt-get dist-upgrade
ומקווים לטוב.

במקרה שלי, הוספתי שני שלבים נוספים:
אני משתמש בסקריפט בשם ipkungfu שאחראי להגדיר את הפיירוואל של השרת. הממשק שלו הרבה יותר ידידותי מזה של iptables (והוא בסך הכל מעטפת שדואגת שאני לא אצטרך להשתמש בiptables ישירות).
מכיוון שאני יודע שהיה שינוי בתחביר מהגרסא הישנה שבEtch לגרסא שבLenny, דאגתי לכבות את הפיירוואל לפני העדכון כדי לא לנעול את עצמי מחוץ למערכת בטעות.
לא בטוח שזה מה שהיה קורה, אבל עדיף להיות בטוח.

כדי לצמצם את הזמן שהאתר היה למטה, הורדתי מבעוד מועד את כל החבילות על ידי הרצת:
apt-get dist-upgrade –download-only
שמוריד את מה שצריך אבל לא מתקין.

אחרי ההכנות האלו, הרצתי dist-upgdade רגיל בתקוה שההרפתקאה לא תהפוך לסופת חרא.
אחרי השדרוג, הבעיה הראשונה שהבחנתי בה היתה שהאפאצ'י מתלונן על זה:
[code]
apache2[Fri Oct 24 19:09:36 2008] [warn] NameVirtualHost *:80 has no VirtualHosts
[/code]
מסתבר שהחברים בדביאן החליטו להוסיף את ההצהרה על שימוש בהוסטים וירטואליים לקובץ הports.conf, מה שאמר שהיו שתי הצהרות כאלו.
הודעת השגיאה הסתומה שקיבלתי היא התוצאה.
הסרתי את ההגדרה שלי והבעיה נעלמה.

בעיה נוספת היא שtrac הפסיק לעבוד.
האמת היא שמכיוון שלא התקנתי את trac דרך apt-get הייתי מופתע אם הוא ההיה ממשיך לעבוד.
הסיבה הפעם היא שדביאן לני מתשמש בPython 2.5 ומכיוון שתוכניות פייתון מותקנות משום מה לתוך ספריה שספציפית לגרסאת הפייתון, הייתי צריך להתקין מחדש את trac לתוך פייתון 2.5.
עד כאן הכל טוב.

בעיה נוספת הגיעה מהכיוון של שרת הדואר postfix.
השרת הזה עדיין לא משמש אותי לקבלת דואר (אני עדיין משתמש בשרת שבבית למטרה הזו) אבל הוא כן משמש לשליחת דואר.
בשלב מסויים שמתי לב שאני לא מקבל אימיילים על טיקטים חדשים שנוספו לtrac, מה שמייד החשיד את מערכת הדואר.
נראה שברגעים אלו ההתקנה של postfix בלני שבורה, ונאלצתי לדרדס קבצים מהמחשב בסלון שגם מריץ את לני כדי להצליח בהתקנה.

בעיה אחרונה הגיעה מהכיוון של ipkungfu, סקריפט הפיירוואל.
הבעיה היתה הודעות שגיאה מוזרות, שאפילו המפתח שלו לא הצליח להבין מאיפה הן באות (הוא יושב ב#ipkungfu בפרינוד).
בסוף הצלחתי לגרום לו לפעול איכשהו.

כל הסיפור לקח כשלוש ארבע שעות, כאשר רוב האתרים שאני מריץ לא היו למטה יותר מחצי שעה להערכתי.
די בטוח שנגלה עוד תקלות בהמשך, אבל סך הכל זה לא היה נורא.

castup

הודעה ששלחתי לתמיכה הטכנית של castup:

שלום,
כשאני גולש באתרים שמתמשים בשרות שלכם אני מרגיש כאילו השנה היא 1999 והאינטרנט הישראלי בחיתוליו.
בתור חברה שמכנה את עצמה "Leading developer and service provider" אתם מתהדרים בטכנולוגיה נחותה למדי שעובדת רק אצל חלק מהמשתמשים.
יש מגוון פתרונות של הזרמת וידאו שעובדים בצורה פורטבילית גם על לינוקס ומק, אבל אתם מתעקשים להשתמש בטכנולוגיות שעובדות רק בחלונות.
האם יש תקווה שהמצב ישתפר עוד בתום העשור הראשון למאה העשרים ואחת?

בתודה,
עמרי ידן.

הודעה זו פורסמה בבלוג שלי, http://firefang.net/blog

Debian live

מחר אני נוסע לאינטל חיפה כדי לבדוק את הביצועים של תוכנה שאנחנו מפתחים על הדור הבא של המעבדים של אינטל (ארכיטקטורת Nehalem), שישוחררו עוד כחודש וחצי.
אני הולך לבדוק מכונה עם שני מעבדים של ארבעה ליבות כל אחד, כאשר כל ליבה מריצה שני נימים (אינטל מחזירים את הHyperThreading) – ככה שבעצם המוכנה הזו תהיה שקולה למדי למכונה עם 16 ליבות.
הארכיטקטורה החדשה של נהלם צפויה לתת ביצועים טובים משמעותית לעומת הדור הנוכחי (לכל ליבה), בצריכת חשמל יותר נמוכה.
מומלץ מאוד לראות את הדמו.

את הפיתוח של המערכת שאני הולך לבדוק שם אני מבצע על דביאן, ואינטל הכינו מערכת עם רדהאט.
למרות שמירב הסיכויים הם שאני אצליח לגרום למערכת לרוץ, ממש לא בא לי להתחיל לחקור ולתקן במקום כל מני בעיות אזוטריות (אני מודאג בעיקר מספריות מגרסאות לא תואמות).

חשבתי לעצמי שיהיה נחמד לבוא עם סביבה מוכנה במקום לבוא ולהתקין הכל במקום בסביבה זרה, ומה יותר מתאים לזה מLIVE CD + כונן קשיח נייד?
הבחירה הטבעית שלי היתה Knoppix, הורדתי את הISO, העלתי אותו בVirtualBox, שמתי את האפליקציה על הדיסק הנייד והתחלתי לנסות להפעיל אותה.
למרבה הצער היו מלא בעיות, כשהקש ששבר את ראש הגמל היה שlibstdc++ היה מגרסא לא מתאימה.
החלטתי לוותר על התענוג, וביגוני חיפשתי בגוגל "Debian live cd".
התוצאה המפתיעה היא שיש פרוייקט בשם Debian live!

כמו תמיד עם live cd, חיפשתי מאיפה מורידים את הISO, התחלתי להוריד, ולמרבה המזל מהירות ההורדה היתה כ20K בשניה.
למה מזל?
כי במהירות כזו, היה לי מספיק זמן כדי להסתכל קצת מסביב.

About

A Debian Live system is a Debian operating system that does not require a classical installer to use it. It comes on various media, including CD-ROM, USB sticks, or via netboot.

Why Debian Live?
Although the Debian Live project is about the framework to create your own customized Live system, we offer some prebuilt images. Currently, builds for three desktop environments (GNOME, KDE and Xfce) as well as the standard system are available.

אז דביאן לייב היא בעצם מערכת ליצירת Live CD – מגניב, אבל ראיתי כבר כאלו:
לפני כשנה וחצי הגשתי פרוייקט של מנוע שחמט על דיסק Knoppix מותאם אישית.
התהליך של יצירת דיסק Knoppix מותאם הוא די מיגע, וסיקרן אותי לדעת איך זה בדביאן לייב.

מסתבר שהתהליך הוא פשוט במיוחד. כדי ליצור דיסק בסיסי ועובד:
[code]
apt-get install live-helper
mkdir live-cd
cd live-cd
lh_config
lh_build
[/code]

במילים, מתקינים את live-helper, יוצרים ספרית עבודה, משתמשים בlh_config כדי ליצור קופיגורציה בסיסית, ובlh_build כדי לבנות ממנה ISO.
התהליך יכול לקחת זמן, ומומלץ להתקין את apt-cacher כדי לחסוך בזמני הורדה של חבילות דביאן.
אפשר לבדוק את הISO עם VirtualBox. המערכת שהוא מכיל היא בסיסית מאוד, אבל אפשר להתקין בתוכה מה שרוצים עם apt-get.
יש כמה דרכים להוסיף חבילות שיהיו מותקנות מראש בISO:
כדי להוסיף חבילות סטנדרטיות, בסך הכל צריך להוסיף את השם שלהן בLH_PACKAGES בקובץ config/chroot בספרייית הקונפיגורציה שיצרתם.
יש גם דרכים להוסיף חבילות מותאמות אישית, ואפשר גם להוסיף קבצים ספציפייים בקלות.
מי שהתקין את apt-cacher ירצה לשנות את מקורות ההתקנה של יצירת הISO, אפשר לעשות את זה על ידי עריכה של config/bootstrap.

התיעוד של המערכת עדיין לא מלא, אבל מספיק כדי להתחיל.
בנוסף, החברה בערוץ הIRC של הפרייקט עוזרים למי שיודע לשאול.

אני ממליץ בחום על Debian live למי שצריך Live CD.
קל מאוד ליצור דיסקים איתו, והתוצאה היא מערכת דביאן לכל דבר, שעולה מCD/DVD.

גיבויים בלינוקס

אם יש מישהו שלא עושה טעויות, ושהחומרה שלו חסינה לתקלות, הוא יכול לדלג על הפוסט הזה.
אוקיי, מי שנשאר טועה לפעמים ומוחק דברים שלא היה צריך למחוק, ולפעמים גם ההרדיסק שלו קורס בלי התגרות.
כמות העבודה שאפשר לאבד בקריסה כזו או במחיקה לא מכוונת הולכת וגדלה ככל שהכוננים הקשיחים גדלים.
לפעמים אפשר לשחזר את הנתונים שאבדו עם עבודה חוזרת, ולפעמים מה שאבד, אבד לנצח.
גיבוי ידאג למזער את הנזק שנגרם מטעות אנוש או מתקלת חומרה לחלון הזמן שמרגע התקלה לזמן שבו בוצע הגיבוי האחרון.
גיבויים ידניים נועדו להיכשל ברגע האמת כי אנשים הם עצלנים ולא טובים בביצוע של פעולות שחוזרות על עצמן לאורך זמן אם אין איזה גורם שידאג שהם ימשיכו.
במילים אחרות, אם תתחילו בגיבויים ידנייים היום, בעוד שנה תגלו שאתם לא מגבים בצורה תדירה מספיק, אם בכלל.
הפיתרון הוא גיבויים אוטומטיים לחלוטין, שלא דורשים עבודת תחזוקה ידנית.

גיבוי מערכת הקבצים
יש הרבה שיטות לגבות את מערכת הקבצים.
היסטורית, השיטה הנפוצה היתה גיבוי הקבצים לטייפ גיבוי, בפורמט TAR, למעשה, השם של TAR הוא קיצור של Tape archive.
מה שנהוג לעשות בשיטה הזו זה לשמור את הכל בפעם הראשונה, ובפעמים הבאות לשמור רק את הקבצים שהשתנו.
השיטה הזו נקראת "גיבוי מלא + גיבוי הדרגתי", והחיסרון שלה הוא שכדי לשחזר את מה שהיה לפני שבוע, צריך ללכת לגיבוי המלא הכי קרוב ללפני שבוע (אולי בן חודשיים), ולעבור על כל הגיבויים מאותו רגע כדי לבנות את התמונה של הרגע הנתון.
לא כיף, במיוחד אם אנחנו לא בטוחים בתאריך המדוייק שבו הקובץ היה "נכון".

גרסא נוספת של הגיבוי הזה היא "מלא + דיפרנציאלי", בשיטה הזו גיבוי מלא נשמר, וכל גיבוי חלקי שאחריו הוא יחסי לגיבוי המלא, ולא לגיבוי החלקי האחרון. זה אומר שקבצים שהשתנו אחרי הגיבוי המלא יאוכסנו שוב ושוב, מצד שני יהיה הרבה יותר קל לשחזר את הגיבוי לרגע נתון.

הגיבוי התמים הוא פשוט להעתיק את הקבצים, כמו שהם, לספריה אחרת (ואולי למחשב אחר).
הבעיה עם זה היא שקבצים שלא משתנים יתפסו מקום כל פעם מחדש, מה שאומר שסך הכל הצריכה של המקום תהיה גבוהה מאוד.
הפתרון הוא לאכסן רק קבצים חדשים, אבל איך אפשר יהיה לשמור על הפשטות של השיטה התמימה?
אם אבד לי קובץ, אני רוצה לגשת לגיבוי של אתמול ולמצוא אותו שם, גם אם הוא לא השתנה כבר חודש.
כדי להנות משני העולמות, אפשר להשתמש בשיטה הבאה:
נגבה עם rsync, ולפני הגיבוי הבא, נעתיק את הספריה שגיבינו למקום חדש, אבל במקום להעתיק ממש את הקבצים ניצור hard-links לקבצים, ואז נגבה שוב עם rsync.
ברגע שrsync יזהה שקובץ השתנה, הוא יצור קובץ חדש במקום הלינק, ולא יפגע בקובץ המקורי שימשיך להיות זמין תחת הספריה המקורית שאליה הוא נכתב.
הרעיון הוא של מייק רובל, שפרסם אותו ב2004. מאז פותחו לא מעט סקריפטים שממשמשים את השיטה. אני משתמש בsnapback2 כדי לבצע את הגיבויים שלי.
כדי להתקין את snapback2, עקבו אחרי ההוראות האלו:

[code lang="bash"]
wget http://www.perusion.com/misc/Snapback2/Snapback2-0.913.tar.gz
tar xzf Snapback2-0.913.tar.gz
cd Snapback2-0.913/
cpan -i Config::ApacheFormat
perl Makefile.PL && make && make test && make install && echo great success
[/code]
cpan הוא מנגנון ניהול החבילות של שפת פרל. אם לא הפעלתם את cpan לפני כן, הוא ישאל כמה שאלות די קלות לפני שהוא יתקין את Config::ApacheFormat.
שימו לב לפלט של הפקודה האחרונה, אם הוא לא מסתיים ב "great success" אז היתה בעיה בהתקנה.
snapback2 עובד דרך הרשת, מה שאומר שאפשר לגבות איתו בקלות מכונה אחרת או את המכונה המקומית, אבל קודם צריך לדאוג לכך שנוכל להכנס בלי סיסמא (זהירות עם זה, צריך לשמור על הקובץ id_dsa.pub מכל משמר, כי מי שישיג אותו יוכל להכנס למכונה שאתם מגבים!).
[code lang="bash"]
ssh-keygen -t dsa
cat ~/.ssh/id_dsa.pub | ssh root@other_machine "cat – >> ~/.ssh/authorized_keys"
[/code]

קובץ ההגדרות /etc/snapback/snapback2.conf של snapback נראה ככה:
[code lang="xml"]
Hourlies 2
Dailies 7
Weeklies 4
Monthlies 4
AutoTime Yes

AdminEmail root

LogFile /var/log/snapback.log
ChargeFile /var/log/snapback.charges

SnapbackRoot /etc/snapback

DestinationList /root/backup


Exclude /cdrom
Exclude /dev
Exclude /home/*/temp
Exclude /media
Exclude /proc
Exclude /tmp
Exclude /var/cache
Exclude /var/log
Exclude /var/lib/mysql
Exclude /root/backup # Important not to backup the backup 🙂

Directory /

[/code]

הקובץ הזה מגבה את כל מה שרלוונטי, ואולי כמה דברים לא רלוונטים שעדיין לא הכנסתי לExclude.
ויוצר מבנה ספריות דומה לזה:
[code lang="xml"]
`– root@server.com
|– daily.0
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– daily.1
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– daily.2
| |– bin
| |– boot
| | …..
| `– www -> /var/www
|– hourly.0
| |– bin
| |– boot
| | …..
| `– www -> /var/www
`– hourly.1
|– bin
|– boot
| …..
`– www -> /var/www
[/code]

כדי להריץ את הגיבוי אוטומטית פעם ביום ניצור קובץ הרצה בcron.daily
[code lang="bash"]
echo "#! /bin/sh" > /etc/cron.daily/snapback2
echo "/usr/bin/snapback2" >> /etc/cron.daily/snapback2
chmod +x /etc/cron.daily/snapback2
[/code]
חדי העין ישימו לב שלא גיביתי את /var/lib/mysql, שמכילה את בסיסי הנתונים של MySQL.
הסיבה היא שלא מומלץ לגבות את בסיס הנתונים של MySQL על ידי העתקת הקבצים, במיוחד אם השרת רץ (והוא רץ כל הזמן), כדי לא לתפוס קבצים תוך כדי שהם נכתבים (מה שיגרום לגיבוי של בסיס הנתונים להיות דפוק).
גיבוי MYSQL
אני משתמש בסקריפט הזה, שמגבה את אל בסיסי הנתונים אל /var/backups/mysql, ויוצר מבנה ספריות דומה לזה:
[code lang="xml"]
|– daily
| |– omry_blogs
| | |– omry_blogs_2008-09-21.Sunday.sql.gz
| | |– omry_blogs_2008-09-22.Monday.sql.gz
| | |– omry_blogs_2008-09-23.Tuesday.sql.gz
| | |– omry_blogs_2008-09-24.Wednesday.sql.gz
| | |– omry_blogs_2008-09-25.Thursday.sql.gz
| | `– omry_blogs_2008-09-26.Friday.sql.gz
| | `– omry_paypal_2008-09-26.Friday.sql.gz
| `– omry_wordpress_en
| |– omry_wordpress_en_2008-09-21.Sunday.sql.gz
| |– omry_wordpress_en_2008-09-22.Monday.sql.gz
| |– omry_wordpress_en_2008-09-23.Tuesday.sql.gz
| |– omry_wordpress_en_2008-09-24.Wednesday.sql.gz
| |– omry_wordpress_en_2008-09-25.Thursday.sql.gz
| `– omry_wordpress_en_2008-09-26.Friday.sql.gz
|– monthly
`– weekly
[/code]
כמובן שהספריות האלו מגובות אוטומטית במסגרת הגיבוי של מערכת הקבצים.
כדי להשתמש בסקריפט, יש לשים אותו ב/etc/cron.daily ולערוך אותו ככה ששם המשתמש והסיסמא יהיו אלו של משתמש שמורשה לגשת לכל בסיס הנתונים. לא לשכוח לשנות את ההרשאות של הקובץ ככה שרק root יוכל לקרוא אותו.
כדי לחסום את הנפח שהגיבויים האלו תופסים, ניצור בcron.weekly סקריפט שמוחק גיבויי mysql ישנים מ60 יום:
[code lang="bash"]
echo "#!/bin/sh" > /etc/cron.weekly/delete_old_mysql_backups
echo "find /var/backups/mysql/ -type f -mtime +60 -exec rm {} \;" >> /etc/cron.weekly/delete_old_mysql_backups
chmod +x /etc/cron.weekly/delete_old_mysql_backups
[/code]

לשם הבטיחות, כדאי לגבות למחשב אחר, למשל זה שבבית, ככה שגם אם מתרסק הדיסק של השרת, השחזור יהיה אפשרי.
לשם הנוחות, כדאי לגבות גם לספריה מקומית את כל השרת, ככה שגם אם מחקתם קובץ גדול, לא תצטרכו להעלות אותו מהגיבוי המרוחק.