הגדרת גיבוי שרתים באמצעות Bacula / Bareos

Bacula הגדרה: מדוע גיבויים אינם משוחזרים

הגדרת Bacula בנויה כך שהשלמה מוצלחת של משימה עדיין אינה מבטיחה דבר. ה-Director מקבל מהלקוח דוח על שליחת נתונים, כותב רשומה לקטלוג — והמשימה נסגרת בסטטוס "הושלמה".

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

מקור קלאסי לבעיות — חוסר סנכרון בין ה-Director ללקוח Bacula. קובץ ההכללות בלקוח מתאר מערך אחד של נתיבים, והמשימה ב-Director — מערך אחר; הקטלוג meanwhile שומר מטא-נתונים שאינם תואמים לתוכן האמיתי של הכרך.

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

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

לכן בדיקת עותקי גיבוי חייבת להיות процедуרה קבועה, ולא פעולה חד-פעמית: שחזור בדיקה לצומת נפרד, השוואת סכומי ביקורת, בקרת שלמות השרשרת לפי הקטלוג. מפרקים כיצד לבנות את הגדרת Bacula כך שההעתק יעלה באופן מובטח ברגע התקלה.

מה נותנת מערכת גיבוי מסודרת

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

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

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

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

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

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

השוואת גישות: מלא, אינקרמנטלי ודיפרנציאלי

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

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

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

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

שלבי יישום: מביקורת ועד מסירה לתפעול

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

1. ביקורת תשתית. אנו אוספים מפת מערכות, היקפי נתונים, קצב הגידול שלהם, שיטות הגיבוי הנוכחיות ונקודות התורפה שלהן. בודקים את הרשת ואת מערכי האחסון: רוחב הפס בין הלקוח ל-director קובע אם העתקת הלילה תספיק להיכנס לחלון הזמן.
2. תכנון הסכמה. מגדירים את תפקידי director, storage daemon ו-file daemon, מפזרים אותם בין השרתים, בוחרים מאגרי כרכים ומדיניות שמירה. מתאמים לוח זמנים של העתקות מלאות ואינקרמנטליות בהתחשב בעומס על מקורות הנתונים.
3. הגדרת Bacula. מגדירים את הקטלוג, המאגרים, לוחות הזמנים והמשימות, מחברים לקוחות, מגדירים הצפנת ערוץ ודדופליקציה. בנפרד מגדירים מדיניות שמירה: כמה העתקות מלאות נשמרות, ומתי כרכים נדרסים.
4. בדיקת שחזור. משחזרים נתונים לעמדה מבודדת — תחילה קבצים בודדים, ולאחר מכן מערכת שלמה. מודדים את הזמן בפועל ומשווים למדדי היעד; פער הוא סיבה לבנות מחדש את לוח הזמנים או להוסיף אחסון.
5. ניטור והתראות. מחברים התראות על סטטוס משימות, שגיאות והתמלאות כרכים, כך שכשל בהעתקה לא יתגלה ברגע שבו הנתונים כבר נדרשים.
6. תיעוד. מתארים את הסכמה, לוחות הזמנים, המאגרים וסדר הפעולות בעת שחזור — כך שמהנדס תורן יוכל להעלות נתונים ללא מחבר ההגדרה.
7. הדרכה ומסירה. מקיימים סקירה עם הצוות שלכם: כיצד לקרוא דוחות, כיצד להפעיל שחזור, מה לעשות בעת כשל. מוסרים את המערכת לתפעול עם נוהל ברור.

מה הלקוח מקבל לידיו לאחר סיום העבודה

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

• קבצי תצורה של Director, Storage ו-File Daemon עם הערות: אילו תיקיות נכללות במשימות, מדוע הוחרגו מטמונים ונתונים זמניים, כיצד נוסף לקוח חדש.
• תרשים הגיבוי: מה ובאיזו תדירות מגובה, היכן מתחלפים גיבוי מלא וגיבוי מצטבר, כיצד מחולקות המשימות לחלונות עומס נמוך.
• מדיניות שמירה: כמה גרסאות ודורות נשמרים בכל אמצעי אחסון, מתי רשומה מועברת לארכיון ונמחקת, כיצד מוגדרת רוטציית הכרכים.
• נוהל שחזור: סדר פעולות שלב אחר שלב בעת אובדן קובץ, תיקייה או שרת שלם — מבחירת העותק הנדרש ועד לבדיקת שלמות הנתונים לאחר הפריסה.
• מדריך למנהל מערכת: פעולות שגרתיות — הוספת לקוח, הפעלת גיבוי שלא לפי לוח הזמנים, בדיקת מצב המשימות, ניתוח משימה שנכשלה לפי היומן.
• ניטור מוגדר: התראות על משימות שנכשלו ועל אמצעי אחסון שהתמלאו, כדי שהבעיה תעלה לפני שיידרש שחזור.
• פרוטוקול בדיקות קבלה: שחזור בקרה מעותק עם זמן ותוצאה מתועדים — הוכחה שהגיבויים אכן נקראים.

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

מקרה בוחן: קיצור זמן השחזור פי שלושה

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

מה היה לפני

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

מה שינינו

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

מה נהיה

זמן השחזור הצטמצם משש שעות לשעתיים, ותרחישים טיפוסיים — החזרת קובץ או טבלה — נסגרים בדקות ללא מעורבות אדם. הניתוח הידני של הלוגים נעלם: המהנדס רואה את סטטוס המשימה ואת נקודת השחזור בפאנל אחד. במשך חצי שנה אף אירוע לא הוביל לאובדן נתונים, ושיעור המשימות המוצלחות עלה מ-82% ל-99%.

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

במה שונה Bacula מ-Bareos ומה לבחור

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

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

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

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

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

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

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

ספקות טכניים נפוצים בעת הגדרת גיבוי

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

כיצד הנתונים מוגנים בעת הוצאת עותקים מחוץ לאתר?

העותקים מוצפנים בצד הלקוח לפני שליחה לאחסון חיצוני — המפתחות נשארים אצלכם, ולא אצל הספק. אחסון חיצוני נבנה לפי כלל 3-2-1: נתוני עבודה, עותק מקומי לשחזור מהיר ועותק חיצוני למקרה של כשל באתר כולו. ההעברה מתבצעת בערוץ מאובטח, והגישה לאחסון מוגבלת לחשבון נפרד עם הרשאות כתיבה בלבד.

האם הדה-דופליקציה לא מפריעה לשחזור ולא חוסכת על חשבון האמינות?

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

כיצד לוודא שהעותק אכן ישוחזר?

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

תארו את התשתית שלכם ואת דרישות האחסון — נחזור עם הערכה ותוכנית הגדרה.

בואו נדון במשימת הגיבוי שלכם

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

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

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

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

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