Резервные копии VPS: три способа и проверка восстановления

Что копировать

Копия должна позволить поднять сайт или сервис на новом сервере. Для этого нужны три вещи.

• Файлы: код сайта, загруженные пользователями картинки и документы (например, /var/www/site).
• Базы данных: MySQL, MariaDB или PostgreSQL. Копировать файлы базы «как есть» на работающем сервере нельзя, нужна выгрузка специальной командой.
• Конфигурация: настройки nginx (/etc/nginx), файлы окружения с ключами и паролями (.env), задания cron, настройки сервисов. Без них восстановление затянется.

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

Если копия лежит на том же диске, она пропадёт вместе с сервером: при поломке диска, взломе, случайном удалении или блокировке аккаунта. Храните копию на другом сервере, в объектном хранилище (S3-совместимом) или хотя бы на другом физическом носителе у вас дома. Лучше иметь копию в другом месте, не только у того же хостера.

Способ 1. Снимки от хостера

Многие хостеры предлагают снимок диска (снапшот) или автоматические копии виртуальной машины. Это удобно: снимок делается кнопкой в панели и целиком возвращает сервер.

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

Способ 2. Свой скрипт

Скрипт делает выгрузку базы, архивирует файлы и отправляет их на другой сервер. Нужен второй сервер с доступом по SSH-ключу.

Создайте файл /usr/local/bin/backup.sh:

#!/bin/bash
set -e
DATE=$(date +%F)
DIR=/var/backups/site
mkdir -p "$DIR"

# выгрузка базы MySQL/MariaDB (учётные данные лежат в ~/.my.cnf)
mysqldump --single-transaction mydb | gzip > "$DIR/db-$DATE.sql.gz"

# для PostgreSQL вместо этого:
# sudo -u postgres pg_dump mydb | gzip > "$DIR/db-$DATE.sql.gz"

# архив файлов сайта и конфигурации nginx
tar -czf "$DIR/files-$DATE.tar.gz" /var/www/site /etc/nginx

# отправка на другой сервер
rsync -az -e ssh "$DIR/" backup@backup.example.ru:/srv/backups/myvps/

# удалить локальные копии старше 7 дней
find "$DIR" -type f -mtime +7 -delete

Что делают команды:

• mysqldump --single-transaction выгружает базу в SQL-файл, не блокируя таблицы InnoDB; gzip сжимает результат.
• pg_dump делает то же для PostgreSQL.
• tar -czf собирает и сжимает файлы в один архив.
• rsync -az -e ssh передаёт новые файлы по SSH, сжимая их при передаче.
• find ... -delete убирает старые копии, чтобы не забить диск.

Пароль базы не пишите в команду. Положите его в файл ~/.my.cnf с правами chmod 600, секция [client], поля user и password.

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

sudo chmod +x /usr/local/bin/backup.sh

Способ 3. Готовый инструмент restic

Restic хранит копии в зашифрованном репозитории, делает инкрементальные копии (передаёт только изменённое) и умеет удалять старые. Репозиторий может лежать на другом сервере по SFTP или в S3-хранилище.

Установка из репозитория Ubuntu:

sudo apt install restic

Создайте репозиторий на удалённом сервере (restic спросит пароль шифрования; потеряете его, потеряете копии):

restic -r sftp:backup@backup.example.ru:/srv/restic-repo init

Сделайте копию папок:

restic -r sftp:backup@backup.example.ru:/srv/restic-repo backup /var/www/site /etc/nginx

Выгрузку базы restic тоже может принять: сначала сделайте mysqldump в файл в /var/backups/site, затем добавьте эту папку в backup. Для запуска без ручного ввода пароля положите его в файл и задайте переменную RESTIC_PASSWORD_FILE.

Список копий и очистка старых (оставить 7 дневных, 4 недельных и 6 месячных):

restic -r sftp:backup@backup.example.ru:/srv/restic-repo snapshots
restic -r sftp:backup@backup.example.ru:/srv/restic-repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Запуск по расписанию (cron)

Откройте расписание пользователя root:

sudo crontab -e

И добавьте строку, которая запускает скрипт каждую ночь в 3:30 и пишет вывод в журнал:

30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Если запускаете restic, укажите в cron свою команду restic ... backup вместо скрипта.

Обязательно проверьте восстановление

Копия, из которой не пробовали восстановиться, считается ненадёжной. Раз в месяц проверяйте на отдельном сервере или в пустой папке.

Для restic:

restic -r sftp:backup@backup.example.ru:/srv/restic-repo check
restic -r sftp:backup@backup.example.ru:/srv/restic-repo restore latest --target /tmp/restore-test

check проверяет целостность репозитория, restore latest разворачивает последнюю копию в указанную папку. Для SQL-выгрузки проверьте, что файл открывается: gunzip -c db-2026-10-05.sql.gz | head, и при возможности загрузите его в тестовую базу.

Что делать дальше

Второй сервер для копий не обязан быть мощным: подойдёт самый дешёвый VPS из подбора, в нашей базе они стоят от 140 ₽ в месяц (сверено 5 октября 2026 года). Если вы только настраиваете сервер, начните с первой настройки VPS, а доступ к удалённой машине описан в статье про подключение по SSH.