תמונת מצב היא ייצוג של נקודת זמן שההגנה שלה נקבעת לפי המימוש שלה. אסטרטגיית גיבוי מוסיפה שמירה מכוונת, הפרדת גישה ושחזור נבדק. חלק מתמונות המצב הן גיבויים; אחרות תלויות באחסון המקורי. שאלו מה שורד מחיקה, פגיעה או אובדן של הסביבה הראשית.
תארו את ההעתק לפני שאתם נותנים לו שם
המילה תמונת מצב אומרת לכם שנקודת זמן יוצגה, אך לא היכן מוחזקים הנתונים הניתנים לשחזור או מי יכול למחוק אותם. לתמונת מצב של מערכת קבצים באחסון המקורי ולתמונת מצב של בלוק המנוהלת על ידי ספק יכולים להיות גבולות כשל שונים. התחילו מהמימוש במקום להתייחס לתווית כהבטחה אוניברסלית.
AWS מתעדת תמונות מצב של EBS כגיבויים מצטברים של נקודות זמן של הכרכים שלה. זהו מימוש ספציפי, לא הוכחה שכל אפשרות תמונת מצב מתנהגת באותו אופן. עבור כל שירות, שאלו אם השחזור תלוי בכרך המקורי, אם העתקים יוצאים מתחום הכשל הראשי ומה קורה כאשר המקור מוסר.
השוו את הכשלים שאתם מצפים לשרוד
חזרה מהירה לאחור לאחר עדכון ושחזור לאחר אובדן חשבון הם בעיות שונות. תמונת מצב מקומית עשויה להיות נוחה לראשונה תוך שהיא מציעה מעט הפרדה לשנייה. העתקים בלתי תלויים יכולים להוסיף הגנה, אך רק אם נתיבי האחסון, הגישה והמחיקה שלהם מופרדים מספיק מהאירוע שאליו אתם מתכוננים.
רשמו את הכשל ואת התוצאה הנדרשת. השוואה להמחשה זו היא עזר להחלטה, לא רשימת תכונות עבור SwissOctet. היא מעודדת שאלות על העתקים ושליטה במקום טענה שטכנולוגיה אחת תמיד עדיפה. התוצאה בפועל תלויה בתצורה ובתהליך השחזור המתועד של המפעיל.
| תרחיש | שאלה עבור תמונת מצב | שאלה עבור גיבוי |
|---|---|---|
| עדכון יישום שגוי | האם אני יכול לחזור לנקודה המיועדת? | כמה זמן לוקח שחזור שמיש? |
| הדיסק הראשי אבד | האם ההעתק תלוי בדיסק הזה? | האם אני יכול לשחזר לאחסון חדש? |
| חשבון ניהולי נפגע | האם החשבון הזה יכול למחוק כל העתק? | האם זכויות המחיקה מופרדות? |
| שגיאה שהתגלתה שבועות לאחר מכן | האם הנקודה הזו עדיין נשמרת? | האם השמירה מכסה את עיכוב הגילוי? |
בדקו עקביות יישום
דיסק יכול ללכוד קבצים בזמן שיישום עדיין משנה אותם. בהתאם לתוכנה ולתהליך תמונת המצב, התוצאה עשויה לייצג מצב עקבי לקריסה ולא מצב יישום מתואם. אל תניחו שקבצים קריאים אומרים שמסד נתונים והעלאות הקשורות אליו תואמים. השתמשו בשיטת הגיבוי המתועדת על ידי היישום או מסד הנתונים.
עיצוב הארכיון הרציף של PostgreSQL ממחיש את ההבדל: שחזור זקוק לגיבוי בסיס מתאים ולרצף רציף של קובצי write-ahead log הנדרשים. תיקייה שהועתקה באופן רשלני בזמן שמסד הנתונים פועל אינה הליך שווה ערך. אם היישום גם שומר קבצים מחוץ למסד הנתונים, תכננו כיצד שני מערכי הנתונים האלה משוחזרים יחד.
התייחסו לשמירה כחלון שחזור
שמירה צריכה להתחשב בכמה זמן שגיאה יכולה להישאר בלתי מזוהה. חלון של עשרה ימים לא עוזר למחיקה בשוגג שהתגלתה לאחר חודש. שמירת כל העתק ללא הגבלת זמן יוצרת בעיה אחרת: עלות, חשיפה גדלה לנתונים רגישים ומדיניות מחיקה לא ברורה. בחרו שמירה מתוך דרישות תפעוליות וטיפול בנתונים קונקרטיות.
תייגו נקודות שחזור בהקשר שימושי, כגון גרסת יישום וזמן עבודה שהושלמה, בלי להטמיע סודות. שמרו מספיק היסטוריה כדי להבחין בין מצב טוב למצב פגום. לפני גיזום, אשרו כיצד המערכת הנבחרת מטפלת בנתונים משותפים או מצטברים; מחיקת נקודה מתויגת עשויה שלא להתאים למחיקת קובץ עצמאי פשוט.
הפרידו בין עבודות מוצלחות לנתונים מאומתים
כלי גיבוי שמדווח על הצלחה קובע שהתהליך שלו הושלם לפי הכללים שלו. זה לא מוכיח אוטומטית שכל נתוני היישום החשובים נבחרו, שכל בייט מאוחסן נשאר שלם או ששרת חדש יכול להשתמש בתוצאה. אלה בדיקות שונות. כללו בריאות מאגר, סקירת בחירה ושחזור מייצג בתוכנית התפעולית.
Restic מתעדת הבחנה בין בדיקת המאגר המוגדרת כברירת מחדל לבין אימות שקורא נתוני pack מאוחסנים. בדיקת קריאת הנתונים המלאה יכולה לצרוך יותר זמן ורוחב פס. הדוגמה הזו ממחישה את נקודת התכנון: החליטו מה האימות באמת קורא ותקצבו את העבודה. השתמשו בתיעוד הכלי במקום להניח שלכל פקודה בשם check יש אותה כיסוי.
בדקו שחזור קטן ומלא
דמיינו פרסום עם מסד נתונים, תמונות שהועלו ותצורה. שחזרו את שלושתם לסביבת בדיקה פרטית, ואז פתחו מאמר ואמתו את הקבצים המצורפים שלו. השאירו אינטגרציות דואר מתוזמן, תשלום ופרסום מושבתות במהלך התרגיל. בדיקת קובץ טקסט אקראי בלבד תפספס את הקשרים שהופכים את היישום לשימושי.
מדדו את הזמן הנדרש ותעדו אילו אישורים, גרסאות חבילה או תלויות חיצוניות היו חסרים. בדקו הרשאות על הקבצים המשוחזרים, לא רק את התוכן שלהם. תרגיל שחזור מגלה לעתים קרובות שהנתונים קיימים אך ההוראות או הגישה הדרושות לשימוש בהם מעולם לא נשמרו לצד תוכנית התפעול.
קראו גיבויים אופציונליים כשירות ספציפי
בעת הגדרת SwissOctet, הסתכלו על אפשרות הגיבוי המדויקת ותקופת השמירה עבור המשפחה. שאלו אילו כרכים ונתוני יישום היא מכסה, אם השחזור הוא בשירות עצמי ומה קורה כאשר התצורה הראשית משתנה. תווית האפשרות לבדה אינה מבססת העתק בלתי תלוי, מאגר בלתי ניתן לשינוי או נקודת שחזור עקבית למסד נתונים.
השתמשו בתמונות מצב היכן שהן מתאימות לעומס העבודה ושמרו על אסטרטגיית גיבוי רחבה יותר עבור כשלים שהן אינן מכסות. תעדו נתיב שחזור בלתי תלוי לנתונים חשובים, הגנו על האישורים שיכולים למחוק העתקים ובדקו את ההליך. הבחירה החזקה ביותר היא זו ששורדת את התרחיש שהגדרתם, לא זו עם השם המרגיע ביותר.
רשימת הבדיקה המעשית שלך.
- זהו היכן חיים הנתונים הניתנים לשחזור.
- פרטו כשלים שההעתק חייב לשרוד.
- השתמשו בשיטת עקביות הנתמכת על ידי היישום.
- בחרו שמירה עבור חלון הגילוי.
- הגנו על זכויות מחיקה בנפרד.
- שחזרו יישום מלא בסביבה מבודדת.
הפרטים שחשובים.
האם תמונת מצב היא לעולם לא גיבוי?+
חלק ממימושי תמונות המצב הם גיבויים. ההבחנה השימושית היא התלות באחסון, השמירה, מודל הגישה והשחזור הנבדק שלהם, לא התווית לבדה.
האם בדיקת שלמות מוצלחת מוכיחה שהיישום יעבוד?+
היא מוכיחה רק את מה שהבדיקה הזו מכסה. בדקו בנפרד שחזור יישום, תצורה, הרשאות וקשרי נתונים.
האם לשמור את הגיבוי על אותו שרת?+
העתק על אותו שרת עשוי לעזור עם טעויות מוגבלות אך חולק כשלים חשובים. נתונים חשובים זקוקים לנתיב שחזור מחוץ לגבול הכשל שאתם מתכוונים לשרוד.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- Amazon EBS: תמונות מצב docs.aws.amazon.com
- PostgreSQL: ארכיון רציף ושחזור לנקודת זמן www.postgresql.org
- Restic: עבודה עם מאגרים ובדיקות שלמות restic.readthedocs.io
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.