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

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

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

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

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

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

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

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

לדוגמה, נניח שאתם יוצרים לוח זמנים לגיבוי עם תדירות של 0 7 * * * UTC או כל יום בשעה 7:00 (שעון UTC). כלומר, בכל גיבוי, הערך של versionTime הוא 7:00 UTC, והערך של createTime הוא חותמת זמן בחלון של ארבע שעות בין 7:00 UTC ל-11:00 UTC.

מידע נוסף על שימוש ב-createTime וב-versionTime באמצעות ה-API זמין במאמר הפניית API לגיבוי.

תכונות עיקריות

  • עקביות הנתונים: הגיבויים של מסד נתונים ב-Spanner הם עקביים חיצונית וגם עקביים ברמת העסקה, בנקודת הזמן versionTime של הגיבוי.

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

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

יצירת גיבוי

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

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

  • גיבוי מלא מכיל את כל הנתונים. גיבוי מצטבר מכיל רק את הנתונים שהשתנו מאז הגיבוי הקודם.
  • מידע על הסכימה, כולל שמות הטבלאות, השדות, סוגי הנתונים, האינדקסים המשניים, סנכרון שינויים בזרמי נתונים והקשרים בין הישויות האלה.
  • כל האפשרויות של מסד הנתונים שהוגדרו באמצעות הפקודה ALTER DATABASE SET OPTIONS.

גיבוי של Spanner לא כולל את הפרטים הבאים:

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

כדי לוודא שהגיבוי עקבי מבחינה חיצונית, Spanner מצמיד את התוכן של מסד הנתונים ב-versionTime. כך נמנעת מחיקה של ערכי הנתונים הרלוונטיים על ידי מערכת איסוף הגרוטאות (garbage collection) במהלך פעולת הגיבוי. לאחר מכן, כל אזור קריאה-כתיבה ואזור קריאה בלבד במופע מתחיל להעתיק את הנתונים במקביל. אם אזור כלשהו לא זמין באופן זמני, הגיבוי לא יושלם עד שהאזור יחזור להיות אונליין. אפשר לשחזר את הגיבויים ברגע שהפעולה מסתיימת. במקרים של מופעים בכמה אזורים, כל האזורים עם הרשאות קריאה-כתיבה וקריאה בלבד בכל האזורים צריכים להשלים את רפליקות הגיבוי שלהם לפני שהגיבוי מסומן כגיבוי שאפשר לשחזר ממנו.

לוחות זמנים לגיבויים

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

לוח זמנים לגיבוי מלא יכול ליצור גיבוי כל 12 שעות או יותר. אפשר ליצור גיבוי כל 4 שעות או יותר באמצעות תזמון גיבוי מצטבר.

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

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

גיבויים מצטברים

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

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

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

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

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

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

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

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

    • ‫creation_interval: מייצג את תדירות התזמון שצוינה עבור לוח הזמנים של הגיבוי.
    • ‫retention_duration: מייצג את משך הזמן שבו הגיבויים שנוצרו על ידי התזמון נשמרים. בשרשרת נתונה, הגיבוי המלא הכי ישן נשמר אחרי תאריך התפוגה המקורי שלו אם הוא נדרש לתמיכה בגיבויים חדשים יותר בשרשרת. משך השמירה הכולל של הגיבוי המלא הוא לכל היותר הערך הנמוך מבין הערכים הבאים:
      • ‫retention_duration + 28 ימים
      • ‫retention_duration + (creation_interval*14)

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

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

    מערכת Spanner שואפת להימנע מעותקים מיותרים, אבל במקרים נדירים, יכול להיות ש-Spanner יצטרך להעתיק את כל הגיבויים הישנים בשרשרת, גם אם כבר קיימים גיבויים שהועתקו במכונת היעד.

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

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

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

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

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

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

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

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

עלויות אחסון לגיבויים מלאים ולגיבויים מצטברים

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

  • ‫exclusiveSizeBytes: מספר הבייטים שנדרשים לגיבוי. הגודל הזה מייצג את הגודל של הגיבוי שחויב עליו.
  • ‫freeableSizeBytes: מספר הבייטים שיתפנו אם תמחקו את הגיבוי.
  • ‫oldestVersionTime: מוצג versionTime של הגיבוי המלא הכי ישן בשרשרת, גם אם תוקף הגיבוי פג. אפשר להשתמש בשדה הזה כדי להבין אילו נתונים מאוחסנים.

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

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

נניח שיצרתם תזמון לגיבוי מלא ותזמון לגיבוי מצטבר של מסד נתונים בגודל 100GB, שגדל ב-10GB מדי יום. בטבלה הבאה מוצגות עלויות האחסון האפשריות ללוחות הזמנים הבאים של הגיבוי:

יום נפח הגיבוי של לוח הזמנים המלא נפח הגיבוי המצטבר המתוזמן
1 ‫100 GB ‫100 GB
2 ‫110 GB ‫10 GB
3 ‫120 GB ‫10 GB
4 ‫130 GB ‫10 GB
5 ‫140 GB ‫10 GB

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

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

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

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

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

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

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

איך פועל גיבוי של העתקה

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

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

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

איפה נשמרים הגיבויים של Spanner

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

projects/PROJECT_ID/instances/INSTANCE_ID/backups/BACKUP_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט.
  • ‫INSTANCE_ID: מזהה המכונה.
  • ‫BACKUP_NAME: שם הגיבוי.

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

הצפנה

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

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

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

ביצועים

בקטע הזה מתוארים ביצועים אופטימליים של גיבוי ב-Spanner.

ביצועים בזמן גיבוי

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

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

ביצועים בזמן העתקת גיבוי

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

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

מחיקת גיבוי

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

תמחור

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

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

לדוגמה, אם מעתיקים את מסד הנתונים מהגדרת המופע של מקור במספר אזורים nam7 להגדרת המופע של יעד במספר אזורים nam-eur-asia3, יחולו החיובים הבאים:

  • אין חיוב על אזור us-central1 חופף
  • אין חיוב על אזור us-central2 של העד
  • חיוב על העברת נתונים בין יבשות חל פעמיים: פעם אחת לכל יבשת חדשה (אירופה ואסיה)
  • החיוב על העברת נתונים בין אזורים באותה יבשת חל פעם אחת על us-east1
  • חיוב על העברת נתונים בין אזורים באותה יבשת חל פעם אחת באירופה

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

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

מידע נוסף על עלויות גיבוי מופיע במחירון של Spanner.

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