В аренде VPS/VDS доступ к гипервизору обычно отсутствует: нельзя снять полноценный снапшот диска «снаружи», нет консоли гипервизора, а функции резервного копирования провайдера либо недоступны, либо не дают нужной гибкости. В таких условиях резервное копирование приходится строить внутри гостевой ОС – как агентный файловый бэкап с обязательной проверкой восстановления.
Ниже описан прикладной сценарий для Linux‑виртуального сервера: хранение резервных копий вне защищаемого узла, шифрование «на стороне сервера», политика удержания (retention) и регулярное тестовое восстановление. В качестве инструмента используется restic – он подходит для VPS/VDS именно тем, что не требует поддержки со стороны гипервизора и при этом обеспечивает криптографически защищенный, дедуплицированный репозиторий.
Контекст: что меняется, когда нет доступа к гипервизору
В отличие от «образов дисков» и гипервизорных снапшотов, агентный файловый бэкап работает на уровне файловой системы и приложений. Это накладывает важные ограничения:
- Консистентность данных приходится обеспечивать самостоятельно (особенно для СУБД и очередей)
- Восстановление «в ноль» обычно означает: развернуть новый VPS/VDS, поставить пакеты/сервисы, затем вернуть конфигурацию и данные из бэкапа
- Скорость восстановления определяется не только размером данных, но и готовностью «bootstrap‑процедуры» (переустановка, конфиги, ключи, сертификаты)
При аренде виртуальных серверов у разных провайдеров – например, у VPS.house – типовая картина одинаковая: внутри ОС есть root‑доступ, а вот управлять снапшотами гипервизора напрямую нельзя. Поэтому реальная надежность бэкапа складывается из трех вещей: корректного набора данных, надежного внешнего хранилища и регулярно проверяемого восстановления.
Почему restic подходит для VPS/VDS‑бэкапа
restic – утилита резервного копирования с репозиторием, который:
- Шифруется на клиенте (до отправки в хранилище). Даже если репозиторий окажется скомпрометирован, содержимое без пароля не читается
- Дедуплицируется: одинаковые блоки данных не хранятся повторно, что снижает расход места при регулярных бэкапах
- Проверяет целостность с помощью криптографических хэшей и команды restic check
- Поддерживает разные бэкенды: S3‑совместимое object storage, SSH/SFTP на отдельный сервер, локальные диски и другие варианты
Важный практический момент: restic по умолчанию предполагает, что хранилищу доверять нельзя. Поэтому шифрование и контроль целостности – не «опции», а базовая часть модели.
Выбор места для репозитория: S3 или отдельный сервер по SSH
Сценарий «бэкап на тот же VPS» почти не решает задачу: при взломе, ошибке администратора, удалении данных или отказе диска резервная копия исчезает вместе с сервером. Нужен внешний репозиторий. На практике для VPS/VDS чаще выбираются два пути.
S3‑совместимое object storage
Плюсы:
- репозиторий физически отделен от сервера
- масштабируемость и высокая доступность (в зависимости от поставщика)
- удобно хранить «долго» и «много»
Минусы и ограничения:
- задержки и стоимость запросов/трафика могут быть заметны на больших репозиториях
- для высокой скорости восстановления важен канал и расположение (иногда критично, чтобы хранилище было близко к региону размещения VPS)
Репозиторий на отдельном VPS/VDS через SFTP (SSH)
Плюсы:
- полный контроль над диском, файловой системой и доступами
- прозрачная модель затрат (диск и трафик понятны заранее)
- можно выбрать географически близкую площадку для быстрого восстановления
Минусы и ограничения:
- второй сервер тоже нужно администрировать (обновления, SSH‑политики, мониторинг диска)
- отказ второго VPS приведет к потере доступа к репозиторию, если нет резервирования
В реальных внедрениях распространен компромисс: выделить отдельный VPS под репозиторий restic (с минимальным набором сервисов и жесткими SSH‑ограничениями), а затем дополнительно выгружать данные в объектное хранилище по отдельному расписанию. Если нужен простой старт, часто достаточно одной внешней точки – например, отдельного VPS под репозиторий restic в том же регионе, где работает основной сервер, чтобы восстановление было быстрее.
Что именно бэкапить на виртуальном сервере
Список данных для бэкапа всегда привязан к роли сервера, но есть практический минимум, который часто оказывается критичным при восстановлении:
- Конфигурация: /etc (но осознанно исключая лишнее), файлы systemd‑юнитов, конфиги веб‑сервера, планировщики, правила firewall
- Данные приложений: каталоги проекта, пользовательские загрузки, медиа, статика
- Ключи и секреты: SSH‑ключи сервисных пользователей, TLS‑сертификаты (например, /etc/letsencrypt), переменные окружения приложений (.env), токены интеграций
- Данные СУБД – не «как файлы», а через дампы или специализированные инструменты, чтобы получить консистентную копию
- Список пакетов и процедура bootstrap: это не всегда «файлы для бэкапа», но почти всегда нужно для быстрого восстановления
Типовые исключения (чтобы не тащить мусор и «виртуальные» файловые системы): /proc, /sys, /dev, /run, /tmp, кеши пакетных менеджеров, большие логи, которые уже централизованно собираются.
СУБД и консистентность: почему нельзя ограничиться копированием каталога
Для PostgreSQL, MySQL/MariaDB и большинства других СУБД копирование файлов каталога данных «как есть» на работающем сервере часто приводит к неконсистентному бэкапу. Без гипервизорного снапшота нельзя «заморозить диск» с гарантией целостности, поэтому обычно используются дампы или механизмы point‑in‑time recovery (PITR) – в зависимости от требований к RPO/RTO.
Для небольших VPS/VDS‑инсталляций чаще всего достаточно регулярных логических дампов:
- PostgreSQL: pg_dump (одна БД) или pg_dumpall (все БД и роли) с разумными параметрами
- MySQL/MariaDB: mysqldump с —single-transaction для InnoDB, чтобы не блокировать таблицы надолго
Практически удобная схема: перед запуском restic‑бэкапа сформировать дампы в отдельный каталог (например, /var/backups/db), а затем включить этот каталог в backup‑набор. Тогда восстановление СУБД превращается в отдельный понятный шаг.
Настройка restic: базовые шаги (Linux, root‑доступ)
Шаг 1. Установка и учет данных доступа
Установка restic выполняется через пакетный менеджер дистрибутива или через официальный релиз. Важно заранее определить:
- куда будет писать репозиторий (S3 или SFTP)
- где хранится пароль репозитория
- как задаются креды для бэкенда (переменные окружения или отдельный файл, читаемый только root)
Рекомендуемый минимум по безопасности для пароля репозитория:
- хранить в файле с правами 0600 (только root)
- не класть этот файл в тот же каталог, который резервируется
- иметь отдельную копию пароля в менеджере секретов или другом доверенном месте
Шаг 2. Инициализация репозитория
Пример для SFTP‑репозитория на удаленном сервере:
restic -r sftp:restic@backup.example:/srv/restic/repo init
Пример для S3‑совместимого object storage (URL зависит от конкретного провайдера):
export RESTIC_REPOSITORY=«s3:https://s3.example.com/backup-bucket»
export AWS_ACCESS_KEY_ID=«…»
export AWS_SECRET_ACCESS_KEY=«…»
restic init
После инициализации имеет смысл сразу проверить доступ:
restic snapshots
Шаг 3. Список исключений и «границы» файловой системы
Для VPS/VDS важно не утащить в репозиторий лишнее. Типовая практика – вести отдельный файл исключений, например /etc/restic/excludes:
/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/log
В зависимости от задачи /var/log можно бэкапить выборочно или вообще исключить, если логи уже уходят в централизованное хранилище. Дополнительно часто используется ключ —one-file-system, чтобы не захватить смонтированные тома «по дороге».
Шаг 4. Скрипт бэкапа: данные + дампы + теги
На практике удобно держать один основной скрипт, который:
- готовит дампы СУБД (если есть)
- запускает restic backup с понятным набором путей
- применяет retention‑политику
- пишет лог и отдает код завершения для мониторинга
Пример логики (адаптируется под конкретную структуру сервера):
#!/bin/sh
set -eu
export RESTIC_REPOSITORY=«sftp:restic@backup.example:/srv/restic/repo»
export RESTIC_PASSWORD_FILE=«/etc/restic/password»
export RESTIC_CACHE_DIR=«/var/cache/restic»
# 1. Подготовка дампов СУБД (примерный вызов отдельного скрипта)
/usr/local/sbin/backup-db.sh
# 2. Бэкап файлов и конфигурации
restic backup \
—one-file-system \
—exclude-caches \
—exclude-file /etc/restic/excludes \
—tag «daily» \
/etc /home /var/www /var/backups
Отдельный скрипт для дампов позволяет проще тестировать восстановление и менять стратегию без затрагивания restic‑части. Для PostgreSQL, например, часто используется формат custom (удобнее при восстановлении) и ротация дампов внутри каталога:
#!/bin/sh
set -eu
mkdir -p /var/backups/db
chmod 700 /var/backups/db
# пример для PostgreSQL (имя БД и параметры подставляются по месту)
sudo -u postgres pg_dump —format=custom —file=«/var/backups/db/app_$(date +%F).dump» appdb
# удаление старых дампов, чтобы не плодить уникальные файлы бесконечно
find /var/backups/db -type f -name «app_*.dump» -mtime +14 -delete
Retention‑политика в restic: как не переполнить хранилище и не потерять историю
В restic удержание истории задается командой forget. Важно понимать механику:
- forget выбирает, какие снапшоты оставить, а какие «забыть» (удалить из списка)
- prune физически удаляет неиспользуемые данные из репозитория (освобождает место)
В небольших репозиториях часто запускается forget —prune после каждого бэкапа. На больших объемах prune может занимать заметное время, поэтому распространенный подход – выполнять forget ежедневно, а prune, например, раз в неделю в отдельном задании.
Пример retention‑настроек для «обычного» VPS
Один из понятных вариантов (корректируется под требования и стоимость хранения):
- ежедневные бэкапы за последние 14 дней
- еженедельные – за последние 8 недель
- ежемесячные – за последние 12 месяцев
- ежегодные – за последние 2-3 года (если нужно хранение «на всякий случай» и есть место)
Команда:
restic forget —tag «daily» —keep-daily 14 —keep-weekly 8 —keep-monthly 12 —keep-yearly 3
Если prune выполняется сразу:
restic forget —tag «daily» —keep-daily 14 —keep-weekly 8 —keep-monthly 12 —keep-yearly 3 —prune
В продакшене полезно фиксировать «контракт» retention‑политики отдельным документом: какие точки восстановления доступны и как долго. Это упрощает коммуникацию в инцидентах и помогает аргументированно планировать объем хранилища.
Регулярная проверка целостности: restic check и частичное чтение данных
Статус «backup completed successfully» не означает, что данные читаются и реально восстановятся. Минимум, который стоит включать в эксплуатационный цикл:
- restic check – проверка структуры и индексов репозитория
- периодическое чтение части данных, чтобы обнаружить повреждения носителя или проблемы на стороне бэкенда раньше, чем понадобится восстановление
Для экономии времени и трафика часто используется частичная проверка чтения данных (конкретный параметр подбирается по объему):
restic check —read-data-subset=5%
На практике это запускается по расписанию раз в неделю или раз в месяц – отдельно от ежедневного бэкапа.
Автоматизация: systemd timer вместо «хрупкого» cron
cron остается рабочим вариантом, но systemd‑таймеры дают дополнительные преимущества: контроль среды выполнения, журналирование в journald, удобные зависимости и параметр Persistent=true (пропущенные задания могут быть выполнены после перезагрузки).
Пример systemd‑юнита
Сервис /etc/systemd/system/restic-backup.service:
[Unit]
Description=Restic backup
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-restic.sh
Nice=19
IOSchedulingClass=idle
Пример таймера
Таймер /etc/systemd/system/restic-backup.timer:
[Unit]
Description=Run restic backup daily
[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=30m
Persistent=true
[Install]
WantedBy=timers.target
После создания файлов:
systemctl daemon-reload
systemctl enable —now restic-backup.timer
Отдельным таймером обычно оформляется еженедельный restic prune или расширенная проверка restic check, чтобы не смешивать «быстрое ежедневное» и «тяжелое сервисное» обслуживание репозитория.
Регулярная проверка восстановления: главный элемент надежности
Бэкап считается работоспособным только после восстановления. Для VPS/VDS без гипервизора это особенно важно: восстановление часто включает не только «вернуть файлы», но и поднять сервисы, восстановить базу, проверить права доступа и секреты.
Минимальная практика: тестовое восстановление файлов
Раз в месяц (или чаще при изменениях) полезно выполнять восстановление последнего снапшота в отдельный каталог на тестовой машине или на отдельном диске:
mkdir -p /var/tmp/restore-test
restic restore latest —target /var/tmp/restore-test
Далее проверяются хотя бы критичные элементы:
- наличие конфигов и секретов (например, переменных окружения приложения)
- целостность структуры каталогов
- валидность сертификатов и ключей (в том числе права доступа)
Практика уровня выше: восстановление сервиса в изолированном контуре
Для веб‑приложений и API полезно иметь «учебный» сценарий:
- поднять чистый VPS/VDS или тестовую виртуальную машину
- установить базовый набор пакетов (по чек‑листу или Ansible‑ролью)
- восстановить данные из restic
- развернуть дамп СУБД в тестовую БД
- запустить сервис и пройти smoke‑тест (например, запрос на health‑endpoint)
Такая проверка не обязана быть сложной, но должна быть регулярной и фиксируемой: дата, версия приложения, снапшот, результат, замечания. Это превращает восстановление из «уникального события» в повторяемую процедуру.
Сценарий аварийного восстановления на новом VPS/VDS
При потере исходного виртуального сервера восстановление обычно выглядит так:
- Развернуть новый VPS/VDS в нужном регионе и с достаточным объемом диска
- Обновить ОС, настроить SSH‑доступ, базовые политики безопасности (firewall, запрет лишних логинов, обновления)
- Установить restic и подготовить доступ к репозиторию (пароль, ключи S3/SSH)
- Восстановить данные: конфигурацию, каталоги приложений, дампы СУБД
- Восстановить сервисы: пакеты, systemd‑юниты, переменные окружения, сертификаты
- Восстановить СУБД из дампа и проверить доступы
- Провести пост‑проверки: доступность сервиса, логи, мониторинг, ротация ключей при необходимости
Нюанс, который часто недооценивается: без доступа к гипервизору нет «магического» восстановления загрузчика и сетевых настроек как в образе диска. Поэтому документация bootstrap‑процедуры и автоматизация (Ansible, cloud-init, скрипты) заметно сокращают RTO.
Типичные ошибки при агентном бэкапе VPS/VDS
- Бэкап «только /var/www» без конфигов, секретов и TLS‑сертификатов. В результате восстановление превращается в сбор по кускам
- Копирование каталога базы данных вместо дампа или штатного механизма СУБД – высокий риск неконсистентности
- Пароль репозитория лежит на сервере в читаемом виде или попадает в бэкап вместе с /etc
- Нет retention‑политики – хранилище переполняется, бэкапы начинают падать, а проблема обнаруживается слишком поздно
- Нет тестов восстановления – самая частая причина «неожиданного» провала в момент инцидента
- Единственная точка хранения – один удаленный сервер или один bucket без дополнительных мер. Для критичных систем лучше планировать второй контур (хотя бы периодическую выгрузку в другое место)
Чек‑лист эксплуатации (коротко)
- Репозиторий находится вне защищаемого VPS/VDS
- Пароль репозитория хранится отдельно, файл – с правами 0600, не попадает в бэкап
- СУБД резервируется консистентно (дампы или специализированные механизмы)
- Настроены forget/prune и понятная retention‑политика
- Включены регулярные проверки restic check и периодическое чтение части данных
- Есть расписание через systemd timer и понятный лог выполнения
- Проводится регулярное тестовое восстановление (файлы + запуск сервиса в тестовом контуре)
- Описана процедура восстановления «с нуля» на новом виртуальном сервере
Бэкап на VPS/VDS без доступа к гипервизору – это не «облегченный» вариант, а отдельная дисциплина: консистентность на уровне приложений, шифрование до отправки в хранилище, контролируемая retention‑политика и обязательные учения по восстановлению. При соблюдении этих принципов restic позволяет получить предсказуемый и проверяемый процесс, который не зависит от наличия гипервизорных снапшотов у провайдера.