גיבוי ושחזור VPS: תרגול העתקה ובדיקת קבצים

מגדירים מה התרגיל כולל

נדרשים Bash, GNU tar, sha256sum ו-OpenSSH ב-Ubuntu, ומחשב Linux או WSL נפרד. השאירו מסוף אחד לשרת ואחד למחשב המקומי כדי שהמשתנים מהשלבים הקודמים יישארו זמינים. עצרו בכל שגיאת פקודה.

ייווצרו שני קובצי תרגול בתיקיית הבית. הם אינם משנים Nginx, חומת אש או קובצי אתר פעילים. לא מחלצים כ-root או לתיקיית /. אתר מלא עשוי לדרוש מסד נתונים, הפניות, includes, DNS ותלויות נוספות שאינן נכללות כאן אוטומטית.

יוצרים שני קובצי תרגול בשרת

הריצו עם משתמש הניהול הרגיל. mktemp יוצר תיקייה נפרדת ו-umask מגביל הרשאות חדשות. קובץ Nginx הוא קובץ לא פעיל, שנועד להיכלל בארכיון בלבד.

umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' '    listen 8080;' '    server_name example.test;' '    root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"

הטקסט Recovered static page הוא כותרת קובץ הבדיקה ומשמש לאימות התוכן בהמשך. שמרו את הנתיב שהודפס. שום קובץ פעיל אינו נדרס.

יוצרים ארכיון וסכומי ביקורת

המשיכו באותו מסוף שרת, שבו משתנה תיקיית התרגיל עדיין מוגדר:

(
    cd "$backup_lab/payload" &&
    sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
    cd "$backup_lab/export" &&
    sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"

רשימת התוכן צריכה לכלול site/, nginx/, שני קובצי התרגול ו-SHA256SUMS. אל תשנו תוכן בין חישוב הסכומים לאריזה. הסכום החיצוני בודק את הארכיון שהועבר; הרשימה שבתוכו בודקת את הקבצים לאחר שחזור.

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

מעבירים למחשב אחר

במסוף המקומי של Linux או WSL הגדירו remote_backup לנתיב export המדויק שהשרת הדפיס. REPLACE הוא סימון להחלפה, לא הסיומת האקראית האמיתית של mktemp. החליפו משתמש, IP ומפתח בגישה התקינה שלכם.

umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"

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

SCP מגן על ההעברה באמצעות SSH. tar.gz הוא ארכיון דחוס, לא הצפנה באחסון. השתמשו בהרשאות ובהצפנת אחסון מתאימות. תיקייה אחרת באותו VPS אינה עותק עצמאי.

בודקים לפני החילוץ

המשיכו באותו מסוף מקומי:

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

sha256sum צריך להציג OK. עברו גם על הנתיבים בארכיון. במקרה של אי-התאמה בדקו את המקור או ההעברה; אל תכתבו סכום חדש כדי להפוך שגיאה להצלחה. אין לחלץ ארכיון בלתי צפוי או לא מאומת.

משחזרים לתיקייה חדשה וריקה

חלצו את הארכיון המהימן לתיקייה חדשה. --keep-old-files מונע דריסה של קבצים קיימים ו--no-same-owner אינו משחזר את בעלות הארכיון. אל תשתמשו ב-sudo.

restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
    cd "$restore_dir" &&
    sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"

צפו ל-OK עבור site/index.html ו-nginx/first-site.conf ולכותרת קובץ התרגול. התוצאה מאמתת את הבתים של הקבצים שנבחרו. היא אינה מוכיחה הרשאות ייצור, ACL, גישה לשירות או שלמות כל תלויות האתר.

מפרידים שחזור קבצים משחזור השירות

התצורה ששוחזרה היא עדיין קובץ לא פעיל. בשרת חלופי נפרד בדקו נתיבים, includes, מודולים, הרשאות ותעודות, ואמתו את התצורה המלאה לפני טעינה. לאחר מכן בדקו HTTP/HTTPS מבחוץ. בדיקת תחביר בשרת המקורי שלא השתנה אינה בודקת את העותק הזה.

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

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

מגדירים יעדים ומתעדים תוצאה

RPO הוא אובדן הנתונים המותר במונחי זמן; RTO הוא יעד הזמן להחזרת השירות. למשל RPO של 24 שעות ו-RTO של 60 דקות הם יעדים עסקיים לדוגמה, לא תוצאות שנמדדו בתרגיל. גיבוי יומי עוזר רק אם הוא מצליח וניתן לשחזור.

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

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

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

שאלות ותשובות

צריך למחוק את המקור כדי להוכיח שהגיבוי עובד?

לא. שחזרו לתיקייה נפרדת וריקה ובדקו שירות מלא בסביבה חלופית.

סכום ביקורת תקין מוכיח שהכול גובה?

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

זה גיבוי מלא לסביבת ייצור?

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

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

גיבוי ושחזור VPS: מוודאים שהקבצים חוזרים