גיבויים אוטומטיים עם Anacron ו-rsync

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

מבוא

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

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

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

קהל היעד

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

תוכנית גיבוי

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

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

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

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

Data 	Change Freq. 	Size 	Daily Mirror 	Weekly Snapshots 	Monthly Snapshots 	Space Required
	1 	2 	3 	1 	2 	3 	4 	6 	12 	
E-mails 	Daily 	100Mb 	Y 	Y 	Y 	Y 	Y 	N 	Y 	N 	Y 	Y 	500Mb
MySQL Data 	Daily 	30Mb 	Y 	Y 	N 	N 	Y 	N 	Y 	N 	Y 	N 	70Mb
Website 	Monthly 	900Mb 	Y 	Y 	N 	N 	Y 	N 	N 	Y 	N 	N 	3,200Mb
/etc 	2-3 Weeks 	28Mb 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	200Mb
Thesis 	Daily 	25Mb 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	Y 	N 	190Mb
Research Code 	Rarely 	60Mb 	Y 	Y 	N 	N 	Y 	N 	Y 	N 	Y 	Y 	200Mb
Total space required: 	4,360Mb

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

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

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

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

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

4. במחיצה נפרדת בדיסק.

5. באותה המחיצה בדיסק.

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

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

rsync הדרך המהירה והגמישה להעברת קבצים

rsync היא תוכנה מהירה וגמישה להעברת קבצים. היא משתמשת בפרוטוקול פרטי לעדכון הקבצים ביעד, באופן שמאפשר לה להעביר אך ורק את ההבדלים בין מערכות הקבצים. היא יכולה לעבוד באותו מחשב, או ברשת באמצעות rcp, ssh או שרת (daemon) משלה. rsync זמינה בכל הפצות הלינוקס הסטנדרטיות כברירת מחדל - אם לא, ניתן להוריד אותה מאתר הפרוייקט (http://rsync.samba.org).

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

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

rsync -r -e ssh --delete /home/username/mail username@mycomputer.mycompany.com:/backups/mail

כאשר:

-r מורה ל-rsync להעתיק את כל ספריות המשנה (רקורסיה) -e ssh מורה ל-rsync להשתמש ב-ssh (פרטים בהמשך) --delete מורה ל-rsync למחוק את הקבצים שאינם קיימים ביעד, אם הם לא קיימים במקור /home/username/mail הספריה אותה אנחנו מעתיקים username@mycomputer.mycompany.com:/backups/mail התחבר כמשתמש (usersname) במחשב המרוחק, וצור\עדכן את הקבצים בספריה backups/mail

פקודה זו תיצור עותק של הספריה /home/username/mail במחשב mycomputer.mycompany.com בתוך הספריה /backups/mail/mail. זה בדיוק מה שרצינו. אם תרצה לבצע פעולה הפוכה (גיבוי מהמחשב המרוחק לספריית הבית שלך) פשוט תחליף בין המקור והיעד:

rsync -r -e ssh --delete username@mycomputer.mycompany.com:/home/username/mail /backups/mail

אני ממליץ להשתמש בפרוטוקול ssh כדי להבטיח שמירה על פרטיות הנתונים במהלך ההעברה. אם הגיבוי מתבצע ברשת פרטית, אין מניעה להשתמש בפרוטוקולים ישנים יותר כמו rsh, או אפילו ב-daemon של rsync עצמה. שמירת גיבויים לרשת יוצרת בעיה נוספת: השימוש ב-rsh או ssh בגיבוי, דורש התערבות ידנית של המשתמש, ואתה מן הסתם מעוניין בגיבוי אוטומטי. נתגבר על מכשול זה באמצעות מפתחות ציבוריים/פרטיים ללא שימוש ב-pass-phrase.

הגדרת זיהוי ב-ssh ללא צורך בסיסמה

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

הפקודות בהמשך יאפשרו להגדיר זיהוי ללא צורך בסיסמאות, בי המחשב שלך למחשב בשם mycomputer.mycompany.com:

    $ ssh-keygen -b 1024 -t rsa -f /home/username/.ssh/id_rsa
    (do not enter a pass-phrase - leave it blank)
    $ scp /home/username/.ssh/id_rsa.pub username@mycomputer.mycompany.com:/home/username/.ssh/authorized_keys

אם תתקל בבעיות, הן יהיו בדרך כלל בגלל ההרשאות שניתנו לקבצי המפתחות. העזר בפרמטר v- של ssh ובדוק בלוג של ssh בשני המחשבים (בדרך כלל /var/log/secure).

כדאי שתיקח בחשבון שבשיטה זו ישנן סכנות. הפקודה ssh-keygen יצרה שני קבצים:

    * /home/username/.ssh/id_rsa: the private key
    * /home/username/.ssh/id_rsa.pub: the public key 

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

אם אכן תשתמש בשיטה זו, תצטרך להבטיח גם:

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

• להגדיר משתמש חדש במחשב המשמש לצורך גיבוי, ולהבטיח שהוא משמש לצורך הגיבוי בלבד.

תזמון והפעלה של תהליכים עם cron

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

לכל משתמש בלינוקס יש טבלת cron משלו ("crontab") בה נשמרות הגדרות התזמון. ניתן להציג את תוכן הקובץ עם הפקודה 'crontab -l', לרוקן אותו עם 'crontab -r' או לערוך אותו עם 'crontab -e'. בוא נוסיף את הפקודה לביצוע הגיבוי היומי בשעה 2 לפנות בוקר:

00 02 * * * rsync -r -e ssh --delete /home/username/mail username@mycomputer.mycompany.com:/backups/mail

חמש השדות (0 2 * * *) הם (בהתאמה):

    Field	Allowed Values
    minute
    hour
    day of month
    month
    day of week 	0-59
    0-23
    1-31
    1-12
    0-7*
    ( *0 or 7 is Sunday) 

במקרה שלנו, תתבצע ההעתקה של תוכן הספריה /home/username/mail בשעה 02:00 לפנות בוקר בכל יום. נוכל להוסיף פקודות עבור כל הספריות האחרות, אבל נוכל גם ליצו תסריט המכיל את כל הפקודות וניתן ל-cron להריץ אותו.

ישנם מספר משתני סביבה שימושים שיכולים לעזור לך לערוך את קובץ crontab והם דורסים את ברירות המחדל:

SHELL=/bin/sh
MAILTO=username

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

מחברים את הקצוות

לאחר ההיכרות הבסיסית עם rsync ו-cron, כל שנותר לנו לעשות הוא לחבר את הכל וליצור תוכנית גיבויים. נמשיך עם הדוגמה בה המחשב הבייתי שלך שולח מדי לילה עותק של הקבצים שלך למחשב במשרד. המחשב במשרד יהיה אחראי להמשך הגיבוי: כלומר שמירת עותקים של הגיבויים בפרקי הזמן שהגדרת. נשתמש ב-crontab במחשב במשרד כדי לבצע זאת, ואני אדגים את התיזמון לביצוע התוכנית שהגדרתי בסעיף 3.

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

התוכנית שלי דורשת גיבויים בני 1,2 ו3- שבועות, וגם 1, 2, 3, 4 ו6- חודשים. נעבוד על הגיבויים הישנים יותר תחילה (אחרת נעתיק רק את הגיבויים החדשים יותר).

1. Back up mail files with snapshots of 6, 4, 3, 2, 1 months and 3, 2, 1 weeks
2. Order 4m->6m, 3m->4m, 2m->3m, 1m->2m, 3w->1m, 2w->3w, 1w->2w, mirror->1w

1. At 3am on the 1st of Jan,Mar,May,Jul,Sep,Nov copy the 4m to the 6m

00 03 1 1,3,5,7,9,11 * cp -f /backups/thesis/backup/4month.tar.gz /backups/thesis/backup/6month.tar.gz

1. At 3.02am on the 1st of every month move the 3m to the 4m (and continue for other months)

02 03 1 * * cp -f /backups/thesis/backup/3month.tar.gz /backups/thesis/backup/4month.tar.gz 04 03 1 * * cp -f /backups/thesis/backup/2month.tar.gz /backups/thesis/backup/3month.tar.gz 06 03 1 * * cp -f /backups/thesis/backup/1month.tar.gz /backups/thesis/backup/2month.tar.gz 08 03 1 * * cp -f /backups/thesis/backup/3week.tar.gz /backups/thesis/backup/1month.tar.gz

1. And then every Sunday take care of the weekly snapshots and the archiving of the mirror

10 03 * * 0 cp -f /backups/thesis/backup/2week.tar.gz /backups/thesis/backup/3week.tar.gz 12 03 * * 0 cp -f /backups/thesis/backup/1week.tar.gz /backups/thesis/backup/2week.tar.gz 14 03 * * 0 rm -f /backups/thesis/backup/1week.tar.gz 16 03 * * 0 tar zcf /backups/thesis/backup/1week.tar.gz /backups/thesis/thesis/*

And that my friends is your automatic, hassle-free, and effective backup system.

A few points on the above:

   * I have placed each command 2 minutes apart to allow the previous one to complete. Adjust this depending on your own file sizes, system load, hard disk speed, etc.
   * In the example in section 5 for the automatic mirroring I set the mirror time to 2 a.m. Ensure, as I have done here, that the snapshots get created after the mirror (i.e., allow enough time for the mirroring to complete)
   * Before the first run you should ensure all directories are created, archive the existing mirror, and copy it to all the required files (copy 1week.tar.gz to 2week.tar.gz, 3week.tar.gz, etc) to prevent unnecessary error messages 

7. Anacron vs. cron

Anacron is a periodic command scheduler similar to some uses of cron, but it does not assume that the system is running continuously. It can therefore be used for our backup policy on systems that don't run 24 hours a day. Just like rsync and cron, Anacron is now part of most standard Linux distributions.

Every time Anacron is run, it reads a configuration file that specifies the jobs Anacron controls, and their periods in days. If a job wasn't executed in the last n days, where n is the period of that job, Anacron executes it. The configuration file is usually /etc/anacrontab.

For the daily mirroring we could add a line to this configuration file such as:

1 20 mirror rsync -r -e ssh --delete /home/username/thesis username@mycomputer.mycompany.com:/backups/thesis

where the fields mean:

1

   the period in days indicating how often this command should be executed

20

   the delay in minutes after Anacron begins before it should execute this command

mirror

   a unique identifier for this job so Anacron can keep track of when it was last executed

rsync...

   the command to execute

And similarly on the backup machine we would place the following in the Anacron configuration file:

1. Back up mail files with snapshots of 6,4,3,2,1 months and 3,2,1 weeks
2. Order 4m->6m, 3m->4m, 2m->3m, 1m->2m, 3w->1m, 2w->3w, 1w->2w, mirror->1w

1. Every 60 days (2 months)

60 20 bup1 cp -f /backups/thesis/backup/4month.tar.gz /backups/thesis/backup/6month.tar.gz

1. every 30 days (1 month)

30 22 bup2 cp -f /backups/thesis/backup/3month.tar.gz /backups/thesis/backup/4month.tar.gz 30 24 bup3 cp -f /backups/thesis/backup/2month.tar.gz /backups/thesis/backup/3month.tar.gz 30 26 bup4 cp -f /backups/thesis/backup/1month.tar.gz /backups/thesis/backup/2month.tar.gz 30 28 bup5 cp -f /backups/thesis/backup/3week.tar.gz /backups/thesis/backup/1month.tar.gz

1. And every 7 days

7 30 bup5 cp -f /backups/thesis/backup/2week.tar.gz /backups/thesis/backup/3week.tar.gz 7 32 bup7 cp -f /backups/thesis/backup/1week.tar.gz /backups/thesis/backup/2week.tar.gz7 7 34 bup8 rm -f /backups/thesis/backup/1week.tar.gz 7 36 bup9 tar zcf /backups/thesis/backup/1week.tar.gz /backups/thesis/thesis/*

A few notes on this:

   * You really need to plan well if using Anacron. What if the office machine is regularly off while the home machine is trying to rsync? Anacron can work best in this situation if it is the source machine that is not always running; it can perform the rsync and then take care of the snapshots.
   * Ensure you make proper use of the delay time to ensure one job has finished before the other starts
   * Anacron is also ideal for laptop users 

8. Resources

For a more professional backup solution:

   * Amanda, The Advanced Maryland Automatic Network Disk Archiver, http://www.amanda.org/ 

Get advance notification before your hard disk fails:

   * smartmontools Home Page - http://smartmontools.sourceforge.net/ 

 By Barry O'Donovan