Удалённые резервные копии на VPS: restic или Borg, шифрование и проверка восстановления

Резервная копия на том же сервере, где находятся рабочие данные, помогает не во всех случаях. Если выйдет из строя диск, сервер окажется скомпрометирован или администратор случайно удалит каталог, вместе с исходными файлами можно потерять и копии.

Более надёжная схема — передавать данные на отдельный VPS. Основной сервер самостоятельно устанавливает исходящее SSH-соединение, шифрует данные и сохраняет их в удалённом репозитории. Открывать дополнительный доступ к основному серверу при этом не требуется.

Для такой схемы подходят restic и BorgBackup. Оба инструмента поддерживают шифрование, дедупликацию и хранение нескольких состояний данных. Однако они отличаются требованиями к удалённому серверу и способом работы с репозиторием.

В этой статье настроим оба варианта, введём политику хранения копий и проведём тестовое восстановление. Все значения BACKUP_IP, пути и имена серверов в командах нужно заменить на параметры своей инфраструктуры.

Как устроено удалённое резервное копирование на VPS

Базовая схема выглядит так:

Основной сервер
│
├── файлы и конфигурации
├── подготовленные дампы баз данных
└── данные приложений
        │
        │ SSH/SFTP
        ▼
Отдельный Linux VPS
│
└── зашифрованный репозиторий
        │
        ├── ежедневные копии
        ├── еженедельные копии
        └── ежемесячные копии

Удалённый VPS становится одной из копий, но не заменяет всю стратегию резервирования. Практический ориентир — правило 3-2-1:

• хранить не менее трёх экземпляров данных;
• использовать два разных типа или места хранения;
• держать хотя бы одну копию отдельно от основной инфраструктуры.

Например, рабочие данные могут находиться на основном сервере, локальная оперативная копия — на отдельном диске или в другом хранилище, а удалённая — на VPS.

Что следует копировать

В репозиторий обычно включают:

• конфигурационные файлы из /etc;
• пользовательские данные;
• каталоги сайтов и приложений;
• подготовленные дампы баз данных;
• данные Docker volumes после согласованной остановки приложения или создания корректного снапшота;
• скрипты развёртывания и инфраструктурные конфигурации;
• документы, ключи и сертификаты, необходимые для восстановления сервиса.

Кэши, временные файлы, журналы без эксплуатационной ценности и содержимое виртуальных файловых систем обычно исключают.

До настройки задания полезно составить короткий перечень: что именно восстанавливаем, в каком порядке и до какого состояния. Иначе копирование может завершаться успешно, но критичного каталога в репозитории не окажется.

Restic или Borg: что выбрать

Restic и Borg решают похожую задачу, но используют разную модель удалённого хранения.

Restic удобнее, если на VPS планируется использовать обычный SFTP и не хочется устанавливать отдельную серверную часть. Он также подходит, если в будущем репозиторий может быть перенесён в S3-совместимое хранилище.

Borg удобнее, если оба Linux-сервера находятся под полным контролем администратора. На удалённом VPS устанавливается Borg, а SSH-ключ можно ограничить режимом borg serve и конкретным каталогом.

Не следует одновременно использовать restic и Borg для одного репозитория. Их форматы несовместимы. Для начала выберите один инструмент, проверьте полный цикл резервирования и только затем автоматизируйте процесс.

Как подготовить VPS для хранения копий

Команды ниже рассчитаны на Ubuntu или Debian. На других дистрибутивах будут отличаться имена пакетов и используемый пакетный менеджер.

Создайте отдельного пользователя

На VPS не нужно выполнять резервное копирование через root. Создайте отдельную учётную запись:

sudo adduser --disabled-password --gecos "" backup

Затем подготовьте каталог для выбранного инструмента. Для restic:

sudo install -d -o backup -g backup -m 700 /srv/backup/restic

Для Borg:

sudo install -d -o backup -g backup -m 700 /srv/backup/borg

Если на VPS будет храниться только один репозиторий, достаточно создать каталог для выбранной системы.

Настройте SSH-ключ

На основном сервере сначала убедитесь, что файл с таким именем ещё не существует:

sudo test -e /root/.ssh/id_ed25519_backup && echo "Ключ уже существует"

Если команда не вывела сообщение, создайте отдельный ключ:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519_backup -C "offsite-backup"

Для полностью автоматического запуска ключ должен быть доступен службе без интерактивного ввода. Если он создаётся без парольной фразы, безопасность будет зависеть от прав на файл и защиты основного сервера. Не используйте этот ключ для обычного администрирования.

На VPS создайте каталог для ключей пользователя backup:

sudo install -d -o backup -g backup -m 700 /home/backup/.ssh
sudo test -e /home/backup/.ssh/authorized_keys || sudo install -o backup -g backup -m 600 /dev/null /home/backup/.ssh/authorized_keys

Откройте authorized_keys через sudoedit и добавьте публичную часть ключа из файла /root/.ssh/id_ed25519_backup.pub основного сервера.

После этого проверьте соединение с основного сервера:

sudo ssh -i /root/.ssh/id_ed25519_backup backup@BACKUP_IP

При первом подключении внимательно сверьте отпечаток ключа VPS. Не подтверждайте неизвестный отпечаток автоматически.

Для удобства можно создать на основном сервере запись в /root/.ssh/config:

Host ipway-backup
    HostName BACKUP_IP
    User backup
    IdentityFile /root/.ssh/id_ed25519_backup
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 240

У файла должны быть ограниченные права:

sudo chmod 600 /root/.ssh/config

После настройки соединение проверяется короткой командой:

sudo ssh ipway-backup

Ограничьте сетевой доступ

SSH-порт VPS желательно разрешить только с публичного IP основного сервера или административной сети. Ограничение можно задать во внешнем firewall провайдера либо в используемой на VPS системе фильтрации.

Не применяйте новое правило firewall, пока не проверили:

1. С какого адреса основной сервер выходит в интернет.
2. Есть ли отдельный административный канал.
3. Сохранится ли текущая SSH-сессия.
4. Как восстановить доступ через консоль провайдера.

Рассчитайте объём диска

Для предварительной оценки нужны:

• объём первого полного набора данных;
• средний дневной объём изменений;
• период хранения;
• запас на рост;
• временное место для обслуживания репозитория.

Дедупликация и сжатие уменьшают расход диска, но коэффициент зависит от данных. Архивы, видео и уже сжатые образы почти не сжимаются. Точный результат лучше оценить по первой копии и нескольким дням реальных изменений.

Как настроить резервное копирование

Перед установкой проверьте версии пакетов в репозитории дистрибутива. Примеры команд в статье рассчитаны на restic 0.19.x и BorgBackup 1.4.x. Для другой основной версии сначала сравните синтаксис через restic help или borg help.

Вариант с restic

Установите restic на основном сервере:

sudo apt update
sudo apt install restic
restic version

На VPS устанавливать restic не требуется: в этом сценарии используется SFTP.

Создайте локальный файл для пароля репозитория:

sudo install -d -m 700 /root/.config/restic
sudo test -e /root/.config/restic/repository-password || sudo install -m 600 /dev/null /root/.config/restic/repository-password
sudoedit /root/.config/restic/repository-password

Запишите в файл длинный уникальный пароль одной строкой. Не храните его в скрипте, истории команд или общедоступном менеджере конфигураций.

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

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password init

Команду init выполняют только один раз для нового пустого репозитория. Не запускайте её повторно поверх существующего репозитория.

Создайте файл исключений /etc/restic-excludes.txt:

/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/home/*/.cache

Запустите первую копию:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password backup /etc /home /srv/app-data --exclude-file /etc/restic-excludes.txt --host server01

Замените /srv/app-data фактическим каталогом приложения, а server01 — постоянным именем исходного сервера.

После завершения проверьте список снимков:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password snapshots

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

Вариант с Borg

Borg должен быть установлен как на основном сервере, так и на VPS:

sudo apt update
sudo apt install borgbackup
borg --version

На VPS выполните такую же установку и сравните версии. Не смешивайте несовместимые основные версии Borg.

На основном сервере подготовьте файл с парольной фразой:

sudo install -d -m 700 /root/.config/borg
sudo test -e /root/.config/borg/passphrase || sudo install -m 600 /dev/null /root/.config/borg/passphrase
sudoedit /root/.config/borg/passphrase

Перед работой задайте параметры текущего сеанса:

sudo -i
export BORG_REPO="ipway-backup:/srv/backup/borg"
export BORG_PASSCOMMAND="cat /root/.config/borg/passphrase"

Инициализируйте зашифрованный репозиторий:

borg init --encryption=repokey

Экспортируйте ключ Borg:

borg key export /root/borg-repository-key.txt

Перенесите экспортированный ключ в отдельное защищённое хранилище. Не оставляйте единственную его копию только на исходном сервере.

Создайте первый архив:

borg create --stats --compression lz4 ::'{hostname}-{now:%Y-%m-%dT%H:%M:%S}' /etc /home /srv/app-data --exclude '/home/*/.cache' --exclude '/var/cache'

Проверьте список архивов:

borg list

Для удалённого Borg-репозитория SSH-ключ можно дополнительно ограничить командой borg serve и каталогом /srv/backup/borg. Такое ограничение вносится в authorized_keys пользователя backup на VPS. Перед его применением проверьте синтаксис для установленной версии Borg и сохраните отдельный административный доступ к серверу.

Расписание, хранение копий и защита репозитория

Настройте запуск через systemd

Для автоматизации удобнее использовать systemd timer — планировщик systemd, который запускает указанную службу по расписанию и фиксирует результат в журнале.

Создайте скрипт /usr/local/sbin/run-offsite-backup. Для restic его содержимое может выглядеть так:

#!/bin/sh
set -eu

exec /usr/bin/restic \
  -r sftp:ipway-backup:/srv/backup/restic \
  --password-file /root/.config/restic/repository-password \
  backup /etc /home /srv/app-data \
  --exclude-file /etc/restic-excludes.txt \
  --host server01

Установите владельца и права:

sudo chown root:root /usr/local/sbin/run-offsite-backup
sudo chmod 700 /usr/local/sbin/run-offsite-backup

Для Borg используется отдельный скрипт с переменными BORG_REPO и BORG_PASSCOMMAND и командой borg create. Не размещайте парольную фразу прямо в тексте скрипта.

Создайте службу /etc/systemd/system/offsite-backup.service:

[Unit]
Description=Encrypted off-site backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/run-offsite-backup

Создайте таймер /etc/systemd/system/offsite-backup.timer:

[Unit]
Description=Daily off-site backup

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

[Install]
WantedBy=timers.target

Перечитайте конфигурацию и включите таймер:

sudo systemctl daemon-reload
sudo systemctl enable --now offsite-backup.timer
sudo systemctl list-timers offsite-backup.timer

До ожидания расписания выполните тестовый запуск:

sudo systemctl start offsite-backup.service
sudo systemctl status offsite-backup.service

Журнал задания:

sudo journalctl -u offsite-backup.service --since today

Статус active (waiting) у таймера не означает, что резервная копия уже создана. Он показывает только ожидание следующего запуска. Проверяйте результат службы и наличие нового снимка или архива.

Настройте политику хранения

Retention — правило, определяющее, какие копии и как долго нужно хранить. Например:

• 7 ежедневных;
• 4 еженедельных;
• 6 ежемесячных.

Для restic сначала проверьте результат без удаления:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password forget --host server01 --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run

Для Borg:

borg prune --list --dry-run --glob-archives '{hostname}-*' --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Проверьте, какие именно снимки или архивы будут сохранены и удалены.

Применение политики в restic:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password forget --host server01 --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Применение политики в Borg:

borg prune --list --glob-archives '{hostname}-*' --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact

У Borg удаление архива не всегда сразу освобождает место. Для фактической очистки неиспользуемых сегментов выполняется borg compact.

Не добавляйте удаление старых копий в ежедневный скрипт до того, как политика будет проверена на реальном наборе архивов.

Контролируйте свободное место

На VPS периодически проверяйте файловую систему:

df -h /srv/backup

И размер каталогов:

sudo du -sh /srv/backup/restic /srv/backup/borg 2>/dev/null

Наличие свободного места нужно контролировать автоматически. Задание может начать завершаться ошибкой раньше, чем файловая система будет полностью заполнена.

Защитите репозиторий от удаления

Шифрование не защищает от удаления. Если злоумышленник получил контроль над основным сервером и его SSH-ключом, он может попытаться удалить доступные копии.

Риск снижают несколько независимых мер:

• отдельный пользователь на VPS;
• ключ, предназначенный только для резервного копирования;
• ограничение ключа конкретным каталогом или серверным режимом Borg;
• отдельные учётные данные для обслуживания и удаления старых копий;
• снапшоты диска VPS или дополнительная копия репозитория;
• неизменяемое объектное хранилище, если этого требует модель угроз;
• запрет обычного административного доступа по backup-ключу.

Как проверить резервную копию и выполнить восстановление

Создание снимка — только половина задачи. Рабочей считается копия, из которой данные удалось восстановить и проверить.

Проверка restic

Сначала выполните структурную проверку репозитория:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password check

Проверка всех хранимых данных требует больше времени и сетевого трафика:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password check --read-data

Полную проверку лучше запускать в период низкой нагрузки. Она не заменяет восстановление файлов.

Создайте отдельный тестовый каталог:

sudo install -d -m 700 /var/tmp/restic-restore-test

Восстановите последний снимок:

sudo restic -r sftp:ipway-backup:/srv/backup/restic --password-file /root/.config/restic/repository-password restore latest --target /var/tmp/restic-restore-test --host server01

Проверьте:

• присутствуют ли нужные каталоги;
• читаются ли файлы;
• сохранились ли права и владельцы;
• открываются ли архивы и дампы;
• можно ли поднять приложение или базу в тестовой среде.

Не восстанавливайте тестовую копию поверх рабочего каталога.

Проверка Borg

Проверьте структуру репозитория:

borg check

Затем выведите список архивов:

borg list

Выберите конкретное имя архива и просмотрите его содержимое:

borg list ::ARCHIVE_NAME

Создайте пустой тестовый каталог и перейдите в него:

sudo install -d -m 700 /var/tmp/borg-restore-test
cd /var/tmp/borg-restore-test

Восстановите выбранный каталог. Путь внутри архива указывается без начального /:

borg extract ::ARCHIVE_NAME etc

Для полного теста можно извлечь весь архив:

borg extract ::ARCHIVE_NAME

Borg восстанавливает данные в текущий каталог. Перед запуском убедитесь, что находитесь именно в подготовленном тестовом каталоге.

Что проверять после восстановления

Тест нельзя считать завершённым только потому, что команда вернула код 0. Проверка должна отвечать на практические вопросы:

1. Найдены ли все необходимые данные.
2. Соответствует ли копия ожидаемой дате.
3. Сохранились ли права доступа.
4. Можно ли открыть восстановленные файлы.
5. Проходит ли проверку дамп базы данных.
6. Можно ли запустить сервис в изолированной среде.
7. Зафиксированы ли время восстановления и обнаруженные проблемы.

Для критичной системы заранее определяют:

• RPO — сколько данных допустимо потерять по времени;
• RTO — за какое время нужно вернуть сервис в работу.

Если резервная копия создаётся раз в сутки, она не обеспечит RPO в один час. Если восстановление занимает восемь часов, оно не соответствует RTO в два часа.

Настройте контроль результата

Минимальный контроль включает:

• статус systemd-службы;
• код завершения restic или Borg;
• появление нового снимка;
• возраст последней успешной копии;
• свободное место на VPS;
• периодическую проверку репозитория;
• журнал тестовых восстановлений.

Не настраивайте уведомление только на факт запуска задания. Нужен сигнал об успешном завершении и отдельное оповещение при отсутствии свежей копии.

Заключение

Отдельный VPS позволяет вынести резервные копии за пределы основного сервера и снизить риск одновременной потери исходных данных и копий. Restic проще использовать с обычным SFTP, а Borg подходит для управляемой Linux-инфраструктуры, где инструмент можно установить на обе стороны.

Однако сам факт появления репозитория ещё не означает, что резервирование работает. Нужно контролировать расписание, свободное место, политику хранения и результат каждого задания. Главная проверка — восстановление данных в отдельную тестовую среду.

Что почитать дальше

• Первичная настройка Ubuntu VPS после заказа — подготовка пользователя, SSH, обновлений и firewall.
• Docker на Linux VPS: production-развёртывание — работа с контейнерами, томами и резервным копированием.
• Резервное копирование Windows VPS — отдельная инструкция для Windows-серверов.

Когда стоит обратиться к специалистам

Помощь специалиста нужна, если инфраструктура включает несколько серверов, большие базы данных, Docker-кластеры, короткие RPO/RTO или требования к неизменяемости копий.

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

Для отдельного хранения зашифрованных копий можно подобрать Linux VPS. Также доступны готовые варианты VPS на Ubuntu, VPS на Debian и VPS на Oracle Linux.

Кратко

• Резервная копия на том же сервере не защищает от потери всей системы.
• Отдельный VPS может использоваться как удалённый зашифрованный репозиторий.
• Restic удобен для SFTP и разных типов хранилищ, а Borg — для управляемых Linux-серверов по SSH.
• Базы данных и активные приложения нужно подготовить к копированию штатными средствами.
• Пароль restic или ключ и парольная фраза Borg должны храниться отдельно от репозитория.
• Политику удаления старых копий сначала проверяют через --dry-run.
• Шифрование скрывает содержимое, но не защищает репозиторий от удаления.
• Резервирование считается рабочим только после успешного тестового восстановления.