בהתאם לדרישות שלכם לגבי שיקוף הייצור כדי לשכפל עותק של הנתונים למכשיר גיבוי/שחזור שני, אתם יכולים לבצע את יתירות הכשל של תמונת שכפול של StreamSnap לאתר ייצור של נתונים משוכפלים במכשיר גיבוי/שחזור שני. אפשר לשכפל את השינויים שבוצעו באתר ה-DR בחזרה (failback) לסביבת הייצור במכשיר הגיבוי/השחזור המקומי.
- אפשר להשתמש בכמה תמונות של סנכרון חוזר כדי לשכפל שינויים מצטברים שבוצעו באתר ה-DR בחזרה לסביבת הייצור.
אפשר לטעון, לשכפל או לשחזר תמונות של Syncback באתר הייצור כדי לשחזר את הגישה.
בדיקת יתירות כשל
אחרי שמגדירים מדיניות שכפול של ייצור לשיקוף כדי לבצע שכפול של StreamSnap, ואז מחילים תבנית לגיבוי נתונים כדי לנהל אפליקציה או VM, אפשר לבדוק את יתירות הכשל כדי לקבוע את מידת המוכנות של מכשיר הגיבוי/השחזור המרוחק. כשבודקים פעולת יתירות כשל, נוצר עותק וירטואלי של התמונה המשוכפלת האחרונה של האפליקציה, והוא מוצג למארח שבחרתם. אתם יכולים להתחבר למארח ולוודא שהתמונה עקבית. העלאת יתירות כשל לבדיקה ליעד בלי להפסיק את הרפליקציה.
לפני שמבצעים בדיקת יתירות כשל, חשוב לשים לב לשיקולי השימוש הבאים:
- מוודאים שיציאת ה-iSCSI של המארח שאליו רוצים לטעון את קובץ הגיבוי נגישה למכשיר המרוחק.
- אפשר להעביר תמונה אחת בלבד למארח אחד בכל פעם. לדוגמה, אם תמונת יתירות כשל זמינה במכשיר המרוחק והמכשיר המקומי מנהל את המארחים א' וב', אפשר לארח את התמונה בא' או בב', אבל לא בשניהם.
- אי אפשר להעביר אפליקציה של מכונה וירטואלית לאותה מכונה וירטואלית במקרה של כשל.
- כדי לבדוק את יתירות הכשל של מכונות וירטואליות של VMware, צריך ששרת ESX ושרת vCenter יפעלו באתר המרוחק.
כדי לבדוק את יתירות הכשל במכשיר המרוחק, פועלים לפי ההוראות הבאות במסוף הניהול של המכשיר:
במסוף הניהול של מכשיר Backup and DR, לוחצים על App Manager ובוחרים באפשרות Applications מהרשימה הנפתחת.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית שרוצים להעביר, ואז בוחרים באפשרות Access מהרשימה הנפתחת בפינה הימנית התחתונה של הדף.
הדף גישה נפתח.
בוחרים תמונת מצב מרוחקת ואז בוחרים באפשרות Test Failover מרשימת הפעולות.
הדף Test Failover נפתח.
בוחרים באפשרות Test Failover מרשימת פעולות הגישה.
נפתח הדף Test Failover.
בוחרים מיקום לביצוע בדיקת יתירות הכשל, מארח קיים או מכונה וירטואלית חדשה.
כדי להעביר את הגיבוי למארח קיים, בוחרים באפשרות Existing Host ובוחרים מארח מהרשימה הנפתחת Host. המארח שנבחר חייב להיות מארח SAN או מכונה וירטואלית בשרת ESX שמחובר למכשיר.
כשמבצעים מעבר לגיבוי בעת כשל למכונה וירטואלית חדשה של VMware, בוחרים באפשרות New Virtual Machine ומבצעים את הבחירות הבאות שספציפיות למכונה הווירטואלית.
- שם ה-VM: מזינים שם למכונה הווירטואלית החדשה שרוצים לטעון.
- VCENTER: בוחרים vCenter מהרשימה הנפתחת של המכונה הווירטואלית החדשה שרוצים לטעון.
- ESX HOST: בוחרים מארח ESX מהרשימה הנפתחת של המכונה הווירטואלית החדשה שרוצים לטעון.
- DATASTORE: בוחרים מהרשימה הנפתחת מאגר נתונים עם נפח האחסון הנדרש למכונה הווירטואלית החדשה שרוצים לטעון.
בקטע מצב טעינה, בוחרים אחת מהאפשרויות הבאות:
- vRDM (מיפוי וירטואלי של מכשיר גולמי): מצב vRDM נבחר כברירת מחדל. תמונות המצב של VMware מתייחסות ל-vRDM מותקנים כאל עצמאיים, והם לא נכללים בתמונות המצב. לכן, כברירת מחדל, Backup and DR לא כולל vRDMs כשמגנים על VM מותקן. ב-Backup and DR יש אפשרות לסמן vRDM כתלויים. למרות שהאפשרות הזו לא נמצאת בשימוש לעיתים קרובות, כשהיא מופעלת, vRDMs נכללים בתמונות המצב של VMware. תבניות לגיבוי נתונים יכולות לתעד vRDMs שמסומנים כ-Dependent.
- pRDM (מיפוי פיזי של מכשיר גולמי): לפעולות שחזור ברמת הקובץ, בוחרים במצב pRDM.
אם בוחרים באפשרות pRDM, מופיעות אפשרויות הטעינה הנוספות הבאות:
- טעינת כונן: מציינת אות כונן שתוקצה לאמצעי האחסון. אם אות הכונן לא זמינה, המשימה נכשלת. אם נמצאים כמה אמצעי אחסון, המערכת מקצה את אותיות הכונן הבאות. אם לא צוין כונן לטעינה, סוכן Backup and DR בוחר אות כונן בעצמו, אם יש כזו.
- נקודת טעינה: הנתיב המלא שבו רוצים לטעון את אמצעי האחסון. אם הנתיב קיים כתיקייה ריקה, סוכן Backup and DR משתמש בו. אם הוא לא קיים, סוכן Backup and DR יכול ליצור אותו. אם הוא קיים כקובץ או כתיקייה לא ריקה, המשימה תיכשל. אם יש כמה אמצעי אחסון לטעינה, סוכן Backup and DR בוחר את המשתמש שצוין לאחד מאמצעי האחסון, ולשאר אמצעי האחסון הוא מוסיף קו תחתון (_) ואחריו מספר – לדוגמה, userspecified#.
אם אתם טוענים אפליקציה גנרית (LVM), תקבלו אפשרויות מיפוי נוספות.
- בתפריט הנפתח Mount Action, בוחרים באפשרות Keep Source Path כדי לשמור על מבנה התיקיות המקורי, באפשרות Specify Mount Location כדי לציין מיקום ספציפי לטעינת האפליקציה, או באפשרות Map Only כדי למפות את אמצעי האחסון למארח בלי לטעון אותם למערכת הקבצים.
אם צריך, משנים את ברירת המחדל של Storage pool שבו משתמשים לטעינה מהרשימה הנפתחת. ההגדרה הזו רלוונטית רק לטעינות שאין בהן דיסק קיים של אזור ביניים, כמו Direct to OnVault ותמונות מיובאות של OnVault. אחרת, תמיד נעשה שימוש במאגר שבו נמצאים הדיסקים של תמונת המקור, בלי קשר למה שמוגדר כאן.
לוחצים על Continue. התמונה האחרונה של האפליקציה משמשת ליצירת עותק וירטואלי, שמוצג למארח שבחרתם. מכיוון שמדובר בעותק וירטואלי של קובץ האימג', המארח יכול להשתמש בו בלי להשפיע על קובץ האימג' של הרפליקציה של StreamSnap.
פותחים את השירות Monitor במסוף הניהול של המכשיר כדי לראות את סטטוס המשימה.
כשהמשימה מסתיימת ב-Monitor עם סטטוס המשימה Succeeded, חוזרים ל-App Manager ומוודאים שהתמונה הועלתה בהצלחה.
אתם יכולים להתחבר למארח ולראות את תמונת המצב של יתירות הכשל כדי לוודא שהנתונים עקביים ושההליך של התאוששות מאסון הושלם.
אם אתם מרוצים מתוצאות בדיקת יתירות הכשל, מחקו את קובץ האימג' של בדיקת יתירות הכשל הפעילה.
מעבר למצב של יתירות באפליקציה מנוהלת או במכונה וירטואלית
בזמן יתירות הכשל, הרפליקציה של StreamSnap של הנתונים ממכשיר הגיבוי/השחזור המקומי נעצרת כדי להשתמש בעותק העדכני ביותר של האפליקציה או של קובץ האימג' של ה-VM במכשיר המרוחק. התמונה האחרונה של הנתונים זמינה כ-snapshot לכל מארח זמין. מכשיר הגיבוי/השחזור שומר באופן פנימי עותק נוסף של קובץ העזר, כך שאפשר להשתמש בתמונת המצב שנטענה כדי לכתוב נתונים בזמן שהאפליקציות ממשיכות לפעול במכשיר המרוחק.
במצב של מעבר לגיבוי בעת כשל, האפליקציה או ה-VM ניגשים ישירות לתמונה המרוחקת, כך שהשכפול למכשיר הגיבוי/השחזור המרוחק מושהה. כשהאפליקציה או המכונה הווירטואלית מוכנות לפעול מהמכשיר המקומי, אפשר לסנכרן את הנתונים בחזרה למכשיר המקומי ואז לבצע פעולת החזרה למצב תקין.
כדי להעביר אפליקציה או מכונה וירטואלית שמנוהלת על ידי StreamSnap למצב של יתירות כשל:
במסוף הניהול של מכשיר Backup and DR, לוחצים על App Manager ובוחרים באפשרות Applications בתפריט הנפתח.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית שרוצים להעביר, ואז בוחרים באפשרות Access מהרשימה הנפתחת בפינה הימנית התחתונה של הדף.
הדף גישה נפתח.
בוחרים תמונה בצילום מרחוק. כברירת מחדל, התמונה האחרונה נבחרת ליתירות כשל.
בוחרים באפשרות Failover מרשימת פעולות הגישה.
הדף Failover נפתח.
אם בחרתם תמונת אפליקציה ליתירות כשל, בחרו מארח מהרשימה הנפתחת Host. המארח שנבחר חייב להיות מארח SAN או מכונה וירטואלית בשרת ESX שמחובר למכשיר.
אם בחרתם קובץ אימג' של מכונה וירטואלית ליתירות כשל, בוחרים מיקום לביצוע יתירות הכשל: Existing Host או New Virtual Machine.
אם בוחרים באפשרות Existing Host, בוחרים מארח מהרשימה הנפתחת Host. המארח שנבחר חייב להיות מארח SAN או מכונה וירטואלית בשרת ESX שמחובר למכשיר.
אם בוחרים באפשרות New Virtual Machine, צריך לבחור את האפשרויות הבאות שספציפיות למכונה הווירטואלית:
- שם ה-VM: מזינים שם למכונה הווירטואלית החדשה שרוצים לטעון.
- VCENTER: בוחרים vCenter מהרשימה הנפתחת של המכונה הווירטואלית החדשה שרוצים לטעון.
- ESX HOST: בוחרים מארח ESX מהרשימה הנפתחת של המכונה הווירטואלית החדשה שרוצים לטעון.
- DATASTORE: בוחרים מהרשימה הנפתחת מאגר נתונים עם נפח האחסון הנדרש למכונה הווירטואלית החדשה שרוצים לטעון.
בקטע מצב טעינה, בוחרים אחת מהאפשרויות הבאות:
- vRDM (מיפוי וירטואלי של מכשיר גולמי): מצב vRDM נבחר כברירת מחדל. תמונות המצב של VMware מתייחסות ל-vRDM מחוברים כאל עצמאיים, והם לא נכללים בתמונות המצב. לכן, כברירת מחדל, Backup and DR לא כולל vRDMs כשמגנים על VM מותקן. ב-"Backup and DR" יש אפשרות להגדיר vRDM כתלויים. למרות שהאפשרות הזו לא בשימוש לעיתים קרובות, כשהיא מופעלת, vRDMs נכללים בתמונות המצב של VMware. תבניות לגיבוי נתונים מתעדות vRDMs שמסומנים כתלויים.
- pRDM (מיפוי פיזי של מכשיר גולמי): בחרו במצב הזה לפעולות שחזור ברמת הקובץ.
אם בוחרים באפשרות pRDM, מופיעות אפשרויות הטעינה הנוספות הבאות:
- Mount drive: מציינת אות כונן שתוקצה לאמצעי האחסון. אם אות הכונן לא זמינה, המשימה נכשלת. אם נמצאים כמה אמצעי אחסון, המערכת מקצה אותיות כונן עוקבות. אם לא מציינים כונן לטעינה, סוכן Backup and DR בוחר בעצמו אות לכונן, אם יש כזו.
- נקודת טעינה: הנתיב המלא שבו רוצים לטעון את אמצעי האחסון. אם הנתיב קיים כתיקייה ריקה, סוכן Backup and DR משתמש בו. אם הוא לא קיים, סוכן Backup and DR יוצר אותו. אם הוא קיים כקובץ או כתיקייה לא ריקה, המשימה תיכשל. אם צריך לטעון כמה אמצעי אחסון, סוכן Backup and DR בוחר את המשתמש שצוין לאחד מאמצעי האחסון, ולשאר הוא מוסיף קו תחתון (_) ואחריו מספר – לדוגמה, userspecified#.
אם צריך, משנים את ברירת המחדל של Storage pool שבו משתמשים לטעינה מהרשימה הנפתחת. ההגדרה הזו רלוונטית רק לטעינות שאין בהן דיסק קיים של אזור ביניים, כמו Direct to OnVault ותמונות OnVault מיובאות. אחרת, המערכת תמיד משתמשת במאגר שבו נמצאים הדיסקים של קובצי האימג' של המקור, בלי קשר למה שמוגדר כאן.
אם צריך, מזינים תווית לפעולת יתירות הכשל.
בקטע Map to ESX Hosts, בוחרים אחת מהאפשרויות הבאות:
- One: בוחרים באפשרות One אם רוצים למפות רק למארח ה-ESX שמפעיל את המכונה הווירטואלית המטורגטת.
- Two: בוחרים באפשרות הזו אם רוצים למפות לשני מארחי ESX, אבל לא לכל מארחי ה-ESX באשכול. אם בוחרים באפשרות שניים, אפשר לבחור את המארח השני או לבחור באפשרות בחירה אוטומטית. הבחירה האוטומטית בוחרת את המארח השני על סמך זוגות לוגיים של מארחי ESX, ותמיד יכולה לבחור את מארח ה-ESX השותף עבור המארח שמריץ את המכונה הווירטואלית המטורגטת.
- All: בוחרים באפשרות All כדי למפות את כל מארחי ה-ESX שקיימים באשכול. חשוב לזכור שאם בוחרים באפשרות All, יכול להיות שהמשימה תימשך יותר זמן.
לוחצים על Continue.
מופיעה הודעת אזהרה לאישור יתירות כשל.
מזינים FAILOVER בשדה כדי לאשר את הפעולה, ואז לוחצים על Failover. מתחילה משימת יתירות כשל. המשימה הזו מפסיקה כל משימת רפליקציה שמתבצעת באפליקציה הזו, ומציגה את התמונה המשוכפלת האחרונה למארח שנבחר.
כדי לראות את סטטוס המשימה, פותחים את שירות המעקב במסוף הניהול של המכשיר. כשהמשימה מסתיימת ב-Monitor עם סטטוס המשימה Succeeded, חוזרים ל-App Manager ומוודאים שהתמונה נטענה בהצלחה.
מתחברים למארח, פותחים את האפליקציה ומפנים את כל הלקוחות החיצוניים להשתמש בעותק הזה של האפליקציה.
כשתהיו מוכנים להחזיר את הנתונים שנוצרו באתר המרוחק לאתר המקומי, התחילו את החזרה למצב תקין מהמכשיר המרוחק.
חזרה למצב תקין מהמכשיר המרוחק לסביבת הייצור
במצב של יתירות כשל, המשתמשים במסוף הניהול של המכשיר יכולים להמשיך להשתמש באפליקציה וליצור בה נתונים, אבל אפליקציית Backup and DR פועלת מאימג' באתר המרוחק. אחרי שהאפליקציה עוברת למכשיר גיבוי/שחזור מרוחק, אפשר להחזיר אותה למכשיר הגיבוי/השחזור המקומי.
כדי לחזור למצב הקודם, צריך לשחזר את הנתונים העדכניים מתמונת הגיבוי לאפליקציה בסביבת הייצור, לשחזר את האפליקציה מהנתונים העדכניים ואז לבצע ניקוי. אחרי החזרה למצב תקין, מצב האפליקציה משתנה למוגן והשכפול למכשיר המרוחק מתחדש.
כדי לצמצם את זמן ההשבתה של האפליקציה במהלך מעבר חזרה ממכשיר הגיבוי/השחזור המרוחק למכשיר המקומי, צריך לבצע את הפעולות הבאות לפי הסדר.
- ביצוע סנכרון חוזר להשלמת פערים
- עצירת האפליקציה שהועברה למצב של מעבר לגיבוי בעת כשל
- ביצוע הסנכרון החוזר הסופי
- שחזור תמונה שסונכרנה
- מעבר חזרה למכשיר המקומי
- מחיקת תמונות של יתירות כשל וסנכרון חוזר
ביצוע סנכרון חוזר להשלמת פערים
כשמתחילים את תהליך החזרה למצב תקין, המשתמשים ניגשים לאפליקציה באתר המרוחק. בסנכרון החוזר הראשון, כל הנתונים שנוצרו באתר המרוחק מאז המעבר ליתירות כשל מועתקים לאתר המקומי. הסנכרון החוזר הראשון יכול להימשך זמן מה, בהתאם לרמת הפעילות של האפליקציה ולמשך הזמן שבו היא הייתה במצב של יתירות כשל.
כדי לבצע סנכרון חזרה במכשיר הגיבוי/השחזור המרוחק, פועלים לפי השלבים הבאים:
במסוף הניהול של מכשיר Backup and DR, לוחצים על App Manager ובוחרים באפשרות Applications מהרשימה הנפתחת.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית עם קובץ האימג' שרוצים לסנכרן בחזרה, ואז בוחרים באפשרות Access מהרשימה הנפתחת בתחתית הדף Applications.
הדף Access נפתח ומוצגות בו התמונות שצולמו בתצוגת ציר הזמן.
בחלון גישה, בוחרים את התמונה.
בוחרים באפשרות סנכרון חוזר מרשימת הפעולות.
הדף סנכרון חוזר נפתח.
אופציונלי: מזינים שם ייחודי שמשויך לתמונת הסנכרון החוזר בשדה Label.
לוחצים על שליחה.
מתחילה משימת סנכרון חוזר.
עוברים אל System כדי לראות את סטטוס המשימה.
כשהמשימה מסתיימת ב-Monitor עם סטטוס המשימה Succeeded, חוזרים אל App Manager.
הנתונים החדשים שנוצרו מהאפליקציה המרוחקת מוחזרים למכשיר הגיבוי/השחזור המקומי, אבל הם לא מוחלים באופן אוטומטי על קובץ האימג' המקורי של האפליקציה. במקום זאת, הוא זמין במכשיר הגיבוי/השחזור המקומי כתמונת syncback בחלון Access. אפשר לטעון, לשכפל או לשחזר תמונה מסונכרנת.
בשלב הבא צריך לעצור את האפליקציה שהועברה למצב של מעבר לגיבוי בעת כשל במהלך פעולת השחזור.
אם אתם עדיין לא מוכנים לבצע את פעולת השחזור, אתם יכולים לבצע פעולות סנכרון חוזר עד שתהיו מוכנים לחזור למצב תקין. כל אחד מהם יוצר קובץ אימג' חדש של syncback במכשיר הגיבוי או השחזור המקומי. אין הגבלה על מספר הפעמים שאפשר לבצע סנכרון חוזר.
הפסקת האפליקציה שעברה למצב מעבר לגיבוי בעת כשל
השלב הזה בתהליך מציין את תחילת הזמן שבו האפליקציה לא זמינה. עוצרים את האפליקציה באתר המרוחק כדי למנוע כניסה של נתונים חדשים אחרי שהסנכרון החוזר הסופי התחיל. האפליקציה לא פעילה במהלך שלב הסנכרון החוזר הסופי ושלב השחזור, וחוזרת לפעול בסוף שלב השחזור.
אחרי החזרה למצב תקין, סטטוס האפליקציה משתנה ל-Managed והרפליקציה לאתר המרוחק מתחדשת.
ביצוע הסנכרון החוזר הסופי
מכיוון שהאפליקציה פועלת במכשיר הגיבוי/השחזור המרוחק, יכול להיות שהנתונים במכשיר המרוחק השתנו במהלך הסנכרון החוזר. הסנכרון החוזר הסופי מהיר יותר כי הוא כולל פחות נתונים.
- חוזרים על התהליך שמתואר בקטע ביצוע סנכרון חוזר להשלמת פערים. הנתונים הסופיים מהאפליקציה המרוחקת מוחזרים למכשיר הגיבוי/השחזור המקומי.
- משחזרים את קובץ האימג' של Syncback כמו שמתואר במאמר שחזור קובץ אימג' של Syncback.
שחזור תמונה שסונכרנה
אחרי הסנכרון של האפליקציה או קובץ האימג' של המכונה הווירטואלית, אתם יכולים לבצע פעולת שחזור כדי להחזיר את הנתונים למיקום המקורי שלהם, או לבצע פעולת טעינה כדי לגשת לנתונים מהר יותר. ההנחיות הבאות יעזרו לכם לקבוע את הגישה האידיאלית, בהתאם לסוג הנתונים ולצרכים שלכם.
- באפליקציה שהיא לא VM, מומלץ לשחזר את נתוני האפליקציה מתמונת ה-syncback במקום לבצע פעולת טעינה. מידע נוסף זמין במאמר שחזור של אפליקציה או של תמונת syncback של VM. בסוגי אפליקציות שהם לא VM, ההעתקה הבאה חזרה לדיסק הייצור היא פעולה ידנית ובדרך כלל צריך לבצע אותה כשהמשתמשים לא צריכים גישה לנתונים האלה. במקרה כזה, שחזור תמונה הוא בדרך כלל האפשרות הכי טובה. השחזור מחליף את קובץ האימג' של האפליקציה שהיה בשימוש לפני יתירות הכשל בקובץ האימג' האחרון, שכולל שינויים ממכשיר הגיבוי/השחזור המרוחק.
לגבי מכונה וירטואלית, יש לכם את האפשרויות הבאות:
- אתם יכולים לבצע שחזור כדי להחזיר את המכונה הווירטואלית למיקום המקורי, כפי שמוסבר במאמר שחזור של אפליקציה או של תמונת סינכרון חוזר של מכונה וירטואלית. אם פעולת השחזור נמשכת זמן מה בגלל העברת הנתונים. בזמן הזה, המכונה הווירטואלית במצב אופליין. במקרה כזה, הגדרות הרשת וכתובת ה-MAC נשמרות כשמבצעים שחזור, כי הפעולה מעדכנת את הדיסקים במקום ליצור מחדש את ה-VM. ההגנה נשארת ללא שינוי, אבל מתבצעת פעולת splash נמוכה במהלך פעולת תמונת המצב הבאה, בגלל אובדן של נתוני מעקב אחר שינויים ב-VMware שנובעים מכל פעולת שחזור.
אפשר לטעון את ה-VM ל-VM חדש או ל-VM קיים, כפי שמוסבר במאמר טעינת קובץ אימג' של סנכרון חוזר של VM. כך מקבלים גישה מיידית למכונה הווירטואלית ולנתונים שלה, בלי לחכות לחלון השחזור. אם אתם מתכוונים לבצע פעולת טעינה ל-VM, שימו לב לשיקולי השימוש הבאים: אם אתם טוענים ל-VM קיים, יכול להיות שתקבלו דיסקים חדשים ב-VM הקיים, וזה לא בהכרח רצוי בסביבה שלכם. עם זאת, אם תמחקו קודם את הדיסקים המקוריים, יכול להיות שתוכלו להפעיל את ה-VM ולהשתמש ב-Storage vMotion. במקרה כזה, היתרון העיקרי הוא שהגילוי וההגנה הקודמים נשמרים. אם תטענו את הדיסק למכונה וירטואלית חדשה, תוכלו לשחזר את המכונה הווירטואלית. יכול להיות שתרצו לעדכן ידנית את כתובות ה-MAC כך שיתאימו ל-VM המקורי, כדי לשמור על הגדרות הרשת. אחר כך אפשר להשתמש ב-vMotion לאחסון כדי להעביר את המכונה הווירטואלית למאגר נתונים. תצטרכו לגלות מחדש את התוכן ולהגן עליו מחדש בשיטה הזו.
כדי לשחזר תמונת סנכרון חוזר של אפליקציה או של מכונה וירטואלית:
במסוף הניהול של מכשיר Backup and DR, לוחצים על App Manager ובוחרים באפשרות Applications בתפריט הנפתח.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית עם קובץ האימג' שרוצים לסנכרן בחזרה, ואז בוחרים באפשרות Access מהרשימה הנפתחת שבתחתית הדף Applications.
הדף Access נפתח ומוצגות בו התמונות שצולמו בתצוגת ציר הזמן.
לפני שמשחזרים, חשוב לשים לב לשיקולים הבאים:
- אם אתם משחזרים אפליקציה שהיא לא מכונה וירטואלית, הקפידו לסגור את האפליקציה ולבטל את הטעינה של מערכת הקבצים.
- אם אתם משחזרים מכונה וירטואלית, הליך השחזור מכבה אותה באופן אוטומטי.
בוחרים את קובץ האימג' האחרון של הסנכרון לאחור, ואז בוחרים באפשרות Restore מרשימת פעולות הגישה.
הדף Restore ייפתח.
לוחצים על שליחה. תיפתח תיבת דו-שיח עם אזהרה. קוראים את ההודעה ומזינים את הטקסט DATA LOSS כדי לאשר. מופיעה אזהרה שנייה. מזינים את הביטוי OVERWRITE OTHER APPS כדי לאשר את פעולת השחזור.
משימת השחזור מתחילה.
עוברים אל Monitor כדי לוודא שפעולת השחזור בוצעה בהצלחה. כשהמשימה מסתיימת ב-Monitor עם סטטוס המשימה Succeeded, חוזרים אל App Manager.
אחרי שפעולת השחזור מסתיימת בהצלחה:
- באפליקציה שהיא לא VM, טוענים את מערכת הקבצים ומפעילים מחדש את האפליקציה.
- באפליקציה של מכונה וירטואלית, מפעילים את המכונה הווירטואלית.
האפליקציה בסביבת הייצור חזרה לפעול, אבל היא עדיין לא מנוהלת. ממשיכים לפעולת החזרה למצב תקין, שמתוארת בקטע חזרה למצב תקין במכשיר המקומי.
מעבר חזרה למכשיר המקומי
במהלך החזרה למצב תקין, נמחקות תמונות ה-syncback שהוחזרו ממכשיר הגיבוי/השחזור המרוחק, וגם תמונת יתירות הכשל שעשויה עדיין להיות מותקנת במכשיר הגיבוי/השחזור המרוחק. בנוסף, בתהליך החזרה למצב תקין נמחקות כל התמונות של בדיקת יתירות הכשל שנשארו במכשיר הגיבוי/השחזור המרוחק. אחרי השלבים האלה, האפליקציה ממשיכה את השכפול של נתוני האפליקציה באמצעות StreamSnap מהמכשיר המקומי למכשיר המרוחק.
כדי להחזיר אפליקציה מהמכשיר המרוחק למכשיר המקומי, צריך לפעול לפי ההוראות הבאות.
במסוף הניהול של מכשיר Backup and DR, לוחצים על App Manager ובוחרים באפשרות Applications בתפריט הנפתח.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית שרוצים להחזיר למצב הקודם, ואז בוחרים באפשרות Access מהרשימה הנפתחת שבתחתית הדף Applications.
הדף Access נפתח ומוצגות בו התמונות שצולמו בתצוגת ציר הזמן.
בוחרים את קובץ האימג' האחרון ובוחרים באפשרות Failback מרשימת פעולות הגישה.
הדף Failback נפתח.
לוחצים על שליחה.
עוברים אל Monitor כדי לראות את סטטוס המשימה. כשהמשימה מסתיימת ב-Monitor עם סטטוס המשימה Succeeded, חוזרים אל App Manager.
אחרי שהמעבר חזרה למצב תקין מסתיים בהצלחה, הרפליקציה של StreamSnap למכשיר המרוחק ממשיכה.
אחרי החזרה למצב תקין, סטטוס האפליקציה משתנה ל-Managed והרפליקציה לאתר המרוחק ממשיכה.
טעינת קובץ אימג' של VM syncback
כך טוענים קובץ אימג' של סנכרון חוזר של VM.
במסוף הניהול של מכשיר Backup and DR, לוחצים על הכרטיסייה App Manager ובוחרים באפשרות Applications בתפריט הנפתח.
הדף Applications ייפתח.
בוחרים את האפליקציה או את המכונה הווירטואלית עם קובץ האימג' שרוצים לסנכרן בחזרה.
בוחרים באפשרות Access מהרשימה הנפתחת בתחתית הדף Applications.
הדף Access נפתח ומוצגות בו התמונות שצולמו בתצוגת ציר הזמן.
בוחרים את התמונה האחרונה שסונכרנה.
בוחרים באפשרות טעינה מרשימת הפעולות. מופיע החלון Mount. לפרטים על טעינת קובץ אימג' של VM, ראו טעינת קובצי אימג'.
נכנסים ל-Monitor כדי לוודא שפעולת הטעינה של קובץ האימג' של המכונה הווירטואלית בוצעה בהצלחה.
אחרי שהפעולה של טעינת קובץ האימג' של המכונה הווירטואלית מסתיימת בהצלחה, מפעילים את המכונה הווירטואלית, אם צריך, ומבצעים Storage vMotion כדי להעביר את הדיסקים שנטענו או את המכונה הווירטואלית למאגר הנתונים הרצוי.
אם התקנתם את הגיבוי במכונה וירטואלית חדשה, צריך לזהות את המכונה הווירטואלית הזו לפני שאפשר יהיה להגן עליה שוב. מבצעים את התהליך לזיהוי מכונות וירטואליות, כמו שמוסבר במאמר זיהוי מכונות וירטואליות.
המכונה הווירטואלית בסביבת הייצור חזרה לפעול, אבל היא עדיין לא מוגנת. ממשיכים לפעולת החזרה למצב תקין, שמתוארת בקטע חזרה למצב תקין במכשיר המקומי.
מחיקת תמונות של יתירות כשל וסנכרון חוזר
בדרך כלל, כל קובצי האימג' של האפליקציה שנוצרו במהלך יתירות כשל, בדיקת יתירות כשל וסנכרון חוזר נמחקים כשמבצעים את פעולת החזרה למצב תקין. במקרים נדירים, יכול להיות שחלק מהתמונות שנוצרו כחלק מרפליקציית StreamSnap של אפליקציה לא יימחקו.
כדי למחוק תמונת מצב של יתירות כשל, בדיקת יתירות כשל או סנכרון חוזר ממכשיר הגיבוי או השחזור המרוחק, צריך לפעול לפי ההוראות הבאות.
בדף Access, בוחרים את התמונה של ה-failover, ה-test-failover או ה-syncback שרוצים למחוק, ואז לוחצים על Delete ברשימה הנפתחת שבפינה הימנית התחתונה של הדף.
בתיבת הדו-שיח Delete שנפתחת, לוחצים על Submit כדי לאשר את השינויים.