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