לדלג לתוכן

פתרון בעיות

שאלות נפוצות קצרות. לטבלת פתרון הבעיות המלאה בצד המארח של VM-דרך-SSH (permission-denied, אימות מפתח-מארח, משתני תבנית חסרים ועוד), ראה את מדריך גיבוי VM דרך SSH ב-GitHub.

משהו אינו מחווט נכון

פתח את /spike בממשק הווב. בדיקת שילוב המארח בודקת כל עיגון ו-CLI (Docker socket, libvirt, restic, qemu-img, rclone) ומדווחת על כל חלק חסר. התחל כאן לפני שאתה מניח באג: עיגון חסר או מארח בלתי-נגיש מופיע מיד.

אני לא יכול להגיע לממשק הווב

BombVault מגישה HTTPS מהקופסה בפורט 3443 (אישור בחתימה עצמית), אז פתח את https://<your-unraid-ip>:3443. קבל את אזהרת האישור בחתימה עצמית, או הצב את BombVault מאחורי reverse proxy עם האישור שלך. אם אתה מריץ עם HTTP_ONLY=true, היא מגישה HTTP פשוט בפורט 3000 במקום (מיועד לשימוש מאחורי proxy מסיים-TLS).

איבדתי את ה-APP_KEY שלי

APP_KEY גוזר את סיסמת מאגר ה-restic. בלעדיו (ובלי ערכת שחזור מפתח ההצפנה), הגיבויים המוצפנים אינם ניתנים לשחזור. זו הסיבה שלוח הבקרה נודנק לך להוריד את ערכת השחזור. ראה מחוץ לאתר והתאוששות. צור מפתח עם openssl rand -hex 32 ואחסן אותו מחוץ לשרת לפני שאתה מסתמך על גיבוי כלשהו.

גיבוי VM אינו מתחבר

גיבוי VM מדבר עם libvirt דרך SSH, לעולם לא עיגון.

  • ודא ש-SSH מופעל במארח ושהמפתח הציבורי של BombVault מורשה ב-/root/.ssh/authorized_keys (הגדרות, אינטגרציות, SSH למארח מציג את המפתח וכפתור בדוק חיבור).
  • ברשת br0.x מותאמת אישית, קבע את LIBVIRT_HOST לכתובת ה-LAN IP של Unraid שלך (ה-container אינו יכול להגיע למארח דרך host.docker.internal שם). הפעל Settings, Docker, Host access to custom networks.
  • אם שינית את פורט ה-SSH של Unraid, קבע את LIBVIRT_SSH_PORT בהתאמה.
  • אבחון מלא שלב-אחר-שלב (בדיקת נגישות, ניתוב VLAN, Permission denied (publickey), Host key verification failed) נמצא במדריך גיבוי VM דרך SSH.

תמונת מצב חיה של VM לא רצה

תמונות מצב חיות דורשות את qemu guest agent מותקן ב-VM ואת הדיסק על /mnt/cache (או /mnt/diskX), לא /mnt/user. ב-VM כבויה, live נסוג אוטומטית ל-graceful. גיבוי graceful מכבה את ה-VM, מגבה את הדיסקים, ואז מפעיל אותה מחדש, כך שהוא תמיד עקבי.

גיבוי נכשל עם "repository is already locked"

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

העותק שלי מחוץ לאתר לא קרה אחרי גיבוי

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

שחזור בוטל לפני שהתחיל

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

ייצוא רגיל נכשל במקום לכתוב קובץ

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

דאמפ של מסד נתונים נכשל

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

  • ההתחברות נדחתה. הדאמפ מתחבר עם משתני הסיסמה של הקונטיינר עצמו (POSTGRES_PASSWORD, MARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD או גרסאות ה-_FILE שלהם). בדוק אותם בקונטיינר של מסד הנתונים. משתנה _FILE שמצביע על סוד שמשתמש הקונטיינר אינו רשאי לקרוא נכשל באותו אופן.
  • הרשאות חסרות. עם סיסמת root אקראית הדאמפ יכול להתחבר רק כמשתמש האפליקציה, ולכן הוא מכיל רק את מסד הנתונים ההוא, ו-MySQL 8.4 ומעלה עשוי לסרב לגמרי. תן לקונטיינר סיסמת root אמיתית, או כבה עבורו את הדאמפ.
  • טבלאות המערכת דורשות שדרוג. MariaDB מסרבת לדאמפ כשטבלאות המערכת שלה מגיעות מגרסה ישנה יותר (שגיאה 1558). הוסף את המשתנה MARIADB_AUTO_UPGRADE=1 והפעל את הקונטיינר מחדש, או הרץ בתוכו פעם אחת mariadb-upgrade.
  • אין כלי דאמפ. אימג' רזה או עצמי בלי pg_dump, mysqldump או mariadb-dump אינו ניתן לדאמפ. השתמש באימג' הרשמי, או כבה את הדאמפ.
  • מגבלת זמן. לדאמפ יש DB_DUMP_MAX_HOURS (ברירת מחדל 6), לגיבוי שסביבו יש BACKUP_MAX_HOURS, ודאמפ שמפסיק להתקדם נקטע אחרי BACKUP_STALL_HOURS. מאחורי האחרון עומד בדרך כלל נעילה שהאפליקציה מחזיקה. הגדל את המגבלה שפעלה, או בצע את הדאמפ כשהאפליקציה רגועה.
  • הקונטיינר מושהה או מתחיל מחדש. הדאמפ מדבר עם השרת הפועל. אם הקונטיינר מתחיל מחדש שוב ושוב, היומן שלו אומר למה.
  • דאמפ פגום לא ניתן היה להסרה. דאמפ ש-BombVault לא הצליח לסיים נמחק. כשהמחיקה הזאת נכשלת, הדאמפ נשאר ברשימה מסומן כפגום ואפשר למחוק אותו משם.

ייבוא נכשל

ייבוא עוצר את הקונטיינר, מזיז הצידה את תיקיית הנתונים שלו ונותן לאימג' ליצור במקומה תיקייה ריקה. אם שלב שלפני הייבוא עצמו נכשל, התיקייה הישנה מוחזרת למקומה מעצמה. אם הייבוא נכשל, הקונטיינר נשאר עם התיקייה החדשה והישנה נשארת לידה בשם <תיקיית הנתונים>.bombvault-before-import-<חותמת זמן>; הודעת השגיאה של ההרצה נוקבת בנתיב המדויק.

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

גיבוי של מערך נתונים ZFS נכשל או דילג על מערך

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

  • snapshot-loop: התצלום לא הגיע ל-BombVault כי Host Data לא מעביר עיגונים חדשים. ערוך את הקונטיינר, קבע את Access Mode של Host Data ל-Read/Write - Slave והפעל מחדש את BombVault.
  • key-not-loaded: מערך נתונים מוצפן שהמפתח שלו לא נטען מדולג. טען את המפתח עם zfs load-key ועגן את המערך; הגיבוי הבא יכלול אותו.
  • ssh-auth: השרת דחה את המפתח של BombVault. כרטיס החיבור בדף ZFS מציג את הפקודה שמאשרת אותו; הרץ אותה פעם אחת על השרת.

פריט נשאר על "לומד N/10"

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

השמירה הפסיקה למחוק גיבויים ישנים של פריט אחד

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

ניקוי ידני אומר שחלק מהפריטים נשמרו

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

ייבוא ההיסטוריה אומר שלא ניתן היה לקרוא מאגר

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

אזהרת שטח הדיסק לא תואמת ללוח הבקרה של Unraid

בשיתוף המשתמש של Unraid (/mnt/user) המקום הפנוי הוא של המערך כולו, לא של דיסק אחד. מאגרים מרוחקים נמדדים רק דרך מרוחקים של rclone שמדווחים על המקום הפנוי שלהם; למאגרי S3, B2, REST ו-SFTP אין נתון והם מופיעים כלא נמדדים בכרטיס חריגות.

עוזר בינה מלאכותית לא מצליח להתחבר

הדף שרת MCP מסביר מה המשמעות של כל קוד מצב ושל כל סירוב של נקודת החיבור של MCP, ומה אפשר לעשות.

ה-container ממשיך להתחיל מחדש או נראה לא תקין

BombVault מדווחת על מצב תקין/לא תקין מה-/api/health שלה עצמה. כלי auto-heal (כמו Autoheal) יכול להפעיל אותה מחדש אוטומטית אם המנוע אי-פעם נתקע. בדוק את יומן ה-container ואת דוח ה-/spike לסיבה הבסיסית.

עדיין תקוע?