Резервні копії Linux-сервера за допомогою restic і таймера systemd

Оновлено 4 жовтня 2026 12 хв читання Read in English

Зміст статті

Стаття для адміністратора, якому потрібно, щоб Linux-сервер щоночі сам робив зашифровані резервні копії на окреме сховище або другий сервер. У підсумку матимете репозиторій restic, політику зберігання, таймер systemd зі сповіщенням про збій і успішне пробне відновлення.

Що знадобиться#

Linux-сервер із доступом root; команди виконуйте в оболонці root (sudo -i).
Місце для копій поза цим сервером: або місце для резервних копій на окремому сховищі, що входить у сервери більшості лінійок (обсяг указано в картці сервера, у лінійці Лайт його немає; сховище монтують за NFS або CIFS, параметри підключення надішле підтримка; копіювання не автоматичне — його налаштовуєте ви), або другий сервер, доступний через SSH.
Якщо на сервері є бази даних — скрипт дампів: файли запущеної бази, скопійовані «наживо», можуть не відновитися. Як робити дампи — у статті про резервні копії баз даних.

Крок 1 Встановіть restic#

Актуальна стабільна версія на жовтень 2026 року — restic 0.19.1. Найпростіше встановити пакет дистрибутива. У Debian та Ubuntu:

apt update
apt install restic
restic version

У Fedora — dnf install restic; в AlmaLinux і Rocky Linux спершу підключіть EPEL: dnf install epel-release.

Версія в репозиторії дистрибутива може відставати: у Debian 13 це 0.18.0, в Ubuntu 24.04 — 0.16.4, в Ubuntu 26.04 — 0.18.1. Команди з цієї статті працюють і в цих версіях. Якщо потрібна найновіша, офіційний спосіб — завантажити бінарний файл зі сторінки випусків проєкту (знадобляться curl і bzip2):

cd /tmp
curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
curl -LO https://github.com/restic/restic/releases/download/v0.19.1/SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS
bunzip2 restic_0.19.1_linux_amd64.bz2
install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
hash -r
restic version

Команда sha256sum має відповісти restic_0.19.1_linux_amd64.bz2: OK; якщо ні — файл не встановлюйте. Пакет дистрибутива, якщо він був установлений, видаліть: apt remove restic. Надалі такий файл оновлює команда restic self-update; у пакетах дистрибутивів її зазвичай немає. Як перевірити ще й підпис PGP, описано в офіційній інструкції зі встановлення.

Крок 2 Пароль, сховище і репозиторій#

Репозиторій restic завжди зашифрований. Пароль зберігайте у файлі, який читає лише root:

install -d -m 700 /etc/restic
openssl rand -base64 32 > /etc/restic/password
chmod 600 /etc/restic/password

Увага. Одразу скопіюйте вміст /etc/restic/password у менеджер паролів або в інше місце поза цим сервером. Скинути чи відновити пароль неможливо: без нього копії не прочитає ніхто — ні ви, ні підтримка. Не виконуйте команду openssl повторно, коли репозиторій уже створено: вона перезапише файл пароля.

restic працює з кількома типами сховищ; від типу залежить адреса репозиторію:

Тип сховища	Адреса репозиторію (приклад)	Що ще потрібно
Локальний або змонтований каталог	`/mnt/backup/restic`	Каталог на іншому сховищі, змонтований на час копіювання
SFTP	`sftp:backup-host:/srv/backup/app01`	Вхід через SSH за ключем, без запиту пароля
REST-сервер	`rest:https://backup.example.com:8000/app01/`	Змінні `RESTIC_REST_USERNAME` і `RESTIC_REST_PASSWORD`
S3-сумісне сховище	`s3:https://s3.example.com/bucket-name`	Змінні `AWS_ACCESS_KEY_ID` і `AWS_SECRET_ACCESS_KEY`

Варіант 1. Місце для резервних копій#

Сховище не залежить від сервера: відмова дисків чи самого сервера копій не зачепить. Воно працює за NFS (лише версії 3), CIFS/SMB (лише версії 2.0), FTP і FTPS. FTP для restic не підходить, тож змонтуйте сховище за NFS чи CIFS і тримайте репозиторій у змонтованому каталозі. Ім’я хоста (HOST), ім’я сховища (NAME) і пароль надішле підтримка. Доступ відкритий лише з IP-адрес ваших серверів, які підтримка на ваш запит додає до списку доступу; з інтернету чи з офісу сховище недоступне. З однієї адреси — не більше трьох одночасних з’єднань.

Для NFS встановіть клієнт і змонтуйте сховище:

apt install nfs-common
mkdir -p /mnt/backup
mount -t nfs -o vers=3 HOST:/export/ftpbackup/NAME /mnt/backup

Щоб сховище монтувалося й після перезавантаження, додайте рядок у /etc/fstab:

HOST:/export/ftpbackup/NAME /mnt/backup nfs vers=3,_netdev,nofail 0 0

Для CIFS спершу запишіть логін і пароль у файл /etc/restic/cifs-credentials:

username=NAME
password=PASSWORD

Потім змонтуйте сховище:

apt install cifs-utils
chmod 600 /etc/restic/cifs-credentials
mkdir -p /mnt/backup
mount -t cifs -o vers=2.0,credentials=/etc/restic/cifs-credentials,uid=root,gid=root,dir_mode=0700,file_mode=0600 //HOST/NAME /mnt/backup

Рядок для /etc/fstab:

//HOST/NAME /mnt/backup cifs vers=2.0,credentials=/etc/restic/cifs-credentials,uid=root,gid=root,dir_mode=0700,file_mode=0600,_netdev,nofail 0 0

Документація restic не радить тримати репозиторій на CIFS через збої зі старішими ядрами Linux, тож за можливості обирайте NFS.

Параметр nofail не дає завантаженню зупинитися, якщо сховище недоступне. Перевірте запис у fstab: findmnt має показати сховище з параметром vers=3 або vers=2.0.

systemctl daemon-reload
umount /mnt/backup
mount /mnt/backup
findmnt /mnt/backup

Заповнене сховище переходить у режим лише читання, доки не звільниться місце, — стежте за заповненням командою df -h /mnt/backup. Режиму «лише додавання» немає: процес на сервері, який може записувати на сховище, може й стерти копії, тож на випадок шифрувальника тримайте ще одну копію поза сервером і сховищем. Щоб відновити дані на іншому сервері, попросіть підтримку відкрити доступ до сховища з його IP-адреси й змонтуйте сховище там так само.

Варіант 2. Другий сервер через SFTP#

На другому сервері (у прикладі — 203.0.113.10) створіть окремого користувача без прав sudo (тут — backupuser) і каталог для копій, який йому належить:

useradd -m -s /bin/bash backupuser
install -d -o backupuser -m 700 /srv/backup

На основному сервері створіть окремий ключ без парольної фрази — ним користуватиметься таймер:

install -d -m 700 /root/.ssh
ssh-keygen -t ed25519 -N "" -f /root/.ssh/restic_backup

Опишіть з’єднання у файлі /root/.ssh/config; два останні рядки не дають довгому сеансу обірватися:

Host backup-host
    HostName 203.0.113.10
    User backupuser
    IdentityFile /root/.ssh/restic_backup
    ServerAliveInterval 60
    ServerAliveCountMax 240

Додайте відкритий ключ /root/.ssh/restic_backup.pub у ~/.ssh/authorized_keys користувача backupuser (докладно — у статті про ключі SSH) і один раз підключіться вручну, щоб підтвердити відбиток ключа сервера: ssh backup-host true.

Файл середовища і репозиторій#

Адресу репозиторію і шлях до пароля запишіть у файл змінних середовища /etc/restic/restic.env — ним користуватиметеся і ви, і systemd. У прикладі — другий сервер. Для місця для резервних копій перший рядок — RESTIC_REPOSITORY=/mnt/backup/restic, а для CIFS документація restic радить додати ще рядок GODEBUG=asyncpreemptoff=1:

RESTIC_REPOSITORY=sftp:backup-host:/srv/backup/app01
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_CACHE_DIR=/var/cache/restic

Для REST-сервера чи S3-сумісного сховища сюди ж додають логін або ключі, тому права на файл — теж 600. Завантажте змінні в оболонку (це потрібно в кожному новому сеансі) і створіть репозиторій:

chmod 600 /etc/restic/restic.env
set -a; . /etc/restic/restic.env; set +a
restic init

Крок 3 Перша копія з винятками#

Усе, що копіювати не треба, перелічіть у файлі /etc/restic/excludes.txt — по одному шаблону на рядок:

/home/*/.cache
/root/.cache
*.tmp
*.swp

Запустіть копіювання і перегляньте перелік знімків (snapshots). Каталоги замініть на свої; серед них має бути каталог із дампами баз:

restic backup /etc /home /root /srv --exclude-file=/etc/restic/excludes.txt
restic snapshots

Крок 4 Політика зберігання: forget і prune#

Команда forget прибирає знімки, що не підпадають під політику, а prune видаляє зі сховища дані, на які вже ніщо не посилається; без prune місце не звільниться. Спершу подивіться, що буде видалено, потім виконайте:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Така політика залишає по одному знімку за кожен із семи останніх днів, чотирьох тижнів і шести місяців, у які були копії. Вона діє окремо для кожного набору шляхів: якщо змінити перелік каталогів у backup, старі знімки утворять окрему групу. Скільки копій тримати і де — у статті про правило 3-2-1.

Крок 5 Автоматичний запуск: служба і таймер systemd#

Увесь цикл виконує скрипт /usr/local/sbin/restic-backup.sh. Перед restic backup поставте виклик свого скрипта дампів, а для місця для резервних копій розкоментуйте перевірку монтування:

#!/bin/sh
set -eu

# Місце для резервних копій: зупинитися, якщо сховище не змонтовано
# mountpoint -q /mnt/backup

# Дампи баз у каталог, що входить у копію
# /usr/local/sbin/db-dump.sh

restic backup /etc /home /root /srv --exclude-file=/etc/restic/excludes.txt
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

Завдяки set -e скрипт зупиняється на першій помилці й повертає код завершення restic: 1 — копію не створено; 3 — знімок створено, але частину файлів не прочитано; 11 — репозиторій заблоковано (якщо інший процес restic не працює, зніміть застаріле блокування командою restic unlock); 12 — неправильний пароль. Коди 11 і 12 з’явилися в restic 0.17.

Служба /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
Wants=network-online.target
After=network-online.target
OnFailure=restic-backup-failed.service

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/local/sbin/restic-backup.sh

Таймер /etc/systemd/system/restic-backup.timer запускає її щоночі за часом сервера; Persistent=true надолужує запуск, пропущений, поки сервер був вимкнений:

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

Службу сповіщення /etc/systemd/system/restic-backup-failed.service запускає OnFailure, коли скрипт завершується з помилкою. У прикладі вона надсилає листом останні рядки журналу — для цього має бути налаштована команда mail; для месенджера чи системи моніторингу підставте свій виклик:

[Unit]
Description=Notify about a failed restic backup

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'journalctl -u restic-backup.service -n 50 --no-pager | mail -s "restic backup FAILED on %H" admin@example.com'

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

chmod 700 /usr/local/sbin/restic-backup.sh
systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl start restic-backup.service

Як перевірити результат#

Таймер і журнал: у списку є час наступного запуску, в журналі немає помилок, серед знімків є свіжий.
```
systemctl list-timers restic-backup.timer
journalctl -u restic-backup.service -n 30 --no-pager
restic snapshots
```
Цілісність репозиторію. restic check перевіряє структуру, але самих даних не читає. Параметр --read-data-subset=5% у скрипті щоразу читає випадкові 5 % збережених даних; значення 1/7 читає першу із семи частин — за сім запусків із різними номерами буде перечитано все.
```
restic check
restic check --read-data-subset=1/7
```
Пробне відновлення в окремий каталог, не поверх робочих даних. Параметр --verify звіряє відновлені файли з репозиторієм; diff має показати хіба що файли, які змінилися після копіювання.
```
restic restore latest --target /var/tmp/restore-test --include /etc --verify
diff -r --no-dereference /etc /var/tmp/restore-test/etc
rm -rf /var/tmp/restore-test
```

Так само відновіть дамп бази в тестову базу. Найчесніша перевірка — відновити дані на іншій машині, маючи лише адресу репозиторію і пароль із менеджера паролів; повторюйте її щокварталу.

BorgBackup як альтернатива#

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

Актуальна стабільна гілка на жовтень 2026 року — 1.4 (випуск 1.4.5); гілка 2.0 ще має статус бета-версії і для робочих копій не призначена. Встановіть пакет borgbackup на обох серверах: apt install borgbackup або dnf install borgbackup (в AlmaLinux і Rocky Linux — з EPEL). Мінімальний приклад із тим самим з’єднанням backup-host:

export BORG_REPO=ssh://backup-host/srv/backup/app01-borg
borg init --encryption=repokey
borg create --stats ::'{hostname}-{now}' /etc /home /root /srv
borg prune --glob-archives '{hostname}-*' --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact
borg key export :: /root/borg-key.txt

borg init запитає парольну фразу; для запуску за таймером її передають через змінну BORG_PASSCOMMAND. Експортований ключ і парольну фразу збережіть поза сервером. Докладніше — в офіційній документації Borg.

Типові помилки#

Пароль репозиторію зберігається лише на сервері. Втрачений пароль — це втрачені копії: разом із сервером зникне єдиний ключ до них.
Копія на тому самому диску чи сервері. Вона не врятує від відмови диска, помилки адміністратора чи зламу. Якщо репозиторій у змонтованому каталозі, перевіряйте в скрипті, що його змонтовано (mountpoint -q /mnt/backup), інакше копія ляже на системний диск.
Відновлення жодного разу не перевіряли. Копія, з якої ніхто не відновлював дані, — лише припущення.
Збої ніхто не бачить. Якщо сервер вимкнено, OnFailure не спрацює — регулярно перевіряйте дату останнього знімка.

Що далі#

Другий сервер для копій може стояти в іншій країні й бути з’єднаний з основним приватною мережею; наступний крок — резервний майданчик.
Сервери з місцем для резервних копій і приватною мережею — в каталозі; підтримка: +38 044 206 08 08, info@united.net.ua.