שחזור גיבויים שנשמרו לטווח ארוך

אתם יכולים לשחזר גיבויים שנשמרו לטווח ארוך ישירות מקטגוריות של Cloud Storage באמצעות כלי עצמאי, וכך להבטיח גישה לנתונים גם בלי מכשירי Backup and DR פעילים.

במאמר הזה מוסבר איך להשתמש בכלי השחזור העצמאי הזה כדי לגלות, לאמת, לטעון ולשחזר תמונות גיבוי של Backup and DR OnVault ושל Compute Engine.

סקירה כללית

גיבויים שנשמרים לטווח ארוך מאוחסנים בקטגוריות של Cloud Storage באמצעות מדיניות OnVault לצורך תאימות וארכיון. כדי להבטיח שהנתונים יהיו נגישים באופן עצמאי מתשתית הגיבוי, אפשר להשתמש בכלי שחזור עצמאי כדי לגלות, לאמת ולשחזר את הנתונים האלה ישירות מקטגוריית האחסון. זה קריטי לתרחישי תוכנית התאוששות מאסון (DR) או להוצאה משימוש, שבהם יכול להיות שהמכשיר המקורי לגיבוי או לשחזור לא יהיה זמין.

לפני שמתחילים

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

קבלת התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות לשחזור גיבויים שנשמרו לטווח ארוך, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Backup and DR Cloud Storage Operator (roles/backupdr.cloudStorageOperator) בקטגוריית Cloud Storage של היעד. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

דרישות מוקדמות אחרות

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

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

2. בתרחישי שחזור שכוללים תמונות מצב של Persistent Disk, צריך לוודא שכל המטא-נתונים של הגיבוי משוכפלים לקטגוריית Cloud Storage של היעד. כדי לקטלג ולעבד תמונות של מצב המערכת, כלי השחזור מסתמך על המטא-נתונים האלה. כדי להקל על העברת הנתונים ולוודא שהמטא-נתונים נמצאים בקטגוריה של Cloud Storage, צריך לפנות ל-Cloud Customer Care.

   הערה: ההעברה הזו היא השלב האחרון לפני מחיקת ה-appliance. לא ניתן לשחזר שינויים או גיבויים חדשים שנוצרו אחרי השלב הזה.

3. חשוב לוודא שמערכת המארח שבה מריצים את הכלי הזה עומדת בדרישות הבאות:

   • ‫ה-CLI של gcloud: מותקן ונגיש במשתנה הסביבה PATH (במיוחד gcloud storage).
   • אימות: מוגדר עם פרטי כניסה פעילים על ידי הפעלת gcloud auth login, או באמצעות Application Default Credentials‏ (ADC) או מפתחות של חשבון שירות.

4. כדאי לזהות את השמות של קטגוריות של Cloud Storage ואת מזהי הפרויקט התואמים Google Cloud שלהן ולשמור רשימה שלהם כדי להשתמש בהם בכלי השחזור.

פריסת כלי השחזור

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

גילוי מכשירי חשמל, מארחים ותמונות

כלי השחזור העצמאי מקבל זוג ערכים של קטגוריה ופרויקט (--bucket ו---project) לפקודות. כלי השירות תומך בפעולות הבאות:

• הצגת רשימת אפליקציות
• הצגת רשימת הגיבויים
• תפוגת תוקף של גיבויים
• הוספת תמונת גיבוי
• ביטול הטעינה של תמונת גיבוי

הרכבת תמונת הגיבוי

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

מציגים את רשימת הגיבויים הזמינים כדי לזהות את שם תמונת הגיבוי:

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

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

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

מחליפים את מה שכתוב בשדות הבאים:

• ‫BUCKET_NAME: שם הקטגוריה ב-Cloud Storage.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫APPLIANCE_NAME: השם או המזהה של המכשיר לגיבוי או לשחזור.
• ‫HOST_NAME: שם המארח או המזהה של מארח המקור.
• ‫APPLICATION_NAME: השם או המזהה של האפליקציה המוגנת.
• ‫IMAGE_NAME: השם של תמונת הגיבוי הפעילה שצריך לטעון.
• ‫MOUNT_POINT: (אופציונלי) נתיב הספרייה המקומית שאליה הגיבוי מועלה. ערך ברירת המחדל הוא /tmp/recovery_folder.

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

שחזור אפליקציות

כדי לגשת לקובצי מסד נתונים גולמיים, עוברים אל MOUNT_POINT/restored_data/. בוחרים את נתיב השחזור לסוג עומס העבודה ולהגדרת ההרכבה:

Microsoft SQL

1. איתור קבצים: מזהים את קובצי מסד הנתונים הראשיים .mdf ו-.ldf בספרייה db_volume/.
2. צירוף ישיר (אותו מארח): מפסיקים את מופע מסד הנתונים של היעד. פותחים את SQL Server Management Studio, בוחרים באפשרות Attach Database ומציינים את נתיבי הקבצים שמצביעים על קובצי הנתונים וקובצי היומן בספריית נקודת הטעינה של השחזור.
3. העתקה וצירוף (מארח שונה): עצירה של מופע מסד הנתונים של היעד. מעבירים את הקבצים .mdf ו-.ldf לכונני האחסון המקומיים של שרת היעד, ואז מצרפים אותם באמצעות SQL Server Management Studio.

Oracle

1. איתור קבצים: כלי השירות מזהה באופן אוטומטי קבצים מסוג init.ora או spfile וקבצי נתונים מסוג .dbf, תוך כדי העברת הגיבוי של מסד הנתונים של RMAN וקבוצות הנפחים Archive log למצב אונליין.
2. שחזור מסד נתונים: משביתים את מופע היעד של Oracle או מפעילים אותו במצב NOMOUNT. אפשר לעדכן את פרמטרי האתחול (כמו קובצי בקרה) כך שיצביעו על קובצי .dbf שמוצמדים לאימות ישיר, או להעתיק את קובצי .dbf לאחסון מקומי או לאחסון של ניהול אחסון אוטומטי (ASM) לשחזור קבוע.
3. פתיחת מסד נתונים: מעבירים את המכונה לסטטוס MOUNT, מחילים יומני שחזור נדרשים מקבוצת עוצמת הקול TransactionLog המצורפת, ואז פותחים את מסד הנתונים.

מכונה וירטואלית ב-VMware Engine

בנוסף לשחזור אפליקציות של מסדי נתונים, ההגנה על מכונות וירטואליות (VM) ב-Google Cloud VMware Engine (VMware Engine) כוללת את כל הגדרות החומרה לצד היקפי הדיסק הווירטואלי.

1. התקנה ואיתור קבצים: מתקינים את תמונת הגיבוי כמו שמתואר במאמר התקנת תמונת הגיבוי. כלי השירות יוצר את הדיסק הווירטואלי הדליל (vol00.raw) בנתיב ההרכבה הראשי. לאחר מכן, הכלי מצרף את הדיסק כדי לחשוף את מערכת הקבצים של מערכת ההפעלה האורחת בספרייה db_volume/, בזמן שהמטא-נתונים של הגדרות VMware (כולל .ovf, ‏ .vmx ו-Catalog.xml) מאורגנים בתיקייה log_files/.
2. שחזור ישיר של המכונה הווירטואלית: משביתים את מכונת היעד כדי לאבטח את דיסק הבסיס שלה לצורך ניתוח המניפסט. תהליך worker קורא בלוקים של נתונים מאחסון מקומי, כותב אותם ב-VMDK באמצעות ספריות VMware Virtual Disk Development Kit ‏ (VDDK), ואז מפעיל מחדש את המכונה הווירטואלית באופן אוטומטי.

קובצי snapshot של PD ב-Compute Engine

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

1. זיהוי גיבוי ומטא-נתונים של יעד: מוודאים שקובץ קטלוג המטא-נתונים של תמונת מצב של Persistent Disk‏ (pdsnapshot_catalog.json) נמצא בדלי של Cloud Storage. משתמשים בכלי השירות לניהול דיסקים קשיחים קבועים כדי לבדוק את הגיבויים הזמינים שמופיעים בקטלוג, ובוחרים את הגיבוי הספציפי IMAGE ID שרוצים לשחזר.
2. שחזור של נפחים וצירוף שלהם: משתמשים בפקודה attach כדי ליצור באופן אוטומטי דיסקים מתמידים מקובצי snapshot של גיבויים. פעולה אחת מטפלת ביצירה ובחיבור של כל אמצעי האחסון הרלוונטיים למכונה הווירטואלית של היעד.
3. התקנת מכשירים ברמת מערכת ההפעלה: אחרי שהחיבור מסתיים, מתחברים למכונת Compute Engine היעד כדי לזהות את מכשירי הבלוק החדשים שמופו באמצעות כלים כמו lsblk. מבצעים הרכבה ידנית של מערכות הקבצים כדי לגשת לנתונים ששוחזרו או מפעילים את תהליך שחזור האפליקציה.

‫SAP HANA PD

בניגוד לגיבויים ב-OnVault, שמוצמדים ישירות כמערכות קבצים מקומיות, שחזור של תמונות מצב של דיסק אחסון מתמיד ב-SAP HANA כולל הקצאה של דיסקים חדשים של אחסון מתמיד וצירוף שלהם למכונת היעד של Compute Engine.

1. אימות המטא-נתונים ואיתור תמונת הגיבוי: מוודאים שקובץ קטלוג המטא-נתונים של תמונת ה-Persistent Disk זמין בקטגוריה של Cloud Storage. משתמשים בכלי לניהול דיסקים קבועים כדי לבדוק גיבויים שמופיעים בקטלוג ולבחור את IMAGE ID שנדרש לשחזור.
2. הקצאת דיסקים וצירוף אמצעי אחסון: מריצים את הפקודה attach כדי ליצור באופן אוטומטי דיסקים מתמידים מתוך הגיבוי שנבחר. בשלב הזה נוצרים כל אמצעי האחסון הנדרשים והם מצורפים למכונה הווירטואלית של היעד בפעולה אחת.
3. הרכבת מכשירים ברמת מערכת ההפעלה: אחרי שמחברים את הדיסקים, מתחברים ל-VM של SAP HANA ליעד ובודקים אם יש מכשירי בלוק חדשים שהוקצו באמצעות כלים כמו lsblk. כדי לגשת לנתונים ששוחזרו או להתחיל בשחזור ברמת האפליקציה, צריך לטעון את מערכות הקבצים באופן ידני.
4. שחזור SAP HANA: אחרי שמפעילים את אמצעי האחסון של נתוני SAP HANA, את היומן ואת יומן הארכיון, מפעילים את מסד הנתונים של המערכת (כולל שחזור לנקודת זמן מסוימת אם נדרש), ואז משחזרים ומאתחלים את מסדי הנתונים של הדיירים.

IBM Db2 PD

בניגוד לגיבויים ב-OnVault, שמועלים ישירות כמערכות קבצים מקומיות, שחזור של תמונות מצב של דיסק אחסון מתמיד של IBM Db2 מחייב הקצאה של דיסקים חדשים של אחסון מתמיד וצירוף שלהם למכונת היעד של Compute Engine.

1. איתור תמונת הגיבוי ואימות המטא-נתונים: מוודאים שקובץ קטלוג המטא-נתונים של תמונת ה-Persistent Disk נמצא בקטגוריה הייעודית של Cloud Storage. כדי לבדוק את הגיבויים שמופיעים בקטלוג, לזהות את IMAGE ID שנדרש לשחזור ולבחור אותו, משתמשים בכלי לניהול דיסקים קבועים.
2. צירוף אמצעי אחסון והקצאת דיסקים: מריצים את הפקודה attach כדי ליצור באופן אוטומטי דיסקים של אחסון מתמיד (persistent disks) מתוך קובץ ה-snapshot של הגיבוי שצוין. בשלב אחד, המערכת מקצה את כל אמצעי האחסון הנדרשים ומצרפת אותם ישירות למכונה הווירטואלית של היעד.
3. הרכבה של מערכות קבצים של מערכת ההפעלה: אחרי שמצרפים את הדיסקים, מתחברים למכונת ה-VM של IBM Db2 כדי לזהות התקני בלוקים שמופו לאחרונה באמצעות כלים כמו lsblk. כדי לגשת לנתונים ששוחזרו או להמשיך בשחזור האפליקציה, צריך לטעון את מערכות הקבצים באופן ידני.
4. שחזור מסד נתונים של אפליקציה: אחרי שמקשרים את נפחי הנתונים של Db2, את יומן העסקאות ואת יומן הארכיון, צריך לקטלג כל מופע של מסד נתונים של Db2, לבצע שחזור של מסד הנתונים לפי הצורך ולהעביר את מסד הנתונים למצב אונליין.

‫MySQL/MariaDB

1. איתור קבצים: מאתרים את ספריית הנתונים הראשית ב-db_volume/, שמכילה מסדי נתונים של משתמשים, סכימה של המערכת ומרחבי טבלאות של InnoDB.

2. שחזור מסד נתונים: מפסיקים את שירות MySQL או MariaDB הפעיל. כדי לבדוק ישירות, משנים את הערך datadir ב-my.cnf כך שיכוון לתיקיית השחזור. כדי לשחזר את הנתונים באופן קבוע, מעתיקים את קובצי מסד הנתונים לאחסון מקומי (כמו /var/lib/mysql/) ומוודאים שהבעלות וההרשאות של מערכת הקבצים נכונות.

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

3. העלאה אונליין ושחזור: הפעלה מחדש של שירות מסד הנתונים. אם קיימים יומני עסקאות בינאריים, מבצעים שחזור מערכת מנקודה מסוימת בזמן (PITR) באמצעות כלי השירות mysqlbinlog.

PostgreSQL

1. איתור קבצים: בספרייה db_volume/, מזהים את הנכסים PGDATA, כולל מסדי נתונים מרכזיים (base/, global/ ו-pg_wal/) וקובץ ההגדרות postgresql.conf.

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

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

3. Open database: מפעילים מחדש את השירות כדי להעלות את המופע לאונליין. אם נדרש שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך להחיל יומני WAL בארכיון מהתיקייה log_files/ על ידי הגדרת קובץ recovery.conf או קביעת ההגדרה restore_command בתוך postgresql.conf (ל-PostgreSQL 12 ואילך), ואז להעביר את מסד הנתונים למצב אונליין.

SAP ASE

1. איתור קבצים: זיהוי המכשיר הראשי, לצד מסד נתונים ספציפי של משתמשים ומכשירי יומן, שנמצאים בתיקייה db_volume/ המותקנת.

2. שחזור מסד נתונים: השבתה של מכונת היעד של SAP ASE. כדי לבצע הרכבה ישירה, צריך לעדכן את ההגדרה RUN_server כדי להפנות את הפרמטר של מכשיר האב (כמו -d) לנתיב השחזור. אפשרות אחרת היא להעביר את כל נכסי המכשיר למיקומי האחסון הקבועים שלהם.

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

3. Open database (פתיחת מסד נתונים): מפעילים את התהליך של שרת הנתונים SAP ASE. אם קיימים יומני טרנזקציות, מריצים את הפעולה LOAD TRAN כדי לבצע שחזור מערכת מנקודה מסוימת בזמן (PITR) לפני שמחזירים את מסד הנתונים למצב אונליין.

SAP MaxDB

1. איתור נפחים: עוברים אל נתיב ההרכבה db_volume/ כדי למצוא את קובצי הנתונים והיומן הראשיים של SAP MaxDB.

2. שחזור או הפניה אוטומטית של ההגדרה: מפסיקים את תהליך היעד SAP MaxDB. אפשר להשתמש במנהל מסדי הנתונים (dbmcli) כדי לעדכן פרמטרים כמו DataVolumeName כך שיצביעו על נקודת השחזור, או להעתיק את הקבצים ישירות לאחסון מקומי כדי לבצע שחזור מלא.

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

3. הפעלה והעברה למצב אונליין: מפעילים את מופע מסד הנתונים ומגדירים את הסטטוס התפעולי שלו לערך ONLINE באמצעות Database Manager.

SAP IQ

1. איתור קבצים: עוברים לספרייה db_volume/ כדי לזהות את חנות SAP IQ הראשית, את חנות הקטלוג (.db) ואת כל הנכסים הזמניים שמשויכים לחנות.

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

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

3. פתיחת מסד נתונים: מריצים את כלי השירות start_iq כדי להעלות את המופע לאונליין ולאמת את תקינות הנתונים.

IBM Db2 LVM/dump

1. איתור קבצים: עוברים אל db_volume/ ונתיבי הטעינה log_files/. בהתאם לשיטת ההגנה, מזהים את נפחי הנתונים והיומנים של LVM או את נכסי התמונות הספציפיים של הגיבוי לשחזור מבוסס-dump.
2. שחזור מסד נתונים (LVM): כיבוי של מופע היעד של Db2. מעבירים את נתוני מסד הנתונים ואת נפחי יומן הטרנזקציות הפעיל מההרכבה של השחזור לאחסון המקומי של היעד, ומוודאים שהבעלות על מערכת הקבצים נכונה עבור המשתמש והקבוצה של Db2.
3. שחזור מסד נתונים (מלא ואינקרמנטלי על בסיס dump): עצירת חיבורים פעילים ומחיקת מסד הנתונים של היעד אם הוא קיים. משתמשים בכלי db2ckrst עם חותמת הזמן הספציפית של הגיבוי כדי ליצור קטלוג של הרצף המצטבר הנדרש. מריצים את הפעולה RESTORE לכל תמונה בסדר שנקבע.
4. פתיחת מסד נתונים: מפעילים את מופע Db2. אם מסד הנתונים נשאר במצב 'בהמתנה' או שנדרש שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך להחיל את יומני העסקאות באמצעות כלי השירות db2 rollforward כדי להשלים את השחזור ולהעביר את המופע למצב אונליין.

פינוי משאבים

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

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

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

מחליפים את מה שכתוב בשדות הבאים:

• ‫MOUNT_POINT: הנתיב של הספרייה המקומית שאליה הועלה הגיבוי, למשל /tmp/recovery_folder.

המאמרים הבאים

• סקירה כללית של פעולות שחזור
• מעקב אחר משרות במסוף Google Cloud
• ניהול הגיבויים במסוף Google Cloud
• יומני ביקורת