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

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

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

Усе інше має менше значення. Обидва інструменти розбивають файли на частини за вмістом, тому для каталогу розміром 40 GB, у якому змінилося 200 MB, буде передано приблизно 200 MB. Обидва шифрують дані на клієнті. Обидва монтують snapshot за допомогою FUSE (filesystem in userspace), щоб можна було скопіювати окремий файл. Станом на July 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 підтримує так багато бекендів. Будь-яке сховище, яке може записувати, отримувати, перелічувати та видаляти 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 зберігає зашифрований ключ у репозиторії, тому для відновлення достатньо 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 або 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?

Безпосередньо — ні. Репозиторій Borg обслуговує процес borg serve через SSH, а в bucket такий процес не запускається. Обхідним рішенням є монтування object storage як файлової системи за допомогою rclone. Проєкт Borg не рекомендує цей підхід, оскільки монтування, яке переривається посеред транзакції, може пошкодити репозиторій. Якщо вам потрібне object storage, використовуйте restic.

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

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

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

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

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

Ні. Станом на July 2026 Borg 2.0 все ще має статус beta, версія — 2.0.0b22, і проєкт позначає її лише для тестування. Стабільна серія — 1.4, поточна версія — 1.4.5. Почніть із 1.4 вже зараз. Borg 2 змінює формат репозиторію та має задокументований шлях оновлення, тому початок роботи сьогодні не створить проблем під час переходу.