‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

כספת הגיבוי היא משאב אזורי שמנוהל על ידי 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` ^*	מונטריאול	‫ רמה נמוכה של CO₂‎
	`northamerica-northeast2`	טורונטו	‫ רמה נמוכה של CO₂‎
	`us-central1`	אייווה	‫ רמה נמוכה של CO₂‎
	`us-east1`	דרום קרוליינה
	`us-east4`	צפון וירג'יניה
	`us-east5`	קולומבוס
	`us-south1`	דאלאס	‫ רמה נמוכה של CO₂‎
	`us-west1`	אורגון	‫ רמה נמוכה של CO₂‎
	`us-west2`	לוס-אנג׳לס
	`us-west3`	סולט לייק סיטי
	`us-west4`	לאס וגאס
	`northamerica-south1` ^*	קוורטארו
דרום אמריקה
	`southamerica-east1`	סאו פאולו	‫ רמה נמוכה של CO₂‎
	`southamerica-west1`	סנטיאגו	‫ רמה נמוכה של CO₂‎
אירופה
	`europe-central2`	ורשה	‫ רמה נמוכה של CO₂‎
	`europe-north1`	פינלנד	‫ רמה נמוכה של CO₂‎
	`europe-north2`	שטוקהולם	‫ רמה נמוכה של CO₂‎
	`europe-southwest1`	מדריד	‫ רמה נמוכה של CO₂‎
	`europe-west1`	בלגיה	‫ רמה נמוכה של CO₂‎
	`europe-west2`	לונדון	‫ רמה נמוכה של CO₂‎
	`europe-west3`	פרנקפורט
	`europe-west4`	הולנד	‫ רמה נמוכה של CO₂‎
	`europe-west6`	ציריך	‫ רמה נמוכה של CO₂‎
	`europe-west8`	מילאנו	‫ רמה נמוכה של CO₂‎
	`europe-west9`	פריז	‫ רמה נמוכה של CO₂‎
	`europe-west10`	ברלין
	`europe-west12`	טורינו	‫ רמה נמוכה של CO₂‎
המזרח התיכון
	`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		לא רלוונטי

זמינות

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

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

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

קריטריונים	גיבויים במספר אזורים	גיבויים בין אזורים
יצירת גיבוי	אוטומציה של 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 שנים). כך נוצרת רמת מינימום מחייבת לכל הכספת:

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

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

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

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

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

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

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

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

הצפנה

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