סקירה כללית של תוכניות הגיבוי

הגדרה

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

• מכונות של Cloud SQL

• מכונות ודיסקים ב-Compute Engine

• אשכולות של AlloyDB ל-PostgreSQL

• מכונות Filestore

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

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

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

תוכנית גיבוי כוללת כלל גיבוי אחד או יותר. כל כלל גיבוי מגדיר את הפרמטרים הבאים:

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

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

  • מדי שבוע: אפשר לבחור יום ספציפי בשבוע.

  • חודשי: אפשר לבחור יום ספציפי בחודש (לדוגמה, היום ה-15).

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

• חלון גיבוי: אפשר להגדיר את מסגרת הזמן שבה עבודות הגיבוי יכולות להתחיל. חלון הגיבוי צריך לעמוד בדרישות הבאות:

  • השעות צריכות להיות בפורמט של שעון 24 שעות, ושעות ההתחלה והסיום צריכות להיות בין 00 ל-24.

  • הסרטון צריך להיות באורך של שש שעות לפחות.

מגבלה: תוכנית גיבוי תמיד כוללת את דיסק האתחול. אם בוחרים באפשרות Exclude boot disk בקטע הגנה על נתונים של Machine configuration, תוכנית הגיבוי עדיין כוללת את דיסק האתחול. מידע נוסף זמין במאמר בנושא יצירת מכונה וירטואלית עם דיסקים נוספים שאינם דיסקים לאתחול.

טווח התדירות של גיבויים שעתיים

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

• אם המדיניות recurrence_type מוגדרת לערך HOURLY, חובה להגדיר את ההגדרה הזו.

• אם recurrence_type לא HOURLY, ההגדרה הזו לא רלוונטית.

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

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

Resource Type	תדירות שעתית
מכונה של Compute Engine	1-23
דיסק של Compute Engine	1-23
מכונת Cloud SQL	6-23
אשכול AlloyDB ל-PostgreSQL	1-23
מופע Filestore	1-23

לגבי משאבי מופעים של Compute Engine, אפשר לעיין בשיטות מומלצות לגיבויים שעתיים.

גיבויים של יומני מסדי נתונים

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

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

שירות Backup and DR מנהל את מחזורי החיים של הגיבויים ואת האבטחה שלהם באמצעות שני סוגים של שמירת נתונים:

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

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

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

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

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

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

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

שמירה מקסימלית מותאמת אישית על פי דרישה

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

צריכת נפח אחסון לגיבוי

כדאי להביא בחשבון את הכללים הבאים לגבי אחסון הגיבוי בתוכנית גיבוי:

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

• משך שמירה מינימלי: תקופת השמירה של הגיבוי חייבת להיות שווה לתקופת השמירה המינימלית של כספת הגיבוי או ארוכה ממנה.

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

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

גיבוי עומסי עבודה לכספת גיבוי עם CMEK

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

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

• עומסי עבודה שמשתמשים ב- Google-owned and Google-managed encryption keys: אם עומס עבודה של מקור משתמש ב- Google-owned and Google-managed encryption keys, חובה לגבות אותו לכספת גיבוי שמשתמשת ב- Google-owned and Google-managed encryption keys.

ניסיונות חוזרים של משימות גיבוי

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

• הניסיון הראשון נכשל: הסטטוס מסומן כ'בוצע ניסיון חוזר', והמערכת ממתינה 4 דקות.
• הניסיון השני נכשל: הניסיון הבא יתווסף לתור אחרי 16 דקות.
• הניסיון השלישי נכשל: הניסיון החוזר האחרון מתווסף לתור אחרי 64 דקות.
• כשל סופי: אחרי 4 ניסיונות בסך הכול, הסטטוס משתנה ל'נכשל'. לא יתבצעו ניסיונות נוספים להפעלת משימות בתקופת התזמון הזו.

ניסיונות חוזרים של משימות מדווחים במעקב > משימות. כדי לזהות ניסיונות חוזרים, לכל ארבעת הג'ובים יהיה מספר ג'וב זהה עם סיומת ייחודית (לדוגמה, Job_12345, ‏ Job_12345a, ‏ Job_12345b).

אזורים נתמכים בתוכנית הגיבוי

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

תוכניות גיבוי נתמכות באזורים הבאים.

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

שמות של תוכניות גיבוי וכללים

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

• הם יכולים להכיל אותיות קטנות, ספרות, מקפים (-), קווים תחתונים (_) ונקודות (.). הם לא יכולים להכיל רווחים.
• השם צריך להתחיל ולהסתיים בספרה או באות
• עד 63 תווים
• אי אפשר לייצג שמות של קטגוריות ככתובות IP בסימון עם נקודה עשרונית. לדוגמה, 192.0.2.255

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

• יצירה וניהול של תוכנית גיבוי לגיבויים בכספת