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

בוחרים גרסת תיעוד:

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

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

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

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

איך פועלת ארכיטקטורת העזר

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

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

צמצום ה-RPO

התכונה continuous archiving של PostgreSQL מאפשרת להשיג יעד נמוך להתאוששות מאסון (RPO) ולבצע שחזור מערכת מנקודה מסוימת בזמן (PITR) באמצעות גיבויים. התהליך הזה כולל העברה לארכיון של קובצי כתיבה מראש ביומן (WAL) וסטרימינג של נתוני WAL, אולי למיקום אחסון מרוחק.

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

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

אסטרטגיות גיבוי

ב-AlloyDB Omni יש תמיכה באסטרטגיות להגנה על נתונים, כמו גיבויים פיזיים תקופתיים, שחזור מערכת מנקודה מסוימת בזמן (PITR), העברה לארכיון וסטרימינג של WAL ואחסון גיבויים במיקומים שונים. לחלופין, במסדי נתונים קטנים אפשר לבצע גיבוי לוגי באמצעות pg_dump למסד נתונים יחיד או באמצעות pg_dumpall לאשכול כולו, ולשחזר באמצעות pg_restore.

כלי גיבוי

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

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

‫AlloyDB Omni עם אפשרויות גיבוי

איור 1. ‫AlloyDB Omni עם אפשרויות גיבוי.

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

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

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

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

שחזור מערכת מנקודה מסוימת בזמן (PITR)

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

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

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

  • יום ראשון: גיבוי מלא
  • שני, שלישי: גיבוי מצטבר
  • יום רביעי: גיבוי דיפרנציאלי
  • חמישי, שישי: גיבוי מצטבר
  • שבת: גיבוי דיפרנציאלי

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

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

שחזור גיבוי

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

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

הטמעה

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

יתרונות

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

מגבלות

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

חלופות

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

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