Restic чи BorgBackup: що вибрати для backup

Restic і BorgBackup: порівняння в одному абзаці

Restic і BorgBackup виконують основне завдання однаково: створюють дедупліковані, зашифровані інкрементні резервні копії Linux-сервера. Вибір визначає місце зберігання резервної копії. Restic нативно працює з S3 та іншими API об’єктного сховища, тому bucket є повноцінним призначенням, і на віддаленому боці нічого не потрібно встановлювати. Для стабільної версії Borg програму borg потрібно встановити на машині, де зберігається repository, оскільки Borg repository обслуговує процес, а не файлова система чи API. Якщо цільовим сховищем є object storage, відповідь уже очевидна. Якщо це другий Linux-комп’ютер під вашим контролем, Borg також підходить і часто працює швидше.

Усе інше має менше значення. Обидва інструменти розбивають файли на chunks із content-defined chunking, тому каталог розміром 40 GB, у якому змінилося 200 MB, передасть приблизно 200 MB. Обидва шифрують дані на клієнті. Обидва монтують snapshot через FUSE (filesystem in userspace), щоб можна було скопіювати окремий файл. Станом на October 2026 версія restic — 0.19.1, а стабільна гілка Borg — 1.4, з версією 1.4.5. Borg 2.0 уже кілька років перебуває у beta і досі позначений лише як testing, тому сьогодні слід розгортати версію 1.4.

Модель репозиторію визначає реальну різницю

Репозиторій restic — це каталог файлів: config, keys/, snapshots/, index/ і data/, заповнений pack-файлами. Щоб прочитати його, більше нічого не потрібно. Саме тому restic підтримує так багато бекендів. Будь-яке сховище, у якому можна записувати, отримувати, перелічувати й видаляти blob-об’єкти, може містити репозиторій restic. Завдяки цьому один бінарний файл підтримує локальні шляхи, SFTP, власний REST-сервер, S3, Backblaze B2, Azure, Google Cloud Storage і все, до чого може дістатися rclone.

Репозиторій Borg також складається з файлів на диску, але Borg ніколи не працює з ним через простий транспорт. Для віддаленого репозиторію Borg запускає borg serve на віддаленій стороні через SSH і використовує власний протокол для взаємодії з цим процесом. Серверна сторона виконує реальну роботу: зберігає репозиторій, застосовує транзакцію та відповідає на запити до індексу. Саме тому стабільна серія Borg 1.4 не має бекенду S3. Усередині bucket немає процесу, який можна запустити. Borg 2 змінює цю модель: він переносить сховище в новий шар під назвою borgstore, а його документація описує URL репозиторіїв sftp://, rclone:remote:path і s3: або b2:. Однак Borg 2 досі перебуває на етапі beta, і проєкт не рекомендує використовувати його в production, тому для реальних резервних копій сьогодні обмеження S3 усе ще залишається.

Цей один конструктивний факт зумовлює більшість наведених нижче практичних відмінностей.

# 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 зберігає зашифрований ключ у репозиторії, тому для відновлення достатньо passphrase. --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, fastest, better або max. Режими fastest і better з’явилися в restic 0.19.0, тому старіші бінарні файли приймають лише auto, off і max. Старе сховище формату 1 залишається нестисненим, доки ви не перенесете його до нового формату. Тому якщо ваше сховище restic старше за 0.14 і ви ніколи не виконували міграцію, текст, журнали та дампи баз даних досі займають повний початковий розмір.

Віддалені цілі: S3 проти SSH

Саме тут зазвичай роблять вибір.

Для підключення restic до S3 потрібні облікові дані в середовищі виконання, і більше ніде не потрібно запускати додаткові компоненти. Такий самий підхід працює з bucket, який ви розміщуєте самостійно. Це поширена комбінація: запустіть MinIO для S3 API на власному 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 до віддаленого repository потрібні SSH і встановлений Borg на віддаленій стороні. Версія Borg там має бути сумісною з клієнтом. Якщо віддалений сервер вам не належить, це створює додаткові труднощі. Якщо це другий сервер, яким ви вже адмініструєте, проблеми немає. Натомість ви отримуєте найкращий із доступних у цих інструментах захист від ransomware: SSH key у режимі append-only. Примусово налаштуйте key на виконання borg serve. Тоді клієнт зможе додавати archives, але не зможе їх видаляти. Якщо машину буде скомпрометовано, зловмисник не зможе стерти історію резервних копій.

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

Еквівалентний режим у restic доступний лише під час запуску власного REST server, який підтримує append-only mode. Для звичайного S3 такого самого ефекту можна досягти за допомогою bucket policy або object lock. Це налаштовує провайдер, а не restic. Також обмежте доступ до транспортного каналу. SSH-підключення потребує такого самого захисту, як і будь-який інший вхід у систему: застосуйте SSH лише за key із обмеженим записом у authorized_keys для backup account.

Швидкодія: що передбачає кожна схема

Жоден із проєктів не публікує бенчмарк, результатам якого можна довіряти для власних даних. Тому робіть висновки з принципу роботи.

Borg через SSH швидко працює в мережі з високою затримкою, оскільки серверна частина виконує інтелектуальну обробку. Клієнт надсилає запит, віддалений процес borg serve відповідає на нього за індексом репозиторію, а транзакція фіксується в одному місці. Пошук чанків не перетворюється на мережевий обмін для кожного невеликого файлу.

У restic зі сховищем об’єктів немає серверної частини, тому він формує свою картину за індексними файлами та pack-файлами, які отримує через HTTP. Щоб кількість запитів залишалася прийнятною, перед завантаженням restic об’єднує багато невеликих чанків у більші 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. Команда перевіряє структури репозиторію й повідомляє про пошкодження. Це значно краще, ніж виявити проблему під час відновлення.

Відновлення — єдиний тест, який має значення

Обидва інструменти монтують 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 не знаходить нічого й нічого не розпаковує. Жодної помилки, яка пояснила б причину, не буде. Розпакування також записує файли в поточний робочий каталог, тому спочатку перейдіть до окремого тимчасового каталогу. Інакше старі файли перезапишуть актуальні.

Відновлення, яке завершується без помилки, усе одно не є доказом успіху. Програма має власне уявлення про повне відновлення. Наприклад, сервер Immich, відновлений із копії каталогу даних Postgres, може містити всі фотографії на диску, але мати порожню часову шкалу. Саме з такою проблемою має впоратися резервне копіювання та відновлення Immich.

Незалежно від обраного інструмента, розклад — це лише половина роботи. Запускайте відновлення в окремий тимчасовий каталог за таймером, який ви справді контролюєте. Саме так це зроблено в повному посібнику із резервного копіювання VPS за допомогою restic через таймер systemd.

Який інструмент краще підходить для конкретного завдання

Обирайте restic, якщо цільовим сховищем є object storage, якщо потрібен один бінарний файл без встановлення програмного забезпечення на віддаленій стороні, якщо кілька машин мають виконувати дедуплікацію між собою або якщо відновленням займатиметься інша людина. Це один статично скомпільований бінарний файл і URL репозиторію. З операційного погляду це важко перевершити.

Обирайте Borg, якщо цільовою системою є Linux-сервер під вашим контролем, якщо канал має високу затримку, а набір даних містить мільйони малих файлів, якщо потрібен SSH-ключ із режимом append only як захист від ransomware або якщо потрібно окремо налаштовувати стиснення для кожного завдання. Це старіший інструмент. Його стабільні серії розвиваються повільно, і для програмного забезпечення резервного копіювання це перевага.

Обидва варіанти правильні. Неправильним є той варіант, який ви жодного разу не перевірили. Якщо ви вже створюєте дампи на рівні застосунку, продовжуйте це робити: підхід, описаний у налаштуванні Nextcloud у Docker із дампами бази даних, працює з обома інструментами, оскільки файл активної бази даних, скопійований у довільний момент, не є резервною копією бази даних.

FAQ

Що швидше: restic чи BorgBackup?

На локальному диску або в швидкій LAN вони працюють майже однаково. В обох випадках швидкість зрештою обмежується швидкістю читання та обчислення хешів на джерелі. Borg зазвичай швидший через SSH-з’єднання з високою затримкою та дуже великою кількістю малих файлів, оскільки процес borg serve на віддаленій стороні обробляє запити до індексу без окремого мережевого обміну для кожного фрагмента. restic зазвичай швидший, коли цільовим сховищем є object storage, з яким стабільна версія Borg взагалі не працює.

Чи може BorgBackup виконувати резервне копіювання в S3 або Backblaze B2?

Не в стабільній серії 1.4. Репозиторій Borg 1.4 обслуговує процес borg serve через SSH, а в bucket такий процес не запускається. Borg 2 додає URL репозиторіїв s3:, b2: і rclone: через свій шар borgstore, але станом на жовтень 2026 року Borg 2 усе ще має статус beta, і проєкт не рекомендує використовувати його в production. У версії 1.4 цю проблему обходять, монтувавши object storage як файлову систему за допомогою rclone. FAQ Borg не рекомендує використовувати network filesystem для зберігання репозиторіїв і попереджає, що FUSE та network filesystem можуть спричинити низьку швидкість або пошкодження даних. Якщо вам потрібне object storage для production-резервних копій уже зараз, використовуйте restic.

Чи можна запускати обидва інструменти для одних і тих самих даних?

Так, деякі користувачі саме так і роблять: Borg — на другий сервер для швидкого локального відновлення, restic — в object storage для копії за межами основного майданчика. Вони не використовують спільні дані, тому витрати на читання та обчислення хешів виникають двічі. Також потрібно безпечно зберігати два паролі. Використовуйте цю схему лише після перевірки відновлення з обох резервних копій.

Що станеться, якщо я втрачу пароль від репозиторію?

В обох інструментах дані буде неможливо відновити. restic отримує ключ із пароля за допомогою scrypt, і обійти цей механізм неможливо. У режимі Borg repokey зашифрований ключ зберігається всередині репозиторію, тому для відновлення достатньо passphrase. У режимі keyfile додатково потрібен файл ключа з ~/.config/borg/keys/. Зберігайте пароль у password manager, який не розміщений на сервері, що резервується. Якщо використовуєте keyfile, експортуйте ключ Borg за допомогою borg key export.

Чи варто чекати на Borg 2.0?

Ні. Станом на жовтень 2026 року Borg 2.0 усе ще має статус beta, версія — 2.0.0b25 (випущена 27 вересня 2026 року), а проєкт позначає її як призначену лише для тестування. Стабільна серія — 1.4, поточна версія — 1.4.5. Починайте з 1.4 уже зараз. Borg 2 змінює формат репозиторію та має документований шлях оновлення (borg transfer --from-borg1), тому початок роботи сьогодні не створить проблем під час переходу. У Borg 2 також з’явиться вбудована підтримка S3, B2 і rclone після стабілізації цієї версії.