Як налаштувати Restic для бекапу VPS

Чому резервна копія на тому ж сервері не є резервною копією

Restic — це безкоштовний інструмент з відкритим кодом для створення резервних копій. Він надсилає зашифровані згортки (snapshots) ваших файлів з дедуплікацією у віддалений репозиторій: на другий VPS, домашній комп'ютер або S3-сумісне сховище об'єктів. Цей посібник містить інструкції з налаштування на Ubuntu 24.04: від встановлення до створення репозиторію через SFTP, виконання першої резервної копії, налаштування щоденного таймера systemd, політики зберігання даних та перевірки відновлення для підтвердження працездатності системи. Місце призначення має бути іншою машиною, оскільки копія на тому ж сервері зникне разом із сервером.

backup/ каталог на сервері, який створюється для резервного копіювання, захищає лише від одного: випадкового видалення файлу. Він не допоможе при виході з ладу диска, оскільки дані зберігаються на цьому ж диску. Він не допоможе при атаці з правами root, оскільки зловмисники спочатку видаляють копії. Він не допоможе при помилці в обліковому записі, через яку буде видалено сам VPS. Найменш ефективний дата-центр у світі жартує про архів tar під назвою backup_final_v2_REAL, що лежить на тому ж масиві, що й дані; цей жарт актуальний, бо багато хто з нас робив саме так. Правило вимагає зберігати копії на іншому пристрої, і restic — найпростіший спосіб дотримуватися цього правила.

Restic у чотирьох поняттях

Repository. Місце, куди restic записує дані. Це директорія у власному форматі restic, що містить зашифровані blobs; читати її може лише restic. Не редагуйте її вручну; взаємодійте з нею через команди restic та адресу -r.

Snapshot. Знімок стану файлів на певний момент часу. Кожен запуск резервного копіювання створює snapshot; кожен snapshot можна відновити окремо, і кожен з них працює як повна копія ваших даних на той момент.

Deduplication. Restic розбиває файли на чанки, визначені за вмістом, і завантажує лише ті чанки, які ще не були у репозиторії. Перше резервне копіювання завантажує все; кожен наступний запуск завантажує лише те, що змінилося. Нічний snapshot об'ємом 20 GB зі зміною 50 MB коштуватиме приблизно 50 MB, тому зберігання десятків snapshot не потребує багато ресурсів.

Encryption by default. Репозиторій restic завжди зашифрований (AES-256), тому для кожної команди потрібен пароль до репозиторію. Хост резервного копіювання або провайдер сховища бачать лише зашифровані blobs. Наслідок: якщо ви втратите пароль, дані будуть втрачені назавжди, так задумано архітектурою. Зберігайте копію пароля в місці, відмінному від цього сервера. Це настільки важливо, що далі це згадується ще двічі.

Встановлення restic на Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

В Ubuntu 24.04 встановлюється restic 0.16.4, тоді як поточна версія upstream — 0.19.1. Різниця виникає через те, що LTS (long term support) релізи фіксують версії пакетів. Це не критично: версія 0.16.4 виконує всі дії, описані в цьому посібнику. Якщо вам потрібна найновіша версія для покращення швидкості, завантажте офіційний single-binary збірка зі сторінки restic project GitHub releases, розпакуйте її за допомогою bunzip2 та встановіть у /usr/local/bin/restic; встановлення restic не потребує нічого іншого.

Створення репозиторію на іншому сервері через SFTP

Вам потрібен цільовий вузол: зазвичай це другий невеликий VPS, але підійде будь-який сервер з SSH-сервером та вільним дисковим простором. Restic підтримує SFTP (передача файлів через SSH), тому на хості резервного копіювання не потрібно нічого встановлювати. У цьому посібнику хостом резервного копіювання є 10.0.0.12 з користувачем restic. Не використовуйте ім'я backup для цього користувача: у кожній інсталяції Ubuntu та Debian є зарезервований системний обліковий запис backup (uid 34, без shell для входу), тому adduser backup завершиться помилкою, а ssh backup@... потрапить у nologin.

Щоденне завдання виконуватиметься від імені root на сервері, що резервується, тому root повинен мати можливість входу за ключем на хост резервного копіювання. Створіть окремий ключ без пароля, оскільки о 3 годині ночі ніхто не зможе ввести пароль вручну, і скопіюйте його:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Якщо ви вперше працюєте з ключами, основи керування SSH-ключами пояснює принципи роботи, права доступу та спосіб відкликання ключа в майбутньому.

Далі — пароль репозиторію. Згенеруйте надійний пароль у файл, доступний лише для root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Збережіть цей пароль у менеджер паролів, перш ніж продовжувати. Якщо цей VPS вийде з ладу, репозиторій разом із цим паролем дозволить відновити всі дані; без пароля репозиторій не зможе нічого відновити.

Ініціалізуйте репозиторій:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Альтернативним цільовим вузлом є S3-сумісне об'єктне сховище. Це правильний вибір, якщо ви не хочете запускати другий сервер. Будь-який S3-сумісний bucket працює однаково; змінюються лише адреса та дві змінні облікових даних:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Все, що йде після init, єдентично для обох цільових вузлів. У решті цього посібника вказано адресу SFTP; підставте свою.

Перший резервний копіювання з виключеннями

Резервуйте дані, які неможливо відновити перевстановленням, а не всю файлову систему. Операційну систему можна повернути через перевстановлення; ваші конфігурації та дані — ні. Для типового VPS це означає /etc, /home, а також місця зберігання стану ваших додатків, такі як /srv або /var/www. Виключайте кеші, оскільки вони мають великий обсяг, постійно змінюються і самовідновлюються:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

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

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Кожен знімок (snapshot) містить ID, час та шляхи до файлів. Використовуйте ці ID для відновлення.

Нічні запуски за допомогою systemd timer

Постійне введення адреси репозиторію в кожній команді є неефективним, а резервне копіювання, яке запускається вручну, зазвичай перестають робити протягом місяця. Обидві проблеми вирішуються за допомогою одного скрипта та одного таймера. Скрипт встановлює дві змінні середовища, які зчитує restic, RESTIC_REPOSITORY та RESTIC_PASSWORD_FILE, тому всі команди всередині скрипта залишаються короткими:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Рядки forget та check пояснено у наступних двох розділах. Тепер розклад: служба oneshot, яка запускає скрипт, та таймер, який активує її о 03:00 щоночі. Використання таймера краще за cron, оскільки логи запуску зберігаються в journal, а Persistent=true запускає пропущений бекап одразу після відновлення роботи сервера після простою.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Увімкніть таймер, потім запустіть службу один раз вручну, щоб перевірити її роботу:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers показує час наступного запуску. Ви також можете згенерувати пару юніт-файлів замість їхнього ручного створення:

Повний опис структури цих двох файлів, включаючи синтаксис календаря та директиви для посилення захисту (hardening), наведено у running a program as a systemd service on a VPS.

Резервна копія — це лише чутка, поки ви не виконали відновлення

Ставте це твердження як догму. Успішне виконання завдання резервного копіювання щоночі підтверджує лише факт запуску процесу; воно не гарантує можливість відновлення даних. Щоб усунути цей ризик, потрібно виконати дві перевірки.

По-перше, restic check, яку скрипт уже запускає щоночі. Ця перевірка верифікує структуру репозиторію та індекс. Це дозволяє виявити приховану пошкодження даних на хості резервного копіювання наступної ночі, а не під час спроби відновлення. Раз на місяць запускайте розширену версію, яка завантажує та перевіряє криптографічно випадкову десяту частину фактичних даних:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

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

По-друге, перевірка відновлення. Перебуваючи в кореневій оболонці (root shell) з попереднього кроку, відновіть одну реальну директорію з останнього знімка (snapshot) у тимчасову локацію та порівняйте її з робочими файлами:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Якщо diff нічого не виводить, це означає, що всі байти збігаються. Це єдине вагоме підтвердження успіху. Після завершення видаліть /srv/restore-drill. Виконуйте цю перевірку щомісяця, а раз на рік або два проводьте повну версію: відновлюйте весь останній snapshot на тимчасовий VPS і перевіряйте, чи запускається на ньому ваш додаток. Коли виникне критична ситуація, цей процес має бути для вас звичною рутиною.

Retention: forget та prune

Без політики знімки накопичуються нескінченно, і розмір репозиторію постійно зростає. Рядок forget скрипта застосовує політику щоночі: --keep-daily 7 зберігає по одному знімку за кожен день протягом останніх семи днів, --keep-weekly 4 — по одному за тиждень протягом чотирьох тижнів, а --keep-monthly 6 — по одному за місяць протягом шести місяців. Усе, що не охоплено правилом, видаляється.

Команда forget сама по собі лише видаляє записи про знімки; блоки даних залишаються в репозиторії, доки їх не видалить інша команда. Саме це робить --prune: вона знаходить блоки, на які більше не посилаються жодні знімки, і видаляє їх, що фактично звільняє місце на диску. Prune виконує реальну роботу з очищення репозиторію, тому на великих репозиторіях деякі користувачі запускають forget щоночі, а --prune — раз на тиждень; для типових розмірів VPS достатньо щоденного запуску.

Databases: спочатку зробіть дамп, потім створюйте резервну копію дампу

Restic копіює файли під час читання, тоді як база даних постійно записує дані у свої файли. Файл живої бази даних, скопійований під час запису, відновиться як пошкоджений, оскільки копія міститиме сторінки, створені до та після запису. Стандартне рішення: змусити механізм бази даних створити консистентний експорт у файл, а потім дозволити restic зробити резервну копію цього файлу.

Для PostgreSQL додайте команду дампа на початку restic-backup.sh, перед командою restic backup, і включіть директорію дампу до шляхів резервного копіювання:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump виконує ту саму роль для MariaDB та MySQL. Для прикладу використання всієї схеми розділ про резервне копіювання Nextcloud вмикає режим обслуговування, робить дамп Postgres і копіює файли як єдиний консистентний набір — саме той набір, який restic має щоночі вивозити з сервера. Для SQLite використовується схожий підхід, але простіший: посібник з Vaultwarden зупиняє контейнер на кілька секунд, щоб зробити холодну копію db.sqlite3, і саме цей архів restic відправляє на сервер.

FAQ

Чи є бекапи restic зашифрованими?

Так, завжди. Кожен репозиторій restic зашифрований за допомогою AES-256. Нешифрованого режиму не існує, а кожна команда потребує пароль репозиторію. Машина або провайдер, де зберігається репозиторій, містить лише зашифровані blobs, тому злом хоста з бекапами не призведе до витоку ваших файлів. Це безкомпромісний принцип: без пароля дані не зможе відновити ніхто, тому зберігайте його копію окремо від сервера.

Чи підтримує restic інкрементальні бекапи?

Кожен snapshot у restic працює як повний бекап, але споживає лише інкрементальний обсяг сховища. Restic розбиває файли на chunks і завантажує лише ті chunks, яких ще немає в репозиторії. Таким чином, нічний запуск передає лише те, що змінилося за день. На відміну від традиційних інкрементальних схем, тут немає ланцюжка для відтворення: будь-який snapshot відновлюється напряму, а видалення старого snapshot ніколи не пошкоджує новіші.

Як відновити файли з бекапу restic?

Виконайте restic snapshots, щоб знайти ID snapshot, потім restic restore <id> --target /some/empty/dir для його відновлення, додавши --include /path для відновлення лише частини даних. latest можна використовувати замість ID. Restic відтворює оригінальну структуру директорій у цільовій папці, тому відновлення /etc/ssh призведе до появи файлів у /some/empty/dir/etc/ssh. Відпрацюйте цей процес заздалегідь, оскільки неперевірений бекап — це лише чутки.

Як часто потрібно запускати restic backup?

Для сервера мінімально прийнятним варіантом є щонічний запуск. Завдяки дедуплікації це невелике навантаження: кожен запуск завантажує лише ті chunks, що змінилися з останнього разу. Дані, які швидко змінюються або втрата яких критична навіть за один день, можна синхронізувати кожні кілька годин за тим самим принципом. Частота — це легка частина; також регулярно запускайте restic check та раз на місяць проводьте перевірку відновлення, оскільки розклад без верифікації не дає гарантій.

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

Бекапи неможливо буде відновити. Шифрування restic не має "back door" або можливості скидання, тому пароль так само важливий, як і самі бекапи. Зберігайте копію у вашому password manager або в іншому надійному місці, відмінному від сервера з бекапами. Поки у вас є доступ, ви можете використати restic key add, щоб зареєструвати другий пароль для того самого репозиторію як резервний.