Резервное копирование сайта на VPS: как настроить бэкапы и проверить их

На виртуальном хостинге бэкапы делает провайдер, на VPS — вы сами. Это главное, что меняется после переезда, и о чём вспоминают обычно в худший момент: после неудачного обновления, взлома или случайного DROP TABLE.

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

Что именно нужно копировать

Файлы сайта — код, загруженные картинки и документы. Базу данных — весь контент, заказы и пользователи живут там. Конфигурацию сервера — файлы nginx, сертификаты, задания cron, unit-файлы systemd: без них восстановление превращается в повторную настройку с нуля.

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

Шаг 1. Сервер, на котором это делается

Если вы только переезжаете, порядок такой: в панели NodexGo нажмите «Создать сервер», выберите локацию (рядом с каждой показан ваш реальный пинг), тариф, образ Ubuntu 24.04 и имя, затем период оплаты — 1, 3, 6 или 12 месяцев. Через минуту IP-адрес и пароль root придут в панель и на почту, и можно подключаться:

ssh root@IP-адрес-сервера

Отдельно оцените диск: бэкапы занимают место, и держать месяц ежедневных копий базы прямо на сервере — обычная практика. Если места не хватит, тариф всегда можно повысить кнопкой «Увеличить мощности» — данные при этом остаются на месте.

Шаг 2. Копия базы данных

Базу нельзя копировать как обычный файл на работающем сервере — получится битая копия. Для MySQL и MariaDB используйте mysqldump: ключ --single-transaction снимает согласованный слепок, не блокируя сайт.

mysqldump -u root -p --single-transaction --routines --events имя_базы > /root/backups/db-$(date +%F).sql

Для PostgreSQL то же самое делает pg_dump:

pg_dump -U postgres имя_базы > /root/backups/db-$(date +%F).sql

Дампы отлично сжимаются — обычно в пять-десять раз:

gzip /root/backups/db-$(date +%F).sql

Шаг 3. Копия файлов

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

mkdir -p /root/backups
tar -czf /root/backups/files-$(date +%F).tar.gz /var/www /etc/nginx /etc/letsencrypt

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

rsync -a --delete /var/www/ /root/backups/www-mirror/

Шаг 4. Автоматизация одним скриптом

Ручные бэкапы не работают — их перестают делать через неделю. Соберём всё в один скрипт:

nano /root/backup.sh

#!/bin/bash
set -euo pipefail

DATE=$(date +%F)
DEST=/root/backups
KEEP_DAYS=14

mkdir -p "$DEST"

# база
mysqldump -u root --single-transaction --routines имя_базы | gzip > "$DEST/db-$DATE.sql.gz"

# файлы и конфигурация
tar -czf "$DEST/files-$DATE.tar.gz" /var/www /etc/nginx /etc/letsencrypt

# чистим старое
find "$DEST" -type f -mtime +$KEEP_DAYS -delete

echo "backup $DATE ok"

Чтобы скрипт не спрашивал пароль базы, положите его в файл /root/.my.cnf, доступный только root:

printf '[client]\nuser=root\npassword=пароль-базы\n' > /root/.my.cnf
chmod 600 /root/.my.cnf

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

chmod +x /root/backup.sh
/root/backup.sh
ls -lh /root/backups

Шаг 5. Запуск по расписанию

Открываем планировщик и добавляем ежедневный запуск в 4 утра с записью в лог:

crontab -e

0 4 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Через сутки убедитесь, что задание отработало:

tail -20 /var/log/backup.log

Шаг 6. Копия за пределами сервера

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

rsync -avz -e ssh root@IP-адрес-сервера:/root/backups/ ~/site-backups/

Более взрослый способ — rclone: он умеет заливать в S3-совместимые хранилища и облачные диски. Настройка выполняется один раз в диалоге:

apt install -y rclone
rclone config

После этого отправка копий добавляется в тот же скрипт одной строкой:

rclone copy /root/backups remote:site-backups --max-age 2d

Шаг 7. Проверить, что копия рабочая

Бэкап, который ни разу не восстанавливали, бэкапом не является. Проверка занимает пять минут. Смотрим, что архив цел и что дамп не пустой:

gzip -t /root/backups/db-*.sql.gz && echo 'архив цел'
zcat /root/backups/db-2026-08-01.sql.gz | head -20

Настоящая проверка — развернуть копию в отдельную базу и заглянуть внутрь:

mysql -u root -e 'CREATE DATABASE restore_test'
zcat /root/backups/db-2026-08-01.sql.gz | mysql -u root restore_test
mysql -u root -e 'SELECT COUNT(*) FROM restore_test.wp_posts'

Удобно делать такую проверку раз в месяц — и обязательно после любого изменения в скрипте бэкапа.

Как часто копировать

Ориентируйтесь на простой вопрос: за какой период данных вам не жалко. Блог переживёт суточную потерю, у интернет-магазина сутки заказов — это уже деньги, поэтому базу там копируют раз в несколько часов, а файлы — раз в сутки.

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

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

Сначала база, потом файлы, потом конфигурация. Разворачиваем дамп:

zcat /root/backups/db-2026-08-01.sql.gz | mysql -u root имя_базы

Возвращаем файлы:

tar -xzf /root/backups/files-2026-08-01.tar.gz -C /

Если сервер не загружается или потерян доступ по SSH, в карточке сервера в панели есть web-консоль VNC — через неё можно войти в систему в обход сети. В крайнем случае рядом кнопка «Переустановить ОС»: чистая система ставится за пару минут, а сайт поднимается из копий по этой же инструкции.

Коротко

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