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

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

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

כלי גיבוי

בפריסות של קונטיינרים ו-Linux, אפשר לתזמן ולנהל גיבויים באמצעות הכלים הבאים של PostgreSQL:

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

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

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

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

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

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

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

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

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

העברת נתוני WAL בסטרימינג למיקום מרוחק

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

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

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

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

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

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

שחזור גיבוי

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

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

הטמעה

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

יתרונות

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

מגבלות

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

חלופות

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

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