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

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

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

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

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

  • כדי ש-Bigtable ייצור בשבילכם גיבויים יומיים, צריך להפעיל גיבוי אוטומטי.
  • יוצרים גיבוי לפי דרישה באמצעות מסוף Google Cloud , ה-CLI של gcloud או ספריית לקוח של Bigtable.
  • יוצרים עותק של גיבוי.

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

תכונות

  • משולב באופן מלא: הגיבויים מתבצעים באופן מלא על ידי שירות Bigtable, ללא צורך בייבוא או בייצוא.
  • מצטבר: הגיבוי חולק את האחסון הפיזי עם טבלת המקור ועם גיבויים אחרים של הטבלה.
  • חסכוני: שימוש בגיבויים של Bigtable מאפשר לכם להימנע מהעלויות שקשורות לייצוא, לאחסון ולייבוא נתונים באמצעות שירותים אחרים.
  • תפוגה אוטומטית: לכל גיבוי יש תקופת שמירה שהמשתמש מגדיר. אתם יכולים להגדיר את התקופה הזו למקסימום 90 ימים במהדורת Enterprise או עד 365 ימים במהדורת Enterprise Plus. אפשר לאחסן עותק של גיבוי למשך עד 30 יום.
  • אפשרויות שחזור גמישות: אפשר לשחזר מגיבוי לטבלה במופע אחר שבו הגיבוי נוצר.
  • גיבוי אוטומטי: הפעלת גיבוי אוטומטי מאפשרת ל-Bigtable ליצור גיבויים יומיים.
  • גיבויים חמים: תכנון התאוששות מאסון באמצעות גיבויים חמים שמוכנים לייצור.

תרחישים לדוגמה

גיבויים שימושיים בתרחישי השימוש הבאים:

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

כדאי להביא בחשבון את התרחישים הבאים של התאוששות מאסון:

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

גיבויים חמים

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

מגבלות של גיבויים חמים

לגיבויים חמים יש את המגבלות הבאות:

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

עבודה עם גיבויים של Bigtable

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

  1. אי אפשר ליצור עותק של עותק גיבוי.
  2. עותק של גיבוי הוא תמיד גיבוי רגיל, גם אם המקור הוא גיבוי חם.
פעולה אפשרויות יעד
יצירת גיבוי רגיל
  • כל אשכול באותו מופע כמו טבלת המקור
יצירת גיבוי חם
  • כל אשכול באותו מופע כמו טבלת המקור. המופע צריך להשתמש באחסון SSD.
שחזור מגיבוי רגיל או מגיבוי חם לטבלה חדשה
  • כל מופע
  • כל אזור Bigtable
  • כל פרויקט
העתקת גיבוי1, 2
  • כל מופע
  • כל אזור Bigtable
  • כל פרויקט

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

כדי לעבוד עם גיבויים של Bigtable, אפשר להשתמש באפשרויות הבאות:

אחסון לגיבוי

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

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

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

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

אפשר ליצור עד 150 גיבויים לכל טבלה בכל אשכול.

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

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

הנתונים בגיבויים מוצפנים.

שמירה

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

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

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

נפח האחסון אחרי השחזור

עלות האחסון של טבלה חדשה ששוחזרה מגיבוי זהה לעלות של כל טבלה אחרת.

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

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

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

עלויות

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

עלויות אחסון

עלויות האחסון שונות לגיבויים רגילים ולגיבויים פעילים.

עלויות אחסון גיבוי רגילות

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

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

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

עלויות אחסון של גיבוי חם

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

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

עלויות של העתקת גיבוי

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

עלויות שחזור

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

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

CMEK

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

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

שיקולים לגבי שכפול

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

שכפול וגיבוי

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

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

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

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

  • יכול להיות שפעולת כתיבה תישלח לחלק בטבלה שכבר הועתק בגיבוי.
  • יכול להיות שפעולת כתיבה לאשכול אחר לא שוכפלה לאשכול שמכיל את הגיבוי.

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

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

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

שכפול ושחזור

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

ביצועים

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

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

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

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

ביצועים בזמן שחזור

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

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

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

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

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

בקרת גישה

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

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

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

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

פעולה הרשאת IAM נדרשת
יצירת גיבוי bigtable.tables.readRows, bigtable.backups.create
קבלת גיבוי bigtable.backups.get
הצגת רשימת הגיבויים bigtable.backups.list
מחיקת גיבוי bigtable.backups.delete
עדכון גיבוי bigtable.backups.update
העתקת גיבוי bigtable.backups.read, bigtable.backups.create
שחזור מגיבוי לטבלה חדשה bigtable.tables.create, bigtable.backups.restore
קבלת פעולה bigtable.instances.get
הצגת רשימה של פעולות bigtable.instances.get

שיטות מומלצות

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

יצירת גיבויים

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

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

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

מכסות ומגבלות

בקשות גיבוי ושחזור ואחסון גיבוי כפופות ל מכסות ומגבלות של Bigtable.

מגבלות

ההגבלות הבאות חלות על גיבויים של Bigtable:

כללי

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

שחזור

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

העתקה

  • אי אפשר ליצור עותק של גיבוי שתוקף שלו עומד לפוג תוך 24 שעות.
  • אי אפשר ליצור עותק של עותק גיבוי.

CMEK

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

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