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

Restic і BorgBackup в одному абзаці

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

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

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

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

Еквівалентна можливість у restic є лише під час запуску власного REST-сервера, який підтримує режим лише додавання. Для звичайного S3 такого самого результату можна досягти за допомогою політики bucket або блокування об’єктів. Це налаштовує провайдер, а не restic. Також обмежте транспорт, оскільки SSH потрібно захищати так само ретельно, як і будь-який інший спосіб входу: застосуйте SSH лише за ключем з обмеженим записом authorized_keys для облікового запису резервного копіювання.

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

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

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

У restic зі сховищем об’єктів немає серверної частини, тому програмі потрібно формувати структуру даних з індексних файлів і pack-файлів, які вона отримує через HTTP. Щоб кількість запитів залишалася прийнятною, перед завантаженням програма об’єднує багато невеликих блоків у більші pack-файли та зберігає локальний кеш у ~/.cache/restic, щоб під час наступного запуску не завантажувати весь індекс повторно. Якщо видалити цей кеш, наступне резервне копіювання буде повільним, оскільки кеш буде створено заново. У мережі з високою затримкою та мільйонами невеликих файлів саме в цьому випадку restic працює повільніше за Borg з тими самими даними.

На локальному диску або у швидкій локальній мережі різниця здебільшого зникає, і швидкодія обох інструментів обмежується швидкістю читання та обчислення хешів для вихідних даних.

Блокування та резервне копіювання кількох машин

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

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

Що краще підходить для кожного завдання

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

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

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

FAQ

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

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

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

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

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

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

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

Дані в обох інструментах неможливо буде відновити. restic отримує ключ із пароля за допомогою scrypt, і обхідного способу немає. У режимі repokey Borg зберігає зашифрований ключ у репозиторії, тому для відновлення достатньо парольної фрази. У режимі keyfile додатково потрібен файл ключа з ~/.config/borg/keys/. Зберігайте пароль у менеджері паролів, який не розміщено на сервері, для якого створюються резервні копії. Якщо ви використовуєте 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 змінює формат репозиторію та має задокументований шлях оновлення, тому початок роботи сьогодні не створить проблем під час переходу.