Restic או BorgBackup: איך לבחור כלי גיבוי ללינוקס?

השוואה בין Restic לבין BorgBackup בפסקה אחת

Restic ו־BorgBackup מבצעים שניהם את אותה משימה בסיסית: גיבויים מצטברים, מוצפנים ומבוססי דה-דופליקציה של שרת Linux. ההבדל המכריע בבחירה ביניהם הוא יעד הגיבוי. Restic תומך באופן טבעי ב־S3 ובממשקי API אחרים של אחסון אובייקטים, כך ש־bucket הוא יעד מדרגה ראשונה שאינו דורש התקנת תוכנה בצד המרוחק. לעומת זאת, Borg מחייב התקנה של התוכנית borg על המכונה המאחסנת את ה־repository, כיוון ש־repository של Borg מנוהל על ידי תהליך פעיל ולא על ידי מערכת קבצים או API. אם יעד הגיבוי שלכם הוא אחסון אובייקטים, זו התשובה עבורכם. אם היעד הוא שרת Linux נוסף שבשליטתכם, Borg הוא אופציה רלוונטית ולעיתים קרובות מהירה יותר.

כל שאר ההבדלים משניים. שניהם מפצלים קבצים באמצעות content defined chunking, כך שספרייה של 40 GB שהשתנתה ב־200 MB תעלה בערך 200 MB בלבד. שניהם מבצעים הצפנה בצד הלקוח. שניהם מאפשרים לעגן (mount) snapshot באמצעות FUSE (מערכת קבצים במרחב המשתמש) כדי לשלוף קובץ בודד. נכון ליולי 2026, הגרסה של restic היא 0.19.1, בעוד סדרת הגרסאות היציבה של Borg היא 1.4, בגרסה 1.4.5. גרסה 2.0 של Borg נמצאת בבטא מזה שנים ועדיין מוגדרת כגרסת בדיקה בלבד, לכן 1.4 היא הגרסה שיש להטמיע כיום.

מודל המאגר הוא ההבדל המהותי

מאגר restic הוא ספריית קבצים: config, keys/, snapshots/, index/, ו-data/ המלאים בקובצי pack. אין צורך בדבר נוסף כדי לקרוא אותו. זו הסיבה ש-restic מסוגל לעבוד עם מגוון כה רחב של backend. כל אחסון המסוגל לבצע פעולות put, get, list ו-delete ל-blobs יכול להכיל מאגר restic; כך קובץ בינארי יחיד תומך בנתיבים מקומיים, SFTP, שרת REST עצמאי, S3, Backblaze B2, Azure, Google Cloud Storage, וכל יעד ש-rclone מסוגל להגיע אליו.

מאגר Borg מורכב גם הוא מקבצים על הדיסק, אך Borg לעולם אינו ניגש אליהם דרך תעבורה פשוטה (dumb transport). עבור מאגר מרוחק, Borg מפעיל את borg serve בצד המרוחק באמצעות SSH ומנהל פרוטוקול תקשורת מול תהליך זה. הצד של השרת מבצע עבודה ממשית: הוא מחזיק את המאגר, מחיל את הטרנזקציה ועונה על שאילתות אינדקס. זו הסיבה של-Borg אין backend מסוג S3 וזו הסיבה שהפרויקט לא הוסיף תמיכה כזו. אין תהליך שניתן להריץ בתוך bucket.

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

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

הצפנה: ניתן לכבות את אחת האפשרויות

Restic מוצפן תמיד. לא קיים מצב ללא הצפנה. restic init מבקש סיסמה, גוזר ממנה מפתח באמצעות scrypt, וכל קובץ pack שנכתב לאחר מכן עובר הצפנה ואימות. אובדן הסיסמה משמעו אובדן הנתונים, שכן מסיבות תכנוניות לא קיים מסלול שחזור.

Borg הופך את ההצפנה לבחירה בעת יצירת ה-repository, וזו בחירה קבועה. borg init --encryption=repokey שומר את המפתח המוצפן בתוך ה-repository, כך שניתן לבצע שחזור באמצעות ה-passphrase בלבד. --encryption=keyfile שומר את המפתח בצד הלקוח בתוך ~/.config/borg/keys/, כך שמי שגונב את ה-repository כולו לא מחזיק בדבר; המשמעות היא שחובה לגבות את קובץ המפתח בנפרד, אחרת הארכיונים לא יהיו קריאים. לכל מצב קיימת גרסת -blake2 המבצעת אימות באמצעות BLAKE2b במקום HMAC-SHA256, מה שמהיר יותר בחומרה ללא האצת SHA. קיימת גם אפשרות --encryption=none, והיא מהווה בחירה לגיטימית כאשר ה-repository מאוחסן על גבי דיסק מוצפן שבבעלותכם.

הכלל המעשי: השתמשו ב-repokey-blake2 עבור גיבוי שרת רגיל, ב-keyfile כאשר ה-repository נמצא במקום שאינכם סומכים עליו לחלוטין, ולעולם אל תשתמשו ב-none על מכונה מושכרת.

דחיסה, ומדוע restic קיבלה אותה באיחור

ל־Borg יש דחיסה מראשית דרכה. ברירת המחדל היא lz4, שנבחרה כיוון שהיא מהירה מספיק כדי להשאיר אותה פעילה עבור הכל. zstd מקבלת רמות מ־1 עד 22 וברירת המחדל שלה היא 3, zlib ו־lzma קיימות למקרים שבהם אתם מעדיפים חיסכון בבתים על פני זמן, ו־auto מריצה היוריסטיקה לכל chunk כך שנתונים שכבר דחוסים לא נדחסים פעמיים.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

ל־restic לא הייתה דחיסה כלל עד פורמט מאגר 2, הדורש restic 0.14.0 ומעלה. פורמט 2 הוא כעת ברירת המחדל עבור מאגר חדש, והדחיסה מוגדרת באמצעות --compression בערכים auto, off או max. מאגר ישן בפורמט 1 נשאר ללא דחיסה עד שתבצעו לו הגירה. לכן, אם מאגר ה־restic שלכם נוצר לפני גרסה 0.14 ומעולם לא ביצעתם הגירה, אתם עדיין משלמים בנפח מלא עבור טקסט, לוגים וגיבויי מסדי נתונים.

יעדים מרוחקים: S3 לעומת SSH

כאן מתקבלת בדרך כלל ההחלטה.

כדי ש־restic יתחבר ל־S3, הוא זקוק לפרטי הזדהות במשתני הסביבה, ללא צורך בהרצת תהליך כלשהו בצד המרוחק. אותו דפוס עובד גם מול bucket שאתם מארחים בעצמכם, שילוב נפוץ למדי: הריצו MinIO עבור ממשק S3 בשרת ה־VPS שלכם והפנו את restic אליו.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

כדי ש־Borg יתחבר למאגר מרוחק, הוא זקוק לגישת SSH ולהתקנה של Borg בצד המרוחק, כאשר הגרסאות חייבות להיות תואמות. זהו חיכוך מיותר אם הצד המרוחק אינו בשליטתכם. לעומת זאת, אם מדובר בשרת שני שאתם ממילא מנהלים, מדובר ביתרון משמעותי: זה מאפשר לכם את השליטה החזקה ביותר נגד כופרות מבין שני הכלים, באמצעות מפתח SSH במצב append only. הגדירו את המפתח כך שיריץ את borg serve, וכך הלקוח יוכל להוסיף ארכיונים אך לא למחוק אותם; כך, גם אם מכונה נפרצה, היא לא תוכל למחוק את היסטוריית הגיבויים של עצמה.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

ל־restic יש פתרון מקביל רק כאשר מריצים את שרת ה־REST הייעודי שלו, התומך במצב append only. מול S3 רגיל, ניתן להשיג את אותה תוצאה באמצעות מדיניות bucket או object lock, שהן באחריות ספק השירות ולא באחריות restic. הקפידו להדק גם את תעבורת הרשת, שכן צד ה־SSH דורש את אותה רמת זהירות כמו כל כניסה אחרת למערכת: החילו גישת SSH מבוססת מפתח בלבד עם הגבלות בתוך authorized_keys על חשבון הגיבויים.

מהירות: המשמעות של כל תכנון

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

Borg בשימוש מעל SSH הוא מהיר בקישור בעל שיהוי (latency) גבוה, כיוון שהצד של השרת הוא חכם. הלקוח שואל שאלה, תהליך ה-borg serve המרוחק עונה עליה מתוך אינדקס המאגר, והטרנזקציה מתבצעת במקום אחד. חיפושי Chunk אינם הופכים לסבבי תקשורת (round trips) ברשת עבור כל קובץ קטן.

ל-Restic בשימוש על גבי אחסון אובייקטים (object storage) אין צד שרת, לכן עליו לבנות את תמונת המצב שלו מתוך קובצי אינדקס וקובצי pack שהוא מושך דרך HTTP. כדי לשמור על מספר בקשות סביר, הוא אורז הרבה chunks קטנים לתוך קובצי pack גדולים יותר לפני ההעלאה, והוא שומר מטמון מקומי ב-~/.cache/restic כדי שההרצה הבאה לא תמשוך מחדש את כל האינדקס. מחיקת המטמון הזה תגרום לגיבוי הבא להיות איטי בזמן שהוא נבנה מחדש. בקישור בעל שיהוי גבוה עם מיליוני קבצים קטנים, זהו המקרה שבו restic ירגיש איטי יותר מ-Borg על אותם נתונים.

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

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

Borg 1.4 מבצע נעילה בלעדית על ה-repository למשך כל פעולת הגיבוי. כתיבה של שני לקוחות לאותו repository בו-זמנית אינה נתמכת: הלקוח השני ימתין, ולאחר מכן ייכשל עקב חריגת זמן של הנעילה (lock timeout). התבנית הנתמכת היא repository אחד לכל לקוח. משמעות הדבר היא שביטול כפילויות (deduplication) מתבצע רק בתוך ה-repository של מכונה בודדת, כך שעשרה שרתים כמעט זהים יאחסנו עשרה עותקים של אותה מערכת בסיס.

Restic מאפשר למספר לקוחות לגבות לאותו repository בו-זמנית, כיוון שפעולת גיבוי לוקחת נעילה משותפת, ורק פעולות תחזוקה כגון prune דורשות נעילה בלעדית. עשרה שרתים דומים המוגדרים לעבוד מול אותו repository של restic יבצעו ביטול כפילויות זה מול זה, והשרת השני ואילך יאחסן לרוב נפח נתונים קטן מאוד. המחיר הוא "רדיוס פגיעה" (blast radius): סיסמה אחת ו-repository אחד המכילים את הכל, כך שאובדן הסיסמה מוביל לאובדן הגיבויים של כל עשרת השרתים.

שימור: forget ו-prune, לעומת prune ו-compact

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

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

המלכודת בשני הכלים זהה וראוי להציג אותה בבירור. ב-Borg, הפקודה borg prune מסירה ארכיונים אך אינה מפנה מקום בדיסק בעצמה. המקום מתפנה רק כאשר borg compact רץ; לכן, משימת cron שמבצעת prune בלבד ולעולם לא מבצעת compact, תשאיר מאגר נתונים שגדל ללא הגבלה בעוד רשימת הארכיונים נשארת קצרה. ב-restic, הפקודה forget ללא --prune רק מסירה הפניות ל-snapshots, והנתונים נשארים עד להרצת prune.

הריצו את restic check לאחר ה-prune. פקודה זו מאמתת את מבנה המאגר ומדווחת אם קיים נזק, וזה עדיף בהרבה על גילוי התקלה בזמן שחזור.

שחזור, הבדיקה היחידה שקובעת

שני הכלים מאפשרים לעגן (mount) snapshot כדי שתוכל לעיין בתוכנו. זו הדרך המהירה ביותר לשלוף קובץ בודד בחזרה.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

שים לב למבנה הנתיב ב-borg extract. נתיבים בתוך ארכיון נשמרים ללא לוכסן מוביל (leading slash), לכן etc/nginx הוא הנתיב הנכון, בעוד /etc/nginx לא יתאים לכלום ולא יחלץ דבר, מבלי להציג שגיאה שתסביר מדוע. פעולת החילוץ כותבת לתוך ספריית העבודה הנוכחית, לכן עליך לעבור תחילה לספריית עבודה זמנית (scratch directory), אחרת תדרוס קבצים חיים בגרסאות ישנות.

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

איזה כלי מתאים לאיזו משימה

בחרו ב-restic כאשר יעד הגיבוי הוא object storage, כאשר אתם זקוקים לקובץ בינארי יחיד ללא צורך בהתקנת תוכנה בצד המרוחק, כאשר מספר מכונות צריכות לבצע deduplication מול מאגר משותף, או כאשר האדם שיבצע את השחזור עשוי להיות מישהו אחר. מדובר בקובץ בינארי סטטי יחיד המשתמש ב-URL עבור המאגר, וקשה להתחרות בפשטות התפעולית הזו.

בחרו ב-Borg כאשר היעד הוא שרת Linux שבשליטתכם, כאשר הקישור סובל מ-latency וערכת הנתונים כוללת מיליוני קבצים קטנים, כאשר אתם רוצים להשתמש ב-SSH key עם הרשאות append-only כהגנה מפני ransomware, או כאשר אתם זקוקים לכוונון דחיסה ספציפי לכל משימה. זהו כלי ותיק יותר, סדרת הגרסאות היציבה שלו מתקדמת לאט, ובתחום תוכנות הגיבוי מדובר ביתרון משמעותי.

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

FAQ

האם restic או BorgBackup מהירים יותר?

על דיסק מקומי או ברשת LAN מהירה הביצועים דומים, ושניהם מוגבלים בסופו של דבר על ידי מהירות הקריאה והגיבוב (hashing) במקור. Borg נוטה לנצח בחיבור SSH עם שיהוי (latency) גבוה וריבוי קבצים קטנים, כיוון שתהליך borg serve בצד המרוחק עונה על שאלות אינדקס ללא צורך בנסיעה הלוך-חזור ברשת עבור כל chunk. Restic נוטה לנצח כאשר היעד הוא אחסון אובייקטים (object storage), תחום שבו Borg אינו תומך כלל.

האם BorgBackup יכול לגבות ל-S3 או ל-Backblaze B2?

לא באופן ישיר. מאגר (repository) של Borg מנוהל על ידי תהליך borg serve מעל SSH, ותהליך כזה אינו רץ בתוך bucket. משתמשים עוקפים זאת על ידי מיפוי (mount) של אחסון אובייקטים כמערכת קבצים באמצעות rclone, פעולה שפרויקט Borg אינו ממליץ עליה, כיוון שניתוק של המיפוי באמצע טרנזקציה עלול להשחית את המאגר. אם נדרש אחסון אובייקטים, השתמשו ב-restic.

האם ניתן להריץ את שני הכלים על אותם נתונים?

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

מה קורה אם אאבד את סיסמת המאגר?

הנתונים אינם ניתנים לשחזור בשני הכלים. Restic גוזר את המפתח שלו מהסיסמה באמצעות scrypt ואין דרך לעקוף זאת. Borg במצב repokey שומר את המפתח המוצפן בתוך המאגר, כך שסיסמת הגישה לבדה מספיקה לשחזור, ובמצב keyfile נדרש גם קובץ המפתח מ-~/.config/borg/keys/. שמרו את הסיסמה במנהל סיסמאות שאינו נמצא על השרת המגובה, וייצאו את מפתח ה-Borg באמצעות borg key export אם אתם משתמשים ב-keyfile.

האם כדאי לחכות ל-Borg 2.0?

לא. נכון ליולי 2026, Borg 2.0 עדיין נמצא בגרסת בטא, בגרסה 2.0.0b22, והפרויקט מגדיר אותה כגרסת בדיקה בלבד. סדרת הגרסאות היציבה היא 1.4, נכון לעכשיו 1.4.5. התחילו עם 1.4 כעת. Borg 2 משנה את פורמט המאגר ומספק נתיב שדרוג מתועד, כך שהתחלה היום לא תשאיר אתכם ללא פתרון.