Restic או BorgBackup: איך לבחור כלי גיבוי לשרת?

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

‏Restic ו־BorgBackup מבצעים שניהם את אותה משימה בסיסית: גיבויים מצטברים, מוצפנים ובעלי דה-דופליקציה (deduplication) של שרת Linux. ההבדל המכריע בבחירה ביניהם הוא יעד הגיבוי. ‏Restic תומך באופן טבעי ב־S3 וב־API של אחסון אובייקטים אחרים, כך ש־bucket הוא יעד מדרגה ראשונה שאינו דורש התקנת תוכנה בצד המרוחק. ‏Borg דורש שהתוכנה borg תהיה מותקנת על המכונה המאחסנת את ה-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 מסוגל לעבוד עם מגוון כה רחב של תשתיות אחסון. כל שירות אחסון המסוגל לבצע פעולות put, get, list ו-delete ל-blobs יכול להכיל מאגר restic. כך קובץ בינארי יחיד תומך בנתיבים מקומיים, SFTP, שרת REST עצמאי, S3, Backblaze B2, Azure, Google Cloud Storage, וכל יעד ש-rclone מסוגל להגיע אליו.

מאגר Borg הוא גם אוסף קבצים על הדיסק, אך Borg לעולם אינו ניגש אליו דרך פרוטוקול העברת נתונים פשוט. עבור מאגר מרוחק, Borg מפעיל את borg serve בצד המרוחק באמצעות SSH ומנהל מולו פרוטוקול תקשורת ייעודי. צד השרת מבצע עבודה ממשית: הוא מחזיק את המאגר, מחיל את הטרנזקציה ומשיב לשאילתות אינדקס. זו הסיבה של-Borg אין תמיכה ב-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 הופך את ההצפנה לבחירה בעת יצירת המאגר, וזו בחירה קבועה. borg init --encryption=repokey שומר את המפתח המוצפן בתוך המאגר, כך שניתן לבצע שחזור באמצעות סיסמת הגישה בלבד. --encryption=keyfile שומר את המפתח בצד הלקוח בתוך ~/.config/borg/keys/, כך שגם אם מישהו גונב את המאגר כולו, אין בידיו דבר; עם זאת, עליכם לגבות את קובץ המפתח בנפרד, אחרת הארכיונים לא יהיו קריאים. לכל מצב קיימת גרסת -blake2 המבצעת אימות באמצעות BLAKE2b במקום HMAC-SHA256, מה שמהיר יותר בחומרה ללא האצה ייעודית ל-SHA. קיימת גם אפשרות --encryption=none, והיא מהווה בחירה לגיטימית כאשר המאגר מאוחסן על גבי דיסק מוצפן שבבעלותכם.

הכלל המעשי: השתמשו ב-repokey-blake2 עבור גיבוי שרת רגיל, ב-keyfile כאשר המאגר נמצא במיקום שאינכם סומכים עליו לחלוטין, ולעולם אל תשתמשו ב-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 ישן נשאר ללא דחיסה עד שתבצעו לו הגירה (migration). לכן, אם מאגר ה-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 בו-זמנית, כיוון שפעולת גיבוי לוקחת נעילה משותפת (shared lock), ורק פעולות תחזוקה כגון prune דורשות נעילה בלעדית. עשרה שרתים דומים המופנים לאותו ה-repository של restic מבצעים ביטול כפילויות זה מול זה, כך שהשרת השני ואילך מאחסנים לרוב נפח נתונים קטן מאוד. המחיר הוא "רדיוס פגיעה": סיסמה אחת ו-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 לא יתאים לכלום ולא יחלץ דבר, מבלי להציג שגיאה שתסביר מדוע. פעולת החילוץ כותבת לקובץ בספריית העבודה הנוכחית, לכן עברו לספריית עבודה זמנית לפני כן, אחרת תדרסו קבצים פעילים עם גרסאות ישנות.

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

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

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

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

בחרו ב-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 משנה את פורמט המאגר ומספק נתיב שדרוג מתועד, כך שהתחלה היום לא תשאיר אתכם ללא אפשרות שדרוג.