ידע מעשי של CyberFixCrew

איך בודקים שחזור גיבוי אתר

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

לפני שמתחילים: שומרים על האתר הפעיל

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

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

מה צריך להיות בגיבוי

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

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

סדר עבודה לבדיקה

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

  1. בוחרים עותק ומוודאים שאפשר לפתוח או לפענח אותו בלי לשנות את המקור.
  2. מבטלים שליחת דואר, חיובים, משימות מתוזמנות וחיבורי webhook יוצאים בסביבת הבדיקה.
  3. משחזרים קבצים ונתונים בהתאם להוראות המערכת והגרסה.
  4. פותחים את האתר דרך כתובת בדיקה ומאמתים כניסה מורשית ותוכן.
  5. בודקים תהליכים עסקיים עם נתוני בדיקה ועם סביבת סליקה ייעודית, אם רלוונטי.
  6. רושמים זמני התחלה וסיום, תקלות, נתונים חסרים ותלות בספק.
  7. מוחקים או מבודדים את עותק הבדיקה לפי המדיניות שנקבעה.

טופס קבלה שאפשר למלא

הבדיקה אינה עוברת רק מפני שדף הבית עולה. קובעים מראש אילו תוצאות נדרשות.

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

מה עושים אם השחזור נכשל

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

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

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

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

מקור מקצועי: WordPress: רכיבי גיבוי ויכולת שחזור

תשובות ברורות

שאלות שעולות בנושא

כל כמה זמן צריך לבצע בדיקה?

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

האם צריך גישה לשרת?

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

מה ההבדל בין RPO ל-RTO?

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

מתקדמים לפי הצורך

נבדוק שאפשר לחזור מהגיבוי

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

לתכנון בדיקת שחזור