מדריך התקנת Chaptarr על שרת VPS ב-Docker

מהו Chaptarr ומדוע משתמשי Readarr זקוקים לו

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

הפרויקט Readarr הופסק ב־27 ביוני 2025. ההודעה הרשמית של צוות Servarr מפרטת את הסיבה: המטא-דאטה של הפרויקט הפך לבלתי שמיש, והמאמץ הקהילתי למעבר ל-Open Library נתקע. המאגר הועבר לארכיון. מצב זה הותיר אוספי ספרים וספרי שמע ללא מנהל מתוחזק, ו-Chaptarr לקח על עצמו את התפקיד. הוא שומר על המבנה המוכר לכם מ-Sonarr ומ-Radarr (אינדקסרים, לקוחות הורדה, פרופילי איכות, תיקיות שורש) ומוסיף טיפול בספרי שמע: ארגון מודע לקריין, מהדורות מרובות לאותו כותר, תמיכה ב-M4B וב-MP3 מחולק לפרקים, והמרה מ-MP3 ל-M4B.

מדריך זה השתמש בתג התמונה chaptarr/chaptarr:0.9.925, שהיה השחרור העדכני ביותר ב-9 באוגוסט 2026. Chaptarr מגדיר את עצמו כתוכנת בטא. קראו את סעיף התחזוקה לקראת סוף המדריך לפני שתפנו אותו לספרייה שאינכם יכולים לשחזר.

דרישות קדם

שרת VPS המריץ את Docker ואת התוסף Compose, עם נפח אחסון מספיק עבור הספרייה. ספרי שמע תופסים נפח רב, ופעולת ייבוא שאינה יכולה להשתמש ב-hardlinks שומרת זמנית שני עותקים של הקובץ, כפי שמוסבר בסעיף ה-volumes להלן. אם Docker עדיין לא מותקן על השרת, התחילו ב-התקנה והרצה של Docker על גבי VPS וחזרו לכאן.

Chaptarr מופץ כרגע כ-Docker image בלבד. גרסה מקומית ל-Windows נמצאת בתהליך פיתוח, ואין כרגע חבילות הפצה אחרות. המכולה שומרת את מסד הנתונים שלה ב-/config כ-SQLite כברירת מחדל, וניתן להשתמש בשרת PostgreSQL חיצוני באמצעות משתני סביבה מסוג Chaptarr__Postgres__* אם כבר קיים שרת כזה ברשותכם. SQLite הוא הבחירה המתאימה עבור משתמש יחיד על שרת בודד.

שירות ה-Compose עבור Chaptarr

שירות זה משתלב במערך (stack) קיים. הוא מקבע גרסה משוחררת (tag), מפרסם את ממשק ה-web ב-loopback בלבד, ומצטרף לרשת שבה כבר משתמש לקוח ההורדות שלך.

services:
  chaptarr:
    image: chaptarr/chaptarr:0.9.925
    container_name: chaptarr
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - /srv/media/audiobooks:/audiobooks
      - /srv/media/ebooks:/ebooks
      - /srv/media/downloads:/downloads
    ports:
      - 127.0.0.1:8789:8789
    restart: unless-stopped
    networks:
      - arr

networks:
  arr:
    external: true

השורה external: true מציינת "רשת זו כבר קיימת, התחבר אליה". השתמש בה כאשר Prowlarr ולקוח ה-torrent שלך מגיעים ממיזם (project) Compose שונה, כיוון שקובץ Compose שני יוצר אחרת רשת מבודדת משלו, ו-Chaptarr לא יוכל לעולם לפתור את qbittorrent לפי שם. השג את השם האמיתי מ-docker network ls. אם המערך שלך כבר נמצא בקובץ אחד, הוסף את השירות chaptarr: לאותו קובץ ומחק את כל בלוק ה-networks: במקום זאת. המבנה הרחב יותר מכוסה ב-מערך arr מלא תחת Docker Compose, וכללי השמות ב-כיצד רשתות Compose ושמות שירותים נפתרים.

צור את ספריית התצורה בעצמך, ולאחר מכן הפעל אותו.

mkdir -p ./config
sudo chown 1000:1000 ./config
docker compose up -d
docker compose ps
docker compose logs -f chaptarr

docker compose ps אמור להציג את המכולה כ-Up. מכולה שמופיעה כ-Restarting נכשלה בהפעלה והמערכת מנסה להפעילה מחדש; הסיבה לכך היא כמעט תמיד ספריית התצורה. הלוג מפסיק לרוץ ברגע שהיישום מאזין בפורט 8789.

PUID, PGID והספרייה ש־Docker יוצר כ־root

כאשר משאירים את PUID=99 ו־PGID=100 ללא הגדרה, Chaptarr משתמשת בערכי ברירת המחדל שלהם. אלו ערכים האופייניים ל־unRAID, ובשרת VPS סטנדרטי של Ubuntu הם אינם משויכים למשתמש מוגדר, מה שגורם לכך שקבצים נוצרים עם בעלות שאינה מאפשרת למשתמש שלכם לכתוב אליהם. בדקו את המזהים שלכם באמצעות הפקודות id -u ו־id -g והזינו אותם לקובץ.

כל מכולה שניגשת לאותם קבצים חייבת להשתמש באותו זוג מזהים. לקוח ההורדות כותב לתוך /srv/media/downloads, Chaptarr מעבירה את הקובץ ל-/srv/media/audiobooks, והנגן קורא אותו משם. אם לקוח ההורדות כותב כ-1000:1000 ו-Chaptarr רצה כ-99:100, הייבוא ייכשל כיוון ש-Chaptarr אינה יכולה למחוק או להעביר קובץ שאינו בבעלותה. UMASK=002 מאפשרת כתיבה לקבוצה עבור קבצים חדשים, וזהו המצב הרצוי כאשר כמה מכולות חולקות קבוצת מדיה אחת. המיפוי המלא מופיע ב-כיצד PUID ו-PGID ממפים משתמש מכולה לקבצים במערכת המארחת.

הקובץ README מזהיר מפני מלכודת ספציפית אחת, וכדאי לחזור עליה. אם ./config אינה קיימת בעת הרצת docker compose up, Docker תיצור אותה עבורכם בבעלות root:root. המכולה תרוץ לאחר מכן כ-UID 1000 ולא תוכל לכתוב למסד הנתונים של עצמה, לכן היא תצא ותופעל מחדש ללא הפסקה. בדקו זאת באמצעות ls -ln ./config, המציגה מזהים מספריים של בעלים במקום שמות. שני אפסים מציינים שהבעלים הוא root. תקנו זאת באמצעות sudo chown -R 1000:1000 ./config והפעילו את המכולה מחדש.

מדוע הפרדת נפחי ספרי שמע וספרים אלקטרוניים מונעת שימוש ב-hardlinks

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

‏Hardlink הוא שם נוסף לאותו מידע על הדיסק. הוא אינו צורך שטח אחסון נוסף ופעולתו מיידית, וזו הסיבה שמשפחת ה-arr מעדיפה אותו על פני העתקה. ‏Hardlink עובד רק בתוך מערכת קבצים אחת. בתוך ה-container אלו הן שלוש נקודות עיגון (mount points) נפרדות, לכן ה-kernel מסרב ליצור את הקישור גם כאשר הנתיבים ב-host נמצאים על אותו דיסק. ניתן לבדוק זאת בעצמכם.

docker exec chaptarr sh -c 'touch /downloads/linktest && ln /downloads/linktest /audiobooks/linktest'

הפקודה נכשלת עם שגיאה שמסתיימת ב-Invalid cross-device link. זהו ה-kernel שמסרב לבצע קישור בין נקודות עיגון שונות, וזו הסיבה המדויקת לכך ש-Chaptarr חוזר לביצוע העתקה של הקובץ. ההעתקה תקינה אך איטית יותר, וספר השמע קיים כעת פעמיים עד למחיקת ה-torrent, דבר שלא תעשו כל עוד אתם עדיין בסטטוס seeding. מחקו את /srv/media/downloads/linktest לאחר מכן.

כדי לשמר את ה-hardlinks, עגנו תיקיית אב אחת בלבד:

    volumes:
      - ./config:/config
      - /srv/media:/data

לאחר מכן, הגדירו את תיקיות השורש בתוך Chaptarr ל-/data/audiobooks ו-/data/ebooks, ותנו ללקוח ההורדות את אותו עיגון /srv/media:/data כך ששני ה-containers יראו נתיב זהה. ודאו תחילה שהצד של ה-host הוא מערכת קבצים אחת: df -h /srv/media/downloads /srv/media/audiobooks חייב להציג את אותו ערך בעמודת ה-Filesystem עבור שניהם. ערכים שונים משמעותם דיסקים שונים, ושום מבנה עיגון לא יאפשר יצירת hardlinks ביניהם. הפשרה בין שיטה זו לבין named storage מפורטת ב-bind mounts מול named volumes עבור מדיה.

גישה לממשק הניהול ללא חשיפה לרשת

שורת ה־port מפרסמת את השירות ב־127.0.0.1 מסיבה מסוימת. ufw deny 8789 אינו מגן על פורט של Docker שפורסם, כיוון ש־Docker כותב חוקי NAT (תרגום כתובות רשת) משלו לשרשרת שהקרנל ניגש אליה לפני זו של ufw, ולכן התעבורה מועברת לפני שהחוק שלכם נבדק בכלל. התנהגות זו מפתיעה משתמשים לעיתים קרובות, והיא מוסברת ב־מדוע פורט של Docker שפורסם מתעלם מחוקי ה-ufw שלכם. קישור (binding) ל-loopback עוקף זאת לחלוטין.

גשו לממשק המשתמש דרך מנהרת SSH מהמחשב שלכם:

ssh -N -L 8789:127.0.0.1:8789 you@your-server

השאירו את התהליך רץ ופתחו את http://127.0.0.1:8789 בדפדפן. הגדירו אימות (authentication) בהרצה הראשונה. רק לאחר מכן כדאי לשקול שימוש ב-reverse proxy עם TLS (אבטחת שכבת תעבורה) לפניו. ברגע שתתחילו להשתמש במנהרות עבור שלושה או ארבעה כלים כאלו, כשבכל אחד מהם סיסמה נפרדת, הפתרון המסודר יותר הוא להציב את ה-proxy מאחורי שרת Single Sign-On בניהול עצמי כגון Authentik, כך שחיבור אחד יכסה את כל היישומים וביטול הרשאה אחד יחסום את כולם.

חיבור אינדקסרים ולקוח הורדות

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

הגדרה אחת גורמת כמעט לכולם לטעות. כאשר Chaptarr מבקש את כתובת המארח (host) של לקוח ההורדות, אל תקלידו localhost או 127.0.0.1. בתוך מכולה (container), כתובת זו היא המכולה עצמה; לכן, Chaptarr מנסה לתקשר עם פורט 8080 של עצמו ומדווח על כשל בחיבור. השתמשו בשם המכולה, qbittorrent, עם הפורט 8080. ודאו ששתי המכולות נמצאות על אותה רשת באמצעות הפקודה docker network inspect arr, המציגה את כל המכולות המחוברות לפי שם.

אם לקוח ההורדות שלכם רץ דרך מכולת VPN עם network_mode: "service:gluetun", אין לו שם משלו ברשת, כיוון שהוא חולק את מרחב השמות (namespace) של הרשת עם Gluetun. פנו אליו כ-gluetun בפורט ש-Gluetun חושף. סידור זה, והניתוב הנלווה אליו, מפורטים ב-ניתוב לקוח הורדות דרך Gluetun.

המעבר ל-Readarr: מהו המחיר האמיתי של הגירה

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

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

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

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

העברת ספרי השמע לנגן

Chaptarr מארגנת קבצים. ניגונם הוא תפקידה של תוכנה אחרת, ו-Audiobookshelf היא השותפה המקובלת לכך, כיוון שהיא עוקבת אחר מיקום ההאזנה שלכם בין מכשירים שונים וכוללת אפליקציות לטלפון. האימג' הרשמי שלה הוא ghcr.io/advplyr/audiobookshelf:latest, ודוגמת ה-Compose המתועדת שלה מפרסמת את פורט 13378 של המארח אל פורט 80 של הקונטיינר.

  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    container_name: audiobookshelf
    ports:
      - 127.0.0.1:13378:80
    volumes:
      - ./abs/config:/config
      - ./abs/metadata:/metadata
      - /srv/media/audiobooks:/audiobooks
    environment:
      - TZ=Europe/Berlin
    restart: unless-stopped

בצעו mount לאותו נתיב מארח שאליו Chaptarr כותבת, ולאחר מכן הוסיפו את /audiobooks כספרייה בתוך ממשק ה-web. ייבוא חדש יופיע לאחר הסריקה הבאה.

אם אתם כבר מריצים את Jellyfin, תוכלו להוסיף את התיקייה כספרייה שם והיא תנגן את הקבצים, אם כי התנהגות ה-resume בקובץ ספר שמע ארוך בודד חלשה יותר מאשר בשרת ספרי שמע ייעודי. הגדרת צד זה מכוסה ב-הרצת Jellyfin כשרת מדיה על גבי VPS. עבור החלק של הספרים הדיגיטליים, העבירו את /srv/media/ebooks ליישום קורא; עבודתה של Chaptarr מסתיימת ברגע שהקובץ מקבל שם וממוין.

סיכוני תחזוקה: רישיון, סביבת הרצה ותגיות גרסה דינמיות

Chaptarr מופץ תחת רישיון GPL-3.0, זכויות היוצרים שייכות לתורמי Chaptarr עם חלקים מצוות Servarr, כך שהקוד נשאר פתוח וכל אחד יכול לבצע לו fork אם המפתח הנוכחי יפסיק את פעילותו. הפרויקט מבוסס על .NET 10, גרסת ה-runtime עם תמיכה ארוכת טווח (LTS) נכון לאוגוסט 2026, מה שאומר שהבסיס נתמך לשנים ולא לחודשים בלבד. שתי העובדות הללו חשובות אם אתם מעריכים האם הפרויקט הזה עדיין יהיה קיים בשנה הבאה.

מספרי הגרסאות מתעדכנים במהירות. גרסאות מפורסמות כ-pre-releases, והגרסה 0.9.925 שוחררה באותו יום שבו נכתב מדריך זה. קבעו תגית (tag) מדויקת. שימוש ב-latest אומר ש-docker compose pull לא מנוטר עלול להקפיץ אתכם כמה גרסאות בשבוע אחד, ופרויקט fork צעיר כל כך עלול לשנות את ה-API שלו בין גרסאות, מה שישבור כל סקריפט או לוח בקרה שכתבתם מולו.

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

docker compose stop chaptarr
sudo tar czf chaptarr-config-backup.tgz ./config
docker compose start chaptarr

docker compose pull chaptarr
docker compose up -d chaptarr

הפרויקט מדווח שלא אירעו אובדני נתונים במשך כחצי שנה ובקרב יותר מ־11000 משתמשים, ובכל זאת ממליץ לשמור גיבויים ולא להפנות אותו לספרייה שאי־אפשר להרשות לעצמכם לאבד. התייחסו ברצינות לשני החלקים. העתיקו את ארכיון התצורה אל מחוץ לשרת, משום שגיבוי שנמצא באותו דיסק כמו הנתונים שעליהם הוא מגן אינו גיבוי. קובץ tar יחיד זה מספיק רק משום ש־Chaptarr שומר את מצבו בקובץ SQLite יחיד תחת /config; כל נתון שנמצא בשרת מסד נתונים נפרד דורש גם יצוא של מסד הנתונים. זה המבנה של שלב הגיבוי כאשר מארחים את Chatwoot בעצמכם ב־VPS לצד נתוני Postgres והקבצים שהועלו.

מצבי כשל והודעות שגיאה נפוצות

המכולה מבצעת אתחול בלולאה. docker compose ps מציג Restarting. הריצו את ls -ln ./config. שני אפסים בעמודות הבעלים מעידים על כך ש-Docker יצר את הספרייה כ-root, ולכן המשתמש של המכולה אינו יכול לכתוב למסד הנתונים שלה. הריצו את sudo chown -R 1000:1000 ./config.

ייבוא לא מסתיים והקבצים נשארים בתיקיית ההורדות. Chaptarr מסוגל לקרוא את ההורדה אך אינו יכול לכתוב לספרייה. השוו את ls -ln /srv/media/audiobooks מול ה-PUID וה-PGID שלכם. ספרייה בבעלות UID שונה, או בבעלות הקבוצה שלכם ללא הרשאות כתיבה לקבוצה, תמנע את העברת הקבצים. UMASK=002 מונע את המקרה השני עבור קבצים חדשים.

ניצול הדיסק מוכפל לאחר כל ייבוא. לא נוצר hardlink, ולכן הקובץ הועתק. הריצו את בדיקת ln מתוך סעיף ה-volumes. שגיאה שמסתיימת ב-Invalid cross-device link מאשרת זאת, והפתרון הוא שימוש ב-mount בעל הורה יחיד.

לקוח ההורדות אינו מתחבר. הזנתם את localhost ככתובת ה-host. בתוך המכולה, כתובת זו היא Chaptarr עצמו. השתמשו בשם המכולה וודאו ש-docker network inspect arr מציג את שתי המכולות.

Compose מסרב להפעיל את השירות. Bind for 127.0.0.1:8789 failed: port is already allocated מציין שתהליך אחר תופס את הפורט. מצאו אותו באמצעות sudo ss -lntp | grep 8789.

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

FAQ

האם ניתן להעביר את ספריית ה-Readarr שלי ל-Chaptarr?

לא באמצעות ייבוא ישיר. Chaptarr אינו תואם למקורות המטא-דאטה של Readarr ומשתמש בצינור ספקים (provider pipeline) משלו, לכן המזהים השמורים של Readarr חסרי משמעות ואין כלי להמרת מסד הנתונים. הקבצים שלכם בדיסק נשארים ללא שינוי. עליכם להוסיף את אותם נתיבים כתיקיות שורש (root folders), להריץ ייבוא ספרייה, ולתת ל-Chaptarr לבצע התאמה לקבצים בעצמו. פרופילי איכות, פורמט שמות, הגדרות אינדקסר וכל התאמה שגויה דורשים עבודה ידנית, לכן מומלץ להתחיל עם תיקייה קטנה אחת לפני ייבוא של כל הספרייה.

מדוע Chaptarr לא מצליח לכתוב לתיקיית ספרי השמע שלי?

המשתמש של המכולה (container) אינו הבעלים של הקבצים. Chaptarr חוזר לערכי ברירת המחדל PUID=99 ו-PGID=100 כאשר משתנים אלו אינם מוגדרים; אלו ערכים של unRAID שאינם מתאימים לשרת VPS סטנדרטי מבוסס Ubuntu. הגדירו אותם ל-id -u ו-id -g שלכם, השתמשו באותו זוג בלקוח ההורדות, והגדירו UMASK=002 כדי שקבצים חדשים יישארו ניתנים לכתיבה על ידי הקבוצה. בדקו בעלות באמצעות ls -ln על ספריית הספרייה, שכן הפקודה מציגה מספרים במקום שמות, מה שמאפשר השוואה מדויקת.

מדוע ניצול הדיסק שלי הוכפל לאחר הייבוא?

Chaptarr העתיק את הקובץ מכיוון שלא הצליח ליצור קישור קשיח (hardlink). מיפוי של /downloads ו-/audiobooks כ-binds נפרדים הופך אותם לנקודות עיגון (mount points) נפרדות בתוך המכולה, והליבה (kernel) מסרבת ליצור קישור קשיח בין נקודות עיגון שונות עם השגיאה Invalid cross-device link. עגנו תיקיית אב אחת כמו /srv/media:/data והשתמשו ב-/data/downloads ו-/data/audiobooks בתוך היישום. שני הנתיבים חייבים לשבת על אותה מערכת קבצים מארחת, דבר שניתן לאמת באמצעות df -h.

האם Chaptarr מנגן את ספרי השמע שלי?

לא. הוא מוצא, מוריד, משנה שמות ומסדר אותם, אך הניגון הוא תוכנה נפרדת. Audiobookshelf הוא השילוב הנפוץ ביותר מכיוון שהוא זוכר את מיקום הניגון בין מכשירים שונים, תוך שימוש בתמונה הרשמית ghcr.io/advplyr/audiobookshelf:latest עם אותו נתיב ספרי שמע מארח מעוגן. גם Jellyfin ינגן את הקבצים אם תוסיפו את התיקייה כספרייה, אך התנהגות המשך הניגון (resume) חלשה יותר בספרי שמע ארוכים המורכבים מקובץ בודד.

האם בטוח להריץ את Chaptarr על ספרייה שחשובה לי?

זוהי תוכנת בטא מ-fork צעיר, והפרויקט מצהיר על כך בעצמו, אם כי לא דווח על אירועי אובדן נתונים במשך כשישה חודשים ועל ידי למעלה מ-11,000 משתמשים. החלקים המרגיעים הם רישיון ה-GPL-3.0, שמאפשר להמשיך ולפתח את הקוד, ובסיס ה-.NET 10, שהוא runtime עם תמיכה לטווח ארוך (LTS) נכון לאוגוסט 2026. הצמידו תג תמונה מדויק כמו 0.9.925 במקום latest, בצעו גיבוי ל-/config לפני כל שדרוג, ושמרו את הארכיון מחוץ לשרת.