Restic או BorgBackup: במה לבחור לגיבוי לינוקס?

Restic לעומת BorgBackup, בפסקה אחת

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

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

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

מאגר של restic הוא ספרייה של קבצים: config, keys/, snapshots/, index/ ו-data/, המכילים קובצי pack. אין צורך בשום דבר נוסף כדי לקרוא אותו. לכן restic יכול לעבוד עם מגוון רחב של תשתיות אחסון. כל אחסון שיכול להעלות, להוריד, להציג ולמחוק אובייקטים בינאריים יכול להכיל מאגר של restic. כך קובץ בינארי אחד תומך בנתיבים מקומיים, ב-SFTP, בשרת REST עצמאי של restic, ב-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 מפעילה היוריסטיקה עבור כל מקטע, כדי שנתונים שכבר דחוסים לא יידחסו פעם נוספת.

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 עבור API של 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 מוגבלת על חשבון הגיבוי.

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

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

Borg over SSH מהיר בחיבור בעל השהיה, משום שהשרת כולל מנגנון חכם. הלקוח שולח שאלה, תהליך borg serve המרוחק משיב עליה מתוך אינדקס המאגר, והעסקה מתבצעת במקום אחד. חיפושי מקטעים אינם הופכים לנסיעות הלוך ושוב ברשת עבור כל קובץ קטן.

ל־restic באחסון אובייקטים אין צד שרת, ולכן הוא חייב לבנות את תמונת המצב שלו מקובצי אינדקס ומקובצי pack שהוא מוריד באמצעות HTTP. כדי לשמור על מספר סביר של בקשות, הוא אורז מקטעים קטנים רבים בתוך קובצי pack גדולים יותר לפני ההעלאה. בנוסף, הוא שומר מטמון מקומי ב־~/.cache/restic, כדי שבהרצה הבאה לא יהיה צורך להוריד מחדש את האינדקס כולו. אם מוחקים את המטמון, הגיבוי הבא איטי בזמן שהוא נבנה מחדש. בחיבור בעל השהיה גבוהה, עם מיליוני קבצים קטנים, זהו המצב שבו restic מרגיש איטי יותר מ־Borg עבור אותם נתונים.

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

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

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

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

שמירת נתונים: 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 מסירה רק הפניות ל-snapshot, והנתונים נשארים עד להפעלת prune.

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

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

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

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

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

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

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

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

FAQ

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

בדיסק מקומי או ברשת LAN מהירה, ההבדלים ביניהם קטנים. בשני הכלים המהירות מוגבלת בסופו של דבר למהירות הקריאה ולמהירות חישוב ה-hash במקור. Borg נוטה להיות מהיר יותר בחיבור SSH בעל שיהוי גבוה, כאשר יש מספר גדול מאוד של קבצים קטנים, משום שתהליך borg serve בצד המרוחק משיב לשאילתות על האינדקס בלי הלוך ושוב ברשת עבור כל מקטע. restic נוטה להיות מהיר יותר כאשר היעד הוא אחסון אובייקטים, שאליו Borg אינו יכול להתחבר כלל.

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

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

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

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

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

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

האם כדאי להמתין ל-Borg 2.0?

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