סקירה כללית על גיבויים ב-Cloud SQL

ב-Cloud SQL אפשר לגבות את המכונות לפי דרישה או באופן אוטומטי באמצעות תזמון גיבויים. הגדרות הגיבוי שזמינות למופע שלכם תלויות באפשרות הגיבוי של המופע. גיבויים של Cloud SQL הם מצטברים ועוזרים לשחזר נתונים שאבדו למופע Cloud SQL. הגיבויים מוצפנים כברירת מחדל באמצעות מפתחות הצפנה בניהול Google או מפתחות הצפנה בניהול הלקוח (CMEK). בעזרת גיבויים אתם יכולים:

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

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

אפשרויות גיבוי

ב-Cloud SQL יש שתי אפשרויות לגיבויים כדי לנהל את הגיבויים של המכונה. שתי האפשרויות תומכות גם ב Google Cloud-powered encryption keysוגם במפתחות הצפנה בניהול הלקוח (CMEK):

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

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

סוגי בקשות לגיבוי

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

גיבויים על פי דרישה

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

גיבויים אוטומטיים

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

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

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

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

גיבוי סופי

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

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

כברירת מחדל, Cloud SQL שומר את הגיבוי הסופי למשך 30 יום. עם זאת, אתם יכולים להתאים אישית את משך הזמן שבו הגיבוי יישמר ב-Cloud SQL. הטווח יכול להיות בין יום אחד ל-365 ימים לגיבויים רגילים, או בין יום אחד ל-10 שנים לגיבויים משופרים. לאחר מכן תוכלו לשחזר את המופע מהגיבוי כל עוד הוא זמין. החיוב על גיבויים סופיים דומה לחיוב על גיבויים אחרים, והוא מתבצע לפי מספר הימים שבהם הגיבויים נשמרים.

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

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

שמירת גיבויים

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

שמירת גיבויים אחרי מחיקת מופע

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

אתם יכולים לעדכן את התיאור של הגיבויים האלה כדי שיהיה קל יותר לנהל אותם ב Cloud de Confiance by S3NS פרויקט. תמיד אפשר לשחזר גיבויים שנשמרו למופע חדש או קיים של Cloud SQL.

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

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

בגיבויים רגילים, מאחר שאפשר להשתמש בשמות של מכונות אחרי שהן נמחקות ב-Cloud SQL, הגיבויים שנשמרים מאוחסנים בפרויקטCloud de Confiance עם שדה שנקרא instance_deletion_time. בשדה הזה אפשר לראות אם גיבוי מסוים שייך למופע פעיל או למופע שנמחק. אפשר גם לעדכן את התיאור של הגיבוי כדי שיהיה קל יותר לנהל אותם.

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

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

גיבויים לשחזור

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

גיבוי ובדיקות תקינות נתונים

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

גיבויים של רפליקות

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

גיבויים לעומת ייצוא

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

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

כדי לשדרג לגרסה מאוחרת יותר, מבצעים שדרוג גרסה ראשית במקום, משתמשים ב-Database Migration Service או מייצאים ואז מייבאים את מסד הנתונים למופע חדש של Cloud SQL.

גודל הגיבוי

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

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

פתרון בעיות

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

מריצים את הפקודה gcloud sql operations list כדי להציג רשימה של כל הפעולות עבור המכונה הנתונה של Cloud SQL.

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

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

  • cloudsql.googleapis.com/postgres.log
  • אם Cloud Audit Logs מופעלות ויש לכם את ההרשאות הנדרשות לצפייה בהן, יכול להיות שגם cloudaudit.googleapis.com/activity יהיה זמין.
אחרי שמחקתם מופע, אי אפשר לגבות אותו.

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

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

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

אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ תמיכת הלקוחות לבטלforce restart את המופע.

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

יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL.

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

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

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

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

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

פעולות שכדאי לנסות:

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

CREATE UNLOGGED TABLE ....

הטבלאות האלה לא נכללות בשחזור מגיבוי:

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

הפתרון הוא להימנע משימוש בטבלאות שלא נרשמו ביומן אם רוצים לשחזר את הטבלאות האלה באמצעות גיבוי. אם אתם משחזרים ממסד נתונים שכבר מכיל טבלאות לא מתועדות, אתם יכולים להעביר את מסד הנתונים לקובץ ואז לטעון מחדש את הנתונים אחרי שתשנו את הקובץ שהועבר מ-ALTER TABLE ל-SET LOGGED בטבלאות האלה.

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

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