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

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

בדף הזה מתוארת ארכיטקטורת העזר של 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.

כלי גיבוי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שחזור גיבוי

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

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

הטמעה

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

יתרונות

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

מגבלות

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

חלופות

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

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