השרת לא עולה, העובדים לא נכנסים לקבצים, התוכנה העסקית נתקעת והדואר או מערכת הנהלת החשבונות תלויים באוויר. במצב כזה, שחזור שרת תקול אינו רק משימה טכנית. זו פעולה שמטרתה להחזיר את העסק לעבוד בלי להחמיר את הנזק, בלי למחוק מידע יקר ובלי לבזבז שעות על ניסיונות אקראיים.
הטעות הנפוצה ביותר בזמן תקלה היא למהר ללחוץ על הפעלה מחדש, להריץ תיקון אוטומטי או לנסות לשחזר קבצים בלי להבין מה קרה. לעיתים זה אכן פותר תקלה קטנה. במקרים אחרים, במיוחד כאשר יש כשל בדיסקים, בעיית תקשורת, הצפנת כופרה או כשל במכונה וירטואלית, פעולה לא נכונה עלולה לפגוע בנתונים שעדיין אפשר להציל.
קודם עוצרים ומגדירים מה בדיוק נפגע
המילה "שרת" יכולה לתאר כמה דברים שונים: מחשב פיזי במשרד, שרת וירטואלי, שרת קבצים, מערכת מסדי נתונים, שרת דואר או שירות שפועל בענן. לכן הצעד הראשון אינו בהכרח שחזור, אלא אבחון ממוקד.
צריך להבין אם הבעיה היא שהשרת עצמו כבוי, אם מערכת ההפעלה אינה עולה, אם דיסק נפגע, אם הרשת מנותקת או אם רק שירות מסוים הפסיק לפעול. שרת יכול להיראות תקול לעובדים כאשר למעשה החומרה תקינה, אך מתג התקשורת, חיבור האינטרנט, ההרשאות או שירות מסד הנתונים הם מקור התקלה.
בשלב הזה בודקים גם את היקף הפגיעה: האם אף אחד לא עובד, האם רק מחלקה אחת מושבתת, האם ניתן לפתוח קבצים מקומיים, והאם יש מערכות שעדיין פועלות. המידע הזה קובע מה צריך להחזיר קודם. לעסק אחד מערכת הנהלת החשבונות היא הדחופה ביותר, ולעסק אחר דווקא תיקיות פרויקטים, הזמנות או מערכת שירות הלקוחות.
מה לא לעשות כששרת מפסיק לעבוד
הלחץ מובן, אבל יש כמה פעולות שכדאי להימנע מהן עד שמבינים את מקור התקלה:
- לא לאתחל את השרת שוב ושוב בתקווה ש"בפעם הבאה זה יעלה".
- לא לפרמט דיסק, להתקין מחדש מערכת הפעלה או להחליף דיסקים לפני בדיקת מצב הנתונים.
- לא למחוק קבצים זמניים, יומנים או חשבונות משתמשים רק כדי לפנות מקום או לפתור הודעת שגיאה.
- לא לחבר כונני גיבוי לשרת אם קיים חשד לנוזקה או להצפנת כופרה.
- לא להניח שגיבוי שקיים בתוכנה הוא גם גיבוי שאפשר לשחזר ממנו בפועל.
פעולות כאלה עשויות להיות נכונות לאחר אבחון מקצועי, אך לא כתגובה ראשונה. המטרה היא לשמור אפשרויות פתוחות. אם מקור התקלה הוא חומרה, למשל, אפשר לעיתים להפעיל את הסביבה על ציוד חלופי או לשחזר אותה למכונה וירטואלית. אם מדובר בהצפנה, צריך קודם לבודד את המערכת ולוודא שגם הגיבוי נקי.
שחזור שרת תקול מתחיל בבחירת נתיב נכון
אין שיטת שחזור אחת שמתאימה לכל תקלה. הבחירה תלויה במצב השרת, בגיל הגיבוי, בנפח המידע ובזמן שהעסק יכול להרשות לעצמו להיות מושבת.
כאשר התקלה היא בדיסק בודד במערך תקין, ייתכן שהפתרון יהיה החלפת רכיב ושיקום המערך, בלי שחזור מלא. כאשר מערכת ההפעלה נפגעה אבל הנתונים קיימים, אפשר לתקן את סביבת ההפעלה או להעביר את הנתונים למערכת חדשה. אם השרת ניזוק לחלוטין, הדרך היעילה יותר עשויה להיות שחזור מלא של תמונת השרת לגיבוי האחרון התקין.
בשרת וירטואלי, כגון סביבת VMware, יש לעיתים אפשרות להחזיר מכונה וירטואלית שלמה, כולל מערכת ההפעלה, ההגדרות והתוכנות. זה יכול לקצר משמעותית את זמן החזרה לעבודה, אך רק אם הגיבוי הוגדר נכון ונבדק מראש. שחזור קובץ בודד שונה מאוד משחזור של מכונה מלאה, ומסד נתונים מסוג Microsoft SQL Server, MySQL או Oracle דורש לעיתים טיפול עקבי יותר כדי למנוע פער בין קבצי הנתונים לבין מצב המערכת.
הנקודה החשובה היא לא רק "האם יש גיבוי", אלא לאיזו נקודת זמן אפשר לחזור. גיבוי מאתמול בלילה עשוי להספיק לעסק מסוים, בעוד עסק אחר עלול לאבד יום שלם של הזמנות, עדכונים או מסמכים. לכן יש להגדיר מראש כמה מידע מותר לאבד במקרה קיצון, וכמה זמן מותר למערכות להיות מושבתות.
סדר הפעולות בשעות הראשונות
במצב חירום, סדר הפעולות משפיע ישירות על משך ההשבתה. תחילה מתעדים את הודעות השגיאה, נורות החיווי, השינויים האחרונים והזמן שבו העובדים הפסיקו לעבוד. לאחר מכן בודקים את החומרה, החשמל, התקשורת והגישה מרחוק, ומבודדים את השרת אם יש חשד לאירוע אבטחה.
במקביל, חשוב לעדכן את העובדים באופן ענייני. אין צורך להבטיח שעה מדויקת לפני שמבינים את היקף התקלה, אבל יש ערך רב בהנחיה ברורה: אילו מערכות אינן זמינות, האם אפשר לעבוד מקומית, האם אסור להתחבר לשרת, ומהו ערוץ העבודה החלופי. כך מצמצמים ניסיונות כניסה מיותרים, יצירה של עותקים כפולים ובלבול בין גרסאות של מסמכים.
לאחר האבחון מחליטים אם לתקן את השרת הקיים, להפעיל שרת חלופי או לבצע שחזור. במקרים מסוימים נכון להחזיר תחילה שירות קריטי אחד, למשל מסד נתונים או תיקיית עבודה מרכזית, ורק לאחר מכן את יתר המערכות. זה עדיף על המתנה לשחזור מלא כאשר חלק מהעובדים יכולים כבר לחזור לפעילות.
גיבוי בענן הוא ביטוח רק אם הוא נבדק
עסקים רבים מגלים ברגע הלא נכון שהגיבוי לא כלל את התיקייה החשובה, שנכשל במשך שבועות, או שהוא נשמר באותו מקום שנפגע. גיבוי איכותי צריך להיות נפרד מהשרת, מוגן מפני גישה לא מורשית, ולכלול את מה שהעסק באמת צריך לשחזר: קבצים, תוכנות, מחיצות, מסדי נתונים, דואר אלקטרוני ולעיתים גם מכונות וירטואליות.
אבל גם כאן יש הבדל בין גיבוי לבין יכולת התאוששות. גיבוי יכול להסתיים ללא שגיאה ועדיין לא להיות שימושי במקרה אמת. לכן יש לבצע בדיקות שחזור תקופתיות. לא חייבים לעצור את כל העסק בכל פעם, אך צריך לבחור קבצים, תיקיות או מערכת בדיקה ולוודא שהחומר נפתח, שהנתונים עדכניים ושאפשר להחזיר אותם ליעד הנכון.
כדאי גם לשמור יותר מגרסה אחת. אם הצפנת כופרה החלה לפני שהתגלתה, הגיבוי האחרון עלול כבר לכלול קבצים מוצפנים. היסטוריית גרסאות מאפשרת לחזור לנקודה קודמת ונקייה יותר. זהו הבדל קריטי בין התאוששות מהירה לבין אובדן מידע ממושך.
אחרי ההחזרה לעבודה, לא מדלגים על הבדיקה
שרת שחזר לעלות אינו בהכרח שרת שחזר לעבוד באופן תקין. לאחר השחזור יש לבדוק שהמשתמשים מצליחים להיכנס, שהרשאות התיקיות תקינות, שהמדפסות והכוננים הממופים זמינים, שמסדי הנתונים עובדים ושאין שגיאות ברישום המערכת. אם מדובר בשרת שמפעיל תוכנה עסקית, חשוב לבקש מבעלי התפקידים לבצע בדיקות אמיתיות: פתיחת מסמך, הפקת דוח, קליטת הזמנה או עבודה על פרויקט.
זה גם הזמן לברר למה התקלה התרחשה. דיסק שהתקרב לסוף חייו, אל-פסק תקול, עדכוני מערכת שלא נבדקו, נפח אחסון מלא או הרשאות חלשות יכולים לחזור ולפגוע בעסק אם רק מחזירים את המצב לקדמותו. שחזור טוב אינו מסתיים כשהמסך נדלק. הוא מסתיים כאשר מקור התקלה מטופל ויש תוכנית שמקטינה את הסיכוי לאירוע הבא.
בטופ מחשבים מתייחסים לאירוע שרת כאל אחריות מלאה, מהאבחון הראשוני ועד לווידוא שהעובדים חזרו לעבוד ושמערך הגיבוי מוכן לפעם הבאה. כששרת תקול, הדבר הנכון הוא לא לחפש פתרון מהיר בכל מחיר, אלא לקבל החלטות מסודרות ששומרות על הנתונים, מצמצמות השבתה ומחזירות לעסק את השקט התפעולי שהוא צריך.