שחזור

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

דף השחזור

• תחומים מפרט את התחומים כאריחים, כל אחד עם כמה פריטים יש להם תצלומים.
• מה לשחזר? מחפש בפריטים של התחום שנבחר. כל שורה מציגה את התצלום החדש ביותר שלה, ופתיחת הפריט מובילה לדף של הפריט.
• Stacks מפרט את פרויקטי Compose עם לפחות שני קונטיינרים מגובים, כמו immich עם מסד הנתונים וה-Redis שלו. החיפוש מוצא stack לפי השם שלו או לפי כל אחד מהקונטיינרים שלו.
• רץ עכשיו מציג שחזור בזמן שהוא רץ, גם אחרי שסגרת את החלון שלו.
• חירום מתחיל את אשף החירום לשרת שנעלם או שהוקם מחדש, ראו אשף החירום.
• מקורות אחרים מחזיק את מתיקיית גיבויים ישנה, לגיבויים של BombVault אחרת, וייבוא מהתוסף Appdata.Backup.

חלון השחזור

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

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

4. לאן: היעד. האפשרויות תלויות בסוג הפריט:

   יעד	מה הוא עושה
   לצד המקור	ברירת המחדל. קונטיינר חוזר כקונטיינר שני בשם <name>-restored עם פורטים משלו, הדיסקים וה-NVRAM של מכונה וירטואלית נוחתים בתיקייה בשם <folder>-restored, וערכת תיקיות חוזרת כ-<path>-restored. שום דבר לא משתנה במקור.
   החלפת המקור	דורס את מה שיש עכשיו. עם גיבוי המצב הנוכחי קודם, שמופעל כברירת מחדל, BombVault מגבה קודם את המצב של היום כדי שאפשר יהיה לחזור. אם הגיבוי הזה נכשל, השחזור לא מתחיל. זה עובד גם לקונטיינר או למכונה וירטואלית שכבר לא נמצאים בשרת: התיקיות שהשחזור דורס מגובות בפני עצמן.
   לתיקייה	רק הקבצים, לעיון.
   הורדה כ-ZIP	כונן ה-flash, לדיסק-און-קי חדש. BombVault אף פעם לא כותבת לכונן ה-flash שפועל.
   למערך נתונים חדש ושחזור אל תוך מערך הנתונים	מערכי נתונים של ZFS, ראו מערכי נתונים של ZFS.

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

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

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

כמה דברים יכולים לעצור שחזור לפני שהוא משנה משהו. ה-IP הסטטי והפורטים שפורסמו של קונטיינר צריכים להיות פנויים, והרשת שלו צריכה להתקיים. ב-Unraid כל שחזור במקום מסרב לתיקייה שלא נמצאת על pool או שיתוף מעוגנים, כי הקבצים היו נוחתים בזיכרון ונעלמים אחרי אתחול. שחזור במקום מציין כל קונטיינר אחר שה-bind mount שלו מגיע לתיקייה שהוא כותב אליה, למשל "הנתיב הזה משמש גם את nextcloud-db", אבל זה רק מזהיר.

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

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

לאן שחזור לתיקייה הולך

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

דוגמה: להחזיר קובץ אחד

מישהו ערך אתמול בלילה את config.php של Nextcloud, ו-Nextcloud כבר לא עולה. הגיבוי הלילי מ-03:00 עדיין מחזיק את הקובץ התקין. אתה רוצה את הקובץ הזה, לא את כל הקונטיינר.

1. פותחים שחזור, בוחרים את האריח קונטיינרים ומקלידים nextcloud במה לשחזר?.
2. לוחצים על nextcloud. החלון נפתח עם גיבוי 03:00 נבחר מראש כמומלץ.
3. משאירים את מקור על מקומי.
4. תחת מה בוחרים קבצים בודדים. פותחים את התיקיות עד config ומסמנים את config.php.
5. תחת לאן בוחרים לתיקייה ובוחרים תיקייה, למשל user/restore, שהיא /mnt/user/restore במארח.
6. קוראים את מה קורה: הקובץ נוחת בתיקיית היעד, ושום דבר לא משתנה בקונטיינר. לוחצים שחזור.

החלון מסתיים ב-בוצע: הקבצים נמצאים ב-/mnt/user/restore. הקובץ נמצא כ-/mnt/user/restore/config.php, בלי התיקיות שמעליו. משווים אותו לקובץ השבור, מעתיקים אותו בחזרה לתיקיית appdata ומפעילים מחדש את Nextcloud.

כדי להחזיר את הקובץ ישר למקומו, בוחרים בשלב 5 החלפת המקור. משאירים גיבוי המצב הנוכחי קודם פועל, כך ש-BombVault מגבה את המצב השבור לפני שהיא כותבת, מקלידים nextcloud לאישור ולוחצים שחזור. Nextcloud נעצר בזמן שהקובץ שנבחר נכתב בחזרה למקומו ומופעל שוב אחר כך, ורק הקבצים שסימנת נכתבים. שחזור שנכשל באמצע משאיר את Nextcloud עצור, כי הקובץ שהוא קורא עלול להיות כתוב רק בחלקו, והריצה אומרת זאת.

מה חוזר, לפי סוג

קונטיינרים נוצרים מחדש מההגדרה השמורה שלהם דרך ה-Docker API, עם ה-entrypoint, שם המארח, הגדרות העצירה, ה-volumes וה-mounts, מגבלות המשאבים, מנהל היומן, הגדרות ה-DNS וה-links הישנים שלהם. קונטיינר חוזר על ה-image שעליו רץ כשהגיבוי נעשה, לא על חדש יותר שנמשך אחר כך, ו-image שחסר נמשך קודם, עם פרטי הגישה מRegistries של containers תחת הגדרות, שחזור. גם ה-GPU או סביבת הריצה שלו (--gpus, --runtime=nvidia) חוזרים. במארח בלי הדרייבר או סביבת הריצה הזו השחזור אומר זאת ומציע שחזור בלי GPU וסביבת ריצה. link לקונטיינר שחסר, או שעצור בזמן שהמשוחזר עולה, מושמט, והיסטוריית הריצות אומרת זאת. שחזור שנכשל אחרי שהקונטיינר הוסר מחזיר אותו, עצור.

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

VMs מקבלות את ה-XML שלהן מוגדר מחדש דרך SSH ואת הדיסקים וה-NVRAM של UEFI מחוברים מחדש, גם אחרי שהמכונה נמחקה. ראו גיבויי VM למכונות עם תצלומי Unraid ודיסקים על zvols.

ערכות תיקיות חוזרות עם הבעלות, ההרשאות וחותמות הזמן שלהן כפי ש-restic שומר אותן. כשהיעד מסרב רק לבעלות, כמו ש-/mnt/user עושה, הריצה מסתיימת בהערה שאומרת זאת. BombVault משווה אז את הקבצים לגיבוי, וקובץ שלא הגיע מכשיל את השחזור.

כונן ה-flash אף פעם לא נוגע ב-/boot החי. השחזור הוא הורדה בשם flash-<id>.zip, מוכנה להפלה ב-Unraid USB Creator. ה-ZIP מחזיק את APP_KEY, ולכן ההורדה שלו צריכה סיסמת התחברות וכניסה במופע. החלון מפרט גם את התוספים בכל גיבוי flash עם הגרסה והגודל שלהם, ויכול להחזיר אחד מהם לבדו ל-flash שפועל: קובץ ה-.plg שלו, התיקייה שלו תחת config/plugins וקובצי החבילה שהגיבוי מחזיק. Unraid מתקין אותו באתחול הבא, או מיד תחת Plugins, Install Plugin.

מערכי נתונים של ZFS יש להם יעדים משלהם והם שומרים על מאפייני ה-ZFS שלהם, ראו שחזור.

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

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

שחזור כמה פריטים בבת אחת

בדף השחזור בוחרים פריטים כמו שבוחרים שורות ברשימת הגיבויים: Ctrl+לחיצה, Shift+לחיצה, Ctrl+A, לחיצה ארוכה, או בחירה. שחזור פותח אז חלון אחד לכולם.

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

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

שחזור stack

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

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

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

מקורות אחרים

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

אחרי שחזור

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