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

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

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

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

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

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

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

עלויות

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

עלויות אחסון

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

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

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

גיבוי רגיל הוא עותק לוגי מלא של טבלה. מאחורי הקלעים, מערכת 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.

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