מאגרי גיבוי לגיבויים שלא ניתן לשנות או למחוק

הגדרת כספת גיבוי

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

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

היררכיית המשאבים

הנתונים ב-Backup and DR מאורגנים בהיררכיה בת שלוש רמות בתוך כספת הגיבוי:

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

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

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

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

מודל המשאבים של כספת הגיבוי.
מודל המשאבים של כספת הגיבוי

מגבלות

  • בדף הזה מוסבר על כספות גיבוי למשאבים שמנוהלים דרך מסוףGoogle Cloud (כמו Compute Engine או Cloud SQL). אם אתם משתמשים במסוף ניהול המכשירים לעומסי עבודה כמו Oracle או Google Cloud VMware Engine, קראו את המאמר סקירה כללית על כספות גיבוי שמנוהלות ממסוף ניהול המכשירים.

  • אי אפשר להשתמש באשכולות של AlloyDB ובמכונות של Filestore בכספות גיבוי במספר אזורים.

  • ב-Backup and DR אין הגבלות על מיקומי היעד התואמים כשמשחזרים עומס עבודה מגיבוי בכספת גיבוי.

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

משאבים נתמכים

סוג עומס העבודה ניהול
מכונה של Compute Engine מסוףGoogle Cloud
דיסק של Compute Engine מסוףGoogle Cloud
מכונה של Filestore מסוףGoogle Cloud
מכונה של Cloud SQL מסוףGoogle Cloud
אשכול AlloyDB מסוףGoogle Cloud
‫Google Cloud VMware Engine, מסד נתונים של Oracle ומסד נתונים של SQL Server מסוף הניהול של המכשיר

מודלים של גיבוי למשאבים

מודל ריכוזי מודל מבוזר
Google Cloud console

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

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

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

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

מיקומים נתמכים של כספות גיבוי

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

אזורים נתמכים ואזורים משולבים

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

אזור גיאוגרפי שם האזור תיאור האזור
צפון אמריקה
northamerica-northeast1 * מונטריאול ‫סמל של עלה רמה נמוכה של CO2‎
northamerica-northeast2 טורונטו ‫סמל של עלה רמה נמוכה של CO2‎
us-central1 אייווה ‫סמל של עלה רמה נמוכה של CO2‎
us-east1 דרום קרוליינה
us-east4 צפון וירג'יניה
us-east5 קולומבוס
us-south1 דאלאס ‫סמל של עלה רמה נמוכה של CO2‎
us-west1 אורגון ‫סמל של עלה רמה נמוכה של CO2‎
us-west2 לוס-אנג׳לס
us-west3 סולט לייק סיטי
us-west4 לאס וגאס
northamerica-south1 * קוורטארו
דרום אמריקה
southamerica-east1 סאו פאולו ‫סמל של עלה רמה נמוכה של CO2‎
southamerica-west1 סנטיאגו ‫סמל של עלה רמה נמוכה של CO2‎
אירופה
europe-central2 ורשה ‫סמל של עלה רמה נמוכה של CO2‎
europe-north1 פינלנד ‫סמל של עלה רמה נמוכה של CO2‎
europe-north2 שטוקהולם ‫סמל של עלה רמה נמוכה של CO2‎
europe-southwest1 מדריד ‫סמל של עלה רמה נמוכה של CO2‎
europe-west1 בלגיה ‫סמל של עלה רמה נמוכה של CO2‎
europe-west2 לונדון ‫סמל של עלה רמה נמוכה של CO2‎
europe-west3 פרנקפורט
europe-west4 הולנד ‫סמל של עלה רמה נמוכה של CO2‎
europe-west6 ציריך ‫סמל של עלה רמה נמוכה של CO2‎
europe-west8 מילאנו ‫סמל של עלה רמה נמוכה של CO2‎
europe-west9 פריז ‫סמל של עלה רמה נמוכה של CO2‎
europe-west10 ברלין
europe-west12 טורינו ‫סמל של עלה רמה נמוכה של CO2‎
המזרח התיכון
me-central1 דוחה
me-central2 דמאם
me-west1 ישראל
אפריקה
africa-south1 יוהנסבורג
אסיה ואזור האוקיינוס השקט
asia-east1 טייוואן
asia-east2 הונג קונג
asia-northeast1 טוקיו
asia-northeast2 * אוסקה
asia-northeast3 סיאול
asia-southeast1 סינגפור
asia-southeast2 ג'קארטה
australia-southeast1 סידני
australia-southeast2 מלבורן
הודו
asia-south1 מומבאי
asia-south2 דלהי

‫* קרטרו (northamerica-south1), מונטריאול (northamerica-northeast1) ואוסקה (asia-northeast2) לא תומכים בהפרדה בין תחומים. כלומר, יכול להיות שהאזורים השונים בכל אחד מהמחוזות האלה לא נמצאים בקמפוסים נפרדים פיזית של מרכזי נתונים. לכן, אסון פיזי מקומי אחד יכול להשפיע על כמה אזורים באותו מחוז, ולהגדיל את הסיכון לאובדן נתונים בהשוואה למחוזות שתומכים בהפרדה בין תחומים.

תמיכה במספר אזורים

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

השם של המיקום "מספר אזורים" תיאור
ASIA מרכזי נתונים באסיה
EU מרכזי נתונים באיחוד האירופי
US מרכזי נתונים בארצות הברית

תאימות של מיקום עומס העבודה

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

עומס עבודה כספת הגיבוי צריכה להיות באותו אזור שבו נמצא עומס העבודה של המקור תמיכה אזורית תמיכה במספר אזורים תמיכה בכמה אזורים
מכונה של Compute Engine לא
דיסק של Compute Engine לא
מכונה של Cloud SQL כן
אשכול AlloyDB כן
מכונה של Filestore לא
‫Google Cloud VMware Engine, מסד נתונים של Oracle ומסד נתונים של SQL Server לא

תאימות למספר אזורים

כדי להשתמש במספר אזורים, צריך לעמוד בדרישות הבאות:

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

  • אפשר לגבות משאבים רק באזורים עם אותה קידומת. לדוגמה, אפשר לגבות משאבים באזורים עם הקידומת asia רק ב-asia במספר אזורים.

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

סוג עומס העבודה תמיכה בשימוש בכספות גיבוי במספר אזורים? אזורים נתמכים לכספות גיבוי במספר אזורים
מכונה של Compute Engine asia, eu, us
דיסק של Compute Engine asia, eu, us
מכונה של Filestore לא רלוונטי
מכונה של Cloud SQL asia, eu, us
אשכול AlloyDB לא רלוונטי
‫Google Cloud VMware Engine, מסד נתונים של Oracle ומסד נתונים של SQL Server לא רלוונטי

זמינות

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

כספות גיבוי שנוצרות במיקומים במספר אזורים מספקות חוסן (resilience) בפני הפסקות חשמל באזור אחד. נתוני הגיבוי מאוחסנים ביתירות בשני אזורים נפרדים לפחות.

השוואה בין כספות גיבוי במספר אזורים לבין כספות גיבוי באזורים שונים

קריטריונים גיבויים במספר אזורים גיבויים באזורים שונים
יצירת גיבוי אוטומציה על ידי Google בשני אזורים ביבשת. אוטונומיה להגדיר במפורש אזור ליצירת גיבוי.
תרחיש לדוגמה זמינות גבוהה ופשטות תפעולית תאימות מחמירה, חוקים בנושא מיקום אחסון הנתונים או אתרים ייעודיים להתאוששות מאסון, בתוך הגבולות האזוריים של המקור ומחוץ להם.
ניהול תקורה נמוכה. כספת אחת, איזון אוטומטי תקורה בינונית. צריך להגדיר התאמה ספציפית ליעד.
מפתחות הצפנה בניהול הלקוח (CMEK) כספת גיבוי במספר אזורים חייבת להשתמש ב-CMEK מאותו אזור של כספת הגיבוי. כספת הגיבוי באזורים שונים צריכה להשתמש ב-CMEK מאותו אזור שבו נמצאת כספת הגיבוי.
השלכות על העלות חיוב על העלאה והורדה במספר אזורים, במקרים הרלוונטיים. חיוב על אחסון גיבוי בכספת במספר אזורים. חיוב על ניהול. חיובים על העברת נתונים בין אזורים. חיוב על אחסון לגיבוי. דמי ניהול.
עומסי עבודה נתמכים
  • מכונות Compute Engine
  • דיסקים של Compute Engine
  • מכונות של Cloud SQL
  • מכונות Compute Engine
  • דיסקים של Compute Engine
  • מכונות של Filestore

שמות של כספות גיבוי

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

  • שמות של כספות גיבוי יכולים להכיל רק אותיות קטנות, ספרות ומקפים (-). הם לא יכולים להכיל רווחים.

  • שמות של כספות גיבוי צריכים להתחיל ולהסתיים בספרה או באות.

  • שמות של כספות גיבוי צריכים להכיל 3-63 תווים. שמות שמכילים נקודות יכולים להכיל עד 222 תווים, אבל כל רכיב שמופרד באמצעות נקודות יכול להיות באורך של עד 63 תווים.

  • אי אפשר לייצג שמות של כספות גיבוי ככתובות IP בסימון עם נקודה עשרונית. לדוגמה, 192.0.2.255.

מניעת מחיקה של גיבויים

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

אתם יכולים לשלוט באכיפת השמירה באמצעות שלוש הגדרות עיקריות ב-Vault:

  • שמירה מינימלית באכיפה: כשיוצרים כספת, צריך להגדיר תקופת שמירה בסיסית (בין יום אחד ל-99 שנים). כך נוצר מחיר מינימלי חובה לכל ה-Vault:

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

  • ירושת שמירה מכלל הגיבוי: במקום להסתמך רק על המינימום הבסיסי של הכספת, אתם יכולים להגדיר את הכספת כך שתאמץ את תקופת השמירה המדויקת שמוגדרת בתוכניות הגיבוי הספציפיות שלכם. אתם צריכים להפעיל את ההגדרה הזו במהלך יצירת הכספת.

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

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

כשמגדירים נעילה, בוחרים מועד כניסה לתוקף. לפני מועד הכניסה לתוקף, עדיין אפשר לשנות את תקופת השמירה המינימלית כדי לתקן טעויות. אחרי מועד הכניסה לתוקף, אף אחד (אפילו לא Project Owner) לא יכול לקצר את תקופת השמירה. מותר רק להגדיל אותו.

הגבלת הגישה לכספת הגיבוי

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

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

  • הגבלת הגישה לארגון הנוכחי: פעולות הגיבוי והשחזור נתמכות רק בארגון הנוכחי. הבחירה הזו הופכת את כספת הגיבוי לתואמת למשאבים שמנוהלים דרך מסוףGoogle Cloud , כמו מכונות של Compute Engine, אבל לא למשאבים שמנוהלים דרך מסוף הניהול של המכשיר.

  • הגבלת הגישה לפרויקט הנוכחי: פעולות הגיבוי והשחזור נתמכות רק בפרויקט הנוכחי. הבחירה הזו הופכת את כספת הגיבוי לתואמת למשאבים שמנוהלים דרך מסוףGoogle Cloud (לדוגמה, מכונות Compute Engine), אבל לא למשאבים שמנוהלים דרך מסוף הניהול של המכשיר.

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

  • גישה ללא הגבלה: מאפשרת לבצע פעולות גיבוי ושחזור אל או מכל פרויקט או ארגון. הבחירה הזו הופכת את כספת הגיבוי לתואמת למשאבים שמנוהלים דרך מסוף Google Cloud ולמשאבים שמנוהלים דרך מסוף ניהול המכשירים.

הצפנה

כברירת מחדל, Google Cloud מצפין באופן אוטומטי נתונים במנוחה באמצעות Google-owned and Google-managed encryption keys. אם יש לכם דרישות תאימות או דרישות רגולטוריות ספציפיות שקשורות למפתחות שמגנים על הנתונים שלכם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) לגיבויים. מפתחות הצפנה בניהול הלקוח (CMEK)

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