סקירה כללית על Backup and DR למסוף הניהול

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

Backup and DR למסוף הניהול מתעד נתונים בפורמט מצטבר תמידי, ומאחסן אותם בפורמט המובנה שלו שניתן לקריאה על ידי אפליקציות. הגיבויים מאוחסנים באופן מקורי ולא כארכיוני גיבוי קנייניים, ולכן אתם יכולים לטעון באופן מיידי קובצי אימג' של גיבוי ישירות ממכשיר גיבוי/שחזור כדי לשחזר עומסי עבודה, להקצות עותקים וירטואליים לבדיקה ולפיתוח, או להעביר נתונים עם זמן השבתה מינימלי.

הוצאה משימוש של Backup and DR במסוף הניהול

Google Cloud ב-30 בספטמבר 2027 תופסק התמיכה של Backup and DR במסוף הניהול של המכשיר הקודם (IaaS stack) ובעומסי העבודה המשויכים אליו שמנוהלים על ידי המשתמשים. כדי לשמור על הגנה על נתונים רציפה, כדאי לתכנן את המעבר לשיטות גיבוי חלופיות בהקדם האפשרי.

עומסי עבודה שמושפעים מהוצאה משימוש של מסוף הניהול

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

  • מכונות Compute Engine שמנוהלות דרך מסוף הניהול של המכשיר
  • מסדי נתונים של IBM Db2
  • מסדי נתונים של Oracle
  • מסדי נתונים של SAP HANA
  • מסדי נתונים של Microsoft SQL Server
  • מכונות וירטואליות של Google Cloud VMware Engine
  • אפליקציות כלליות וקבוצות של אפליקציות עקביות
  • מערכות קבצים בניהול המשתמש (מערכות קבצים של Linux ו-Windows, מצב המערכת, NFS ו-SMB/CIFS)

ההוצאה משימוש לא משפיעה על שירותים מנוהלים של Google שמוגנים ישירות דרך מסוףGoogle Cloud , כולל מכונות וירטואליות של Compute Engine, דיסקים לאחסון מתמיד, Cloud SQL, ‏AlloyDB ל-PostgreSQL ו-Filestore.

ציר הזמן וציוני הדרך של ההוצאה משימוש

הוצאה משימוש של Backup and DR למסוף הניהול מתבצעת בשלושה שלבי אכיפה עיקריים:

  • ‫31 בדצמבר 2026 (מחיקת שרת ניהול לא פעיל): כל שרת ניהול בפרויקט נמחק באופן אוטומטי אחרי 30 ימים רצופים של חוסר פעילות. שרת ניהול נחשב לא פעיל רק אם אין לו גיבויים פעילים, אפליקציות או עומסי עבודה מוגנים ומשימות גיבוי פעילות.
  • ‫30 בספטמבר 2027 (הקפאת הגיבוי): סיום התמיכה ביצירת גיבויים חדשים באמצעות המחסנית של מסוף הניהול הקודם של המכשיר. אם לא תעבירו את הנתונים לפני תאריך היעד, לא תוכלו ליצור גיבויים חדשים של עומסי העבודה הרלוונטיים.
  • ‫31 במרץ 2028 (מועד אחרון לשחזור): סיום היכולות לשחזור ישיר דרך ממשק מסוף הניהול של המכשיר הקודם. כדי לשחזר גיבויים אחרי תאריך הסיום, צריך להשתמש בסקריפטים ובכלי השחזור הנפרדים של שמירה לטווח ארוך (LTR).

חלופות להעברה של עומסי עבודה במסוף הניהול

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

עומס עבודה אפשרות העברה חומרי עזר
Compute Engine גיבויים מקוריים של Google ל-Compute Engine העברת מכונות של Compute Engine לארכיטקטורה ללא מכשירים באמצעות Google Cloud Backup and DR למכונות של Compute Engine.
מסדי נתונים בניהול המשתמש (IBM Db2,‏ Oracle,‏ SAP HANA,‏ Microsoft SQL Server ואחרים) גיבויים בכספת שכוללים ריקון מידע באמצעות סקריפטים בהתאמה אישית משתמשים בגיבויים של מכונות וירטואליות ושל Persistent Disk ב-Compute Engine ב- Google Cloud Backup and DR עם מסגרת guest-flush, בשילוב עם סקריפטים בהתאמה אישית לגיבויים שכוללים ריקון מידע וגיבויים שאי אפשר לשנות.
SAP HANA גיבויים מבוססי-סוכנים Google Cloud משתמשים בסוכן Backint המקורי של Google Cloud או בתמונות מצב של Persistent Disk. אפשר לעיין במדריך לגיבוי ולשחזור של Agent for SAP Backint או במדריך לגיבוי ולשחזור של קובץ snapshot של דיסק.
עומסי עבודה כלליים של מכונות וירטואליות תמונות מצב מקוריות Google Cloud של הדיסק להגדיר תמונות מצב רגילות או של ארכיון כדי לגבות מדי פעם דיסקים וירטואליים, באמצעות המדריך לתמונות מצב של דיסקים.
כל עומסי העבודה פתרונות של צד שלישי ב-Marketplace להפעיל פתרונות גיבוי חלופיים שאושרו לארגונים וזמינים ב-Google Cloud Marketplace.

שמירה ושחזור של גיבויים אחרי 31 במרץ 2028

כדי לשמור על יכולות השחזור של הגיבויים אחרי המועד האחרון לשחזור ב-31 במרץ 2028, צריך להעביר את נתוני הגיבויים מהדור הקודם לאחסון ב-OnVault ב-Cloud Storage לפני שהמכשירים יושבתו:

  1. הקצאת כללי מדיניות של OnVault: העברת כל הגיבויים הקריטיים מהמערכת הקודמת לקטגוריות של Cloud Storage OnVault.
  2. סנכרון מטא-נתונים: לפני שאתם מכבים את המכשירים המקומיים, ודאו שכל המטא-נתונים של קובצי ה-snapshot של Persistent Disk מסונכרנים באופן מלא עם הקטגוריה של Cloud Storage. כדי לאמת ולהשלים את העברת המטא-נתונים, פנו לכתובת gcbdr-umdb-transition@google.com או לCloud Customer Care.
  3. שימוש בכלי השחזור: משתמשים בכלי ובסקריפטים הנפרדים כדי למצוא ולטעון קובצי אימג' לגיבוי של OnVault ושל Persistent Disk ישירות מהקטגוריות של Cloud Storage. הוראות מפורטות מופיעות במאמר שחזור גיבויים שנשמרו לטווח ארוך.

אם יש לכם שאלות או שאתם צריכים עזרה בתכנון המעבר, אתם יכולים לפנות לצוות המעבר בכתובת gcbdr-umdb-transition@google.com, ל-Cloud Customer Care או לצוות ניהול החשבון שלכם ב- Google Cloud.

ההבדלים בין Backup and DR למסוף הניהול לבין Google Cloud Backup and DR

Google מציעה שני מודלים שונים של ניהול וארכיטקטורה עבור Backup and DR:

  • Backup and DR למסוף הניהול (קבוצת המסמכים הזו): ארכיטקטורה שמבוססת על מכשירים, שבה אתם פורסים ומנהלים מכשירי גיבוי/שחזור ברשת של הענן הווירטואלי הפרטי (VPC) שלכם, ומנהלים את ההגנה באמצעות מסוף הניהול הייעודי של המכשיר שמבוסס-אינטרנט. החבילה הזו מיועדת למסדי נתונים בניהול עצמי (כמו Oracle,‏ Microsoft SQL Server,‏ SAP HANA ו-IBM Db2), למכונות וירטואליות של Google Cloud VMware Engine ו-VMware vSphere, למערכות קבצים ולעומסי עבודה שדורשים טעינות מיידיות עם Application Awareness, שיבוטים של מסדי נתונים וירטואליים (LiveClones) או תהליכי עבודה אוטומטיים של Backup and DR.
  • ‫Google Cloud Backup and DR: חוויית גיבוי מבוססת-ענן שמנוהלת על ידי SaaS ומשולבת ישירות במסוףGoogle Cloud , ב-ה-CLI של gcloud, ב-backupdr API וב-Terraform. בעזרתGoogle Cloud Backup and DR, אתם יכולים להגן על משאבים מקוריים Google Cloud – כמו מכונות Compute Engine, דיסקים קבועים ו-Google Cloud Hyperdisks, מכונות Cloud SQL, אשכולות AlloyDB ומכונות Filestore – ישירות בכספות גיבוי קבועות בניהול Google, בלי לפרוס או לנהל מכשירי גיבוי או שחזור.

בטבלה הבאה מסוכמים ההבדלים העיקריים בין שתי חבילות השירות של Backup and DR:

תכונה ‫Backup and DR למסוף הניהול Google Cloud Backup and DR
ממשק הניהול הראשי מסוף ייעודי לניהול מכשירים מבוססי-אינטרנט ו-Management Console API Google Cloud מסוף, ה-CLI של gcloud, ‏API של backupdr ו-Terraform
ארכיטקטורה ומישור נתונים ארכיטקטורת מכשיר תלת-שכבתית שמורכבת ממסוף ניהול המכשיר, ממכשירי גיבוי/שחזור שהלקוח פורס (מכונות וירטואליות של Compute Engine ב-VPC) ומסוכני Backup and DR קלים במארחים של עומסי העבודה. מישור שירות של Google בניהול מלא; לא נדרשים סוכני אורח או מכשירי גיבוי/שחזור שנפרסו על ידי הלקוח למשאבים בכספת שמותאמים למסוף
מודל הגדרת הגיבוי תבניות לגיבוי נתונים (שמכילות מדיניות של תמונת מצב, OnVault ורפליקציה) בשילוב עם פרופילים של משאבים תוכניות גיבוי וכללי גיבוי שמוגדרים במסוף ומשויכים ישירות לכספת גיבוי ייעודית
יעדי אחסון מאגרי אחסון שמנוהלים על ידי מכשיר (מאגר ראשי, מאגר תמונות מצב ב-Persistent Disk, מאגר OnVault ב-Cloud Storage ומאגר מראות במכשיר מרוחק), וגם כספות גיבוי שמנוהלות על ידי Google לעומסי עבודה נתמכים כספות גיבוי שמנוהלות על ידי Google, לא ניתנות לשינוי או למחיקה, עם שמירה כפויה ואחסון אזורי או במספר אזורים
שחזור וגישה לנתונים שחזור מלא, טעינות רגילות מיידיות, טעינות עם מודעות לאפליקציות, עותקים וירטואליים (LiveClones), טעינה והעברה ותהליכי עבודה אוטומטיים של Backup and DR שחזור ישיר למשאבים חדשים או קיימים ב- Google Cloud מכספת גיבוי
עומסי עבודה נתמכים ‫Google Cloud VMware Engine, מכונות וירטואליות של VMware vSphere, מכונות של Compute Engine, מערכות קבצים של Linux ו-Windows (כולל NFS,‏ SMB ו-Filestore),‏ Oracle,‏ Microsoft SQL Server,‏ SAP HANA,‏ IBM Db2,‏ PostgreSQL,‏ SAP ASE,‏ SAP IQ,‏ SAP MaxDB,‏ MySQL,‏ MariaDB, קבוצות של אפליקציות עקביות ואפליקציות גנריות מכונות Compute Engine,‏ Persistent Disk ו-Hyperdisks,‏ Cloud SQL,‏ AlloyDB ו-Filestore (וגם גישה לגיבויים בכספת הגיבוי שנוצרו על ידי מסוף הניהול של המכשיר)

ארכיטקטורה ורכיבי ליבה של Backup and DR למסוף הניהול

במסוף הניהול של Backup and DR נעשה שימוש בארכיטקטורה תלת-שכבתית כדי לתזמר ולהפעיל את ההגנה על הנתונים בסביבה שלכם:

  • מסוף ניהול המכשירים: מישור הבקרה המרכזי מבוסס-האינטרנט שבו אתם מנהלים את מכשירי הגיבוי והשחזור, רושמים מארחים, מגלים אפליקציות, מגדירים תבניות לגיבוי נתונים ופרופילים של משאבים, ומנטרים משימות גיבוי ושחזור. מסוף ניהול המכשירים פועל בפרויקט של דייר (tenant) שמנוהל על ידי Google, ומתקשר באופן מאובטח עם מכשירי הגיבוי והשחזור באמצעות Private Service Connect או גישה פרטית ל-Google.
  • מכשירי גיבוי/שחזור: מכשירים וירטואליים של Compute Engine שנפרסו בפרויקט Google Cloud וברשת ה-VPC. מכשיר הגיבוי/השחזור פועל כמישור הנתונים שמתעד נתונים מעומסי עבודה במקור, מתחזק מטא-נתונים של קטלוגים, מנהל Storage Pool, משכפל נתונים למכשירים מרוחקים או למאגר אובייקטים ומספק טעינות מיידיות. אתם יכולים לבחור מבין ארבעה קטגוריות מכשירים, בהתאם לסוג עומס העבודה, לגודל של קבוצת הנתונים ולנפח האחסון.
  • ‫Backup and DR agents: סוכני תוכנה קלים שמותקנים במערכות הפעלה אורחות של Linux או Windows. סוכן Backup and DR מתקשר עם מכשיר הגיבוי/ההתאוששות כדי לגלות מסדי נתונים ומערכות קבצים, להשהות אפליקציות לצורך תיעוד עקבי של האפליקציות, לתאם מעקב אחר בלוקים שהשתנו (CBT) וגיבויים של יומני טרנזקציות, ולתזמר טעינות שמודעות לאפליקציות. הגנה ללא סוכן משמשת למכונות וירטואליות של VMware (באמצעות ממשקי API של vSphere Storage – הגנה על נתונים) ולמכונות של Compute Engine (באמצעות קובצי snapshot של Persistent Disk).

מאגרי אחסון במכשיר לגיבוי או לשחזור

מכשיר גיבוי/שחזור מארגן ומאחסן נתוני גיבוי שצולמו בעד ארבעה סוגים של Storage Pool:

  • מאגר ראשי: אחסון בלוקים שמחובר ישירות למכשיר הגיבוי/השחזור (באמצעות דיסקים מתמידים רגילים או SSD), שבו מאוחסנים הגיבויים שנוצרו והנתונים שעברו ביטול כפילויות, לצורך שחזור מקומי מהיר וטעינה מיידית.
  • מאגר של קובצי Snapshot: אחסון שמשתמש בקובצי Snapshot של Persistent Disk כדי לאחסן עותקים של נפחי נתונים בנקודת זמן מסוימת, לצורך פעולות של תיעוד וטעינה בביצועים גבוהים.
  • מאגר OnVault: אחסון מבוסס-אובייקטים לשמירה לטווח ארוך, ששולח נתוני גיבוי דחוסים ומצטברים לקטגוריה של Cloud Storage (מסוג Standard,‏ Nearline,‏ Coldline או Archive) או לכספת גיבוי בניהול Google.
  • מאגר שיקוף: אחסון בלוקים במכשיר גיבוי/שחזור משני באזור אחר, שמקבל גיבויים אסינכרוניים משוכפלים ברמת הבלוק (StreamSnap) לתוכנית התאוששות מאסון (DR).

תבניות לגיבוי נתונים, כללי מדיניות ופרופילים של משאבים

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

  • תבנית לגיבוי נתונים: מגדירה איך ומתי הנתונים מגובים, נשמרים ומשוכפלים. כל תבנית לגיבוי נתונים מכילה כלל מדיניות אחד או יותר לגיבוי נתונים, ששולט בלוחות הזמנים, ביעדים להתאוששות מאסון (RPO) ובשמירה על הנתונים ברמות השונות:
    • ‫Production to Snapshot: תיעוד נתונים מעומס העבודה בסביבת הייצור למאגר המקומי Primary או Snapshot.
    • ‫Snapshot to OnVault: מעתיק גיבויי תמונות מצב למאגר OnVault ב-Cloud Storage או לכספת גיבוי לשמירה לטווח ארוך.
    • ‫OnVault to OnVault: שכפול נתונים בין מאגרי OnVault באזורים שונים.
    • ‫Production to Mirror (StreamSnap): משכפל נתוני תמונת מצב למאגר Mirror במכשיר גיבוי/שחזור מרוחק.
  • פרופיל משאבים: מגדיר איפה נתוני הגיבוי מאוחסנים על ידי מיפוי כללי המדיניות בתבנית לגיבוי נתונים למאגרי אחסון ספציפיים של מכשירי גיבוי/שחזור מקומיים, למאגרי OnVault ולמכשירי רפליקציה מרוחקים.

היכולות העיקריות של Backup and DR במסוף הניהול

מסוף הניהול של Backup and DR מספק את היכולות הבאות לניהול של גיבוי, שחזור והעתקת נתונים בארגון:

  • תיעוד מצטבר תמידי: אחרי גיבוי מלא ראשוני של אפליקציה או מכונה וירטואלית, הגיבויים הבאים מתעדים רק את הבלוקים שהשתנו או את השינויים במסד הנתונים. מכשיר הגיבוי/השחזור מסנתז תמונות וירטואליות מלאות של נקודות בזמן, בלי להפעיל גיבויים מלאים תקופתיים שמשפיעים על ביצועי הייצור.
  • הגנה על מסד נתונים עם גיבוי כולל ריקון מידע ושחזור מערכת מנקודה מסוימת בזמן (PITR): שילוב מקורי עם ממשקי API של מסדי נתונים (כמו Oracle RMAN, ‏ SQL Server VSS ו-SAP HANA backint או תמונות מצב של אחסון) כדי ליצור גיבויים של מסדי נתונים עם גיבוי כולל ריקון מידע, לצד גיבויים מתוזמנים של יומני טרנזקציות, שמאפשרים לשחזר את המערכת מנקודה מסוימת בזמן.
  • טעינה מיידית ועותקים וירטואליים: במקום לחכות להעתקה של טרה-בייטים של נתוני גיבוי חזרה לאחסון הייצור לפני שאפשר יהיה להפעיל אפליקציה, אתם יכולים לטעון קובץ אימג' של גיבוי ישירות ממכשיר הגיבוי/השחזור למארח יעד:
    • טעינה רגילה: חשיפת קובץ הגיבוי כדיסק או כמערכת קבצים שנטענו במארח יעד, כדי לבדוק או להעתיק קבצים ספציפיים.
    • טעינה עם מודעות לאפליקציה: הפעלה מיידית של מכונה וירטואלית של מסד נתונים ישירות מתמונת הגיבוי שנטענה בשרת מסד נתונים של היעד, עם אפשרות להריץ קדימה את יומני הטרנזקציות לנקודת זמן נבחרת.
    • הרכבה והעברה: שחזור השירות באופן מיידי באמצעות הרכבה מיידית, תוך העברת קובצי הנתונים הבסיסיים בחזרה לאחסון בסביבת הייצור ברקע, כדי לצמצם את יעדי זמן ההתאוששות (RTO).
    • ‫LiveClone: יוצר עותק וירטואלי עצמאי של תמונת גיבוי שאפשר לכתוב בו, לרענן אותו לפי דרישה או לפי לוח זמנים, בלי לצרוך שטח אחסון פיזי מלא לכל שכפול.
  • תהליכי עבודה אוטומטיים של גיבוי ו-DR: תהליכי עבודה של גיבוי ו-DR הופכים את היצירה, הרענון וההסתרה של LiveClones ומסדי נתונים וירטואליים לאוטומטיים, לפי לוח זמנים או על פי דרישה. צוותי פיתוח, QA וניתוח נתונים יכולים להקצות לעצמם עותקים עדכניים של מסדי נתונים בסביבת הייצור, שבהם נתונים רגישים נמחקים באופן אוטומטי על ידי סקריפטים בהתאמה אישית.
  • התאוששות מאסון בין אזורים: אתם יכולים ליצור רפליקות של קובצי אימג' לגיבוי באופן אסינכרוני למכשיר גיבוי/שחזור משני באזור אחר באמצעות רפליקציית StreamSnap, או להעתיק גיבויים לקטגוריות של Cloud Storage ולכספות גיבוי במספר אזורים או בשני אזורים, כדי שתוכלו לשחזר עומסי עבודה באזור חלופי במהלך הפסקה זמנית בשירות.

עומסי עבודה נתמכים ב-Backup and DR למסוף הניהול

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

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