Как настроить бэкапы VPS — стратегия 3-2-1 и автоматизация

Потеря данных на VPS — не редкость, и провайдер за неё не отвечает. Договор с хостингом защищает инфраструктуру: железо, сеть, электропитание. Всё, что находится внутри виртуальной машины — ваши файлы, базы данных, конфиги — полностью на вашей стороне. Отказ диска, случайный rm -rf /var/www, криптолокер, который зашифровал весь сайт ночью — каждый из этих сценариев одинаково уничтожает данные без возможности восстановления, если бэкапы VPS не настроены заранее. Рассказываем, как настроить бэкапы VPS, какую стратегию выбрать и что автоматизировать через cron и современные инструменты — restic, BorgBackup, rsync. Базовая защита сервера: защита от DDoS-атак и резервное копирование — два независимых уровня, которые не заменяют друг друга.

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

Что такое стратегия 3-2-1 и почему она работает

Правило 3-2-1 сформулировал фотограф Питер Крог в начале 2000-х, когда цифровые архивы начали вытеснять плёнку. Логика проста: ни один способ хранения не надёжен сам по себе, поэтому нужна избыточность на нескольких уровнях.

Суть правила:

• 3 копии данных — оригинал и два независимых бэкапа
• 2 разных носителя — например, локальный диск и отдельный сервер
• 1 offsite-хранилище — копия физически в другом месте или в облаке

Применительно к VPS это выглядит так: основные данные на вашем сервере — первая копия. Инкрементальный rsync на второй VPS или NAS — вторая. Зашифрованный архив в облачном S3-хранилище — третья и offsite одновременно.

Локальная, удалённая и облачная копия — чем они отличаются

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

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

Облачная копия в другом регионе — это страховка на случай катастрофы. Скорость восстановления зависит от размера данных и канала, но она всегда доступна независимо от состояния вашей инфраструктуры. Именно облако закрывает «1» в правиле 3-2-1.

Что именно бэкапить на VPS

Бэкапить «весь сервер» нерационально: теряется время, растут расходы на хранение, а нужное всё равно можно не найти. Правильный подход — выделить критичные данные, которые нельзя восстановить из другого источника.

Что обязательно включать в резервную копию сервера:

• /var/www — файлы сайтов и веб-приложений
• Базы данных — MySQL, PostgreSQL (отдельным дампом, не копированием файлов)
• /etc — конфиги системы и сервисов: Nginx, PHP-FPM, SSH, cron, ключи SSH и системные настройки
• SSL-сертификаты — /etc/letsencrypt или аналог
• Docker volumes — если используете контейнеры
• /home — пользовательские файлы и .ssh/authorized_keys
• /root — скрипты, .my.cnf с реквизитами для mysqldump, crontab

Что бэкапить не нужно:

• /var/log — логи восстанавливать незачем, они генерируются заново
• /tmp, /proc, /sys, /dev — системные временные и виртуальные ФС
• Кэши приложений (/var/cache, cache/ внутри проектов)
• /var/lib/mysql напрямую — это файлы базы данных, которые нельзя просто скопировать на работающей базе

Снапшоты провайдера против файловых бэкапов

Большинство VPS-провайдеров предлагают снапшоты — полный слепок диска виртуальной машины в определённый момент. Тарифы Aeza и AdminVPS включают снапшоты через панель управления, у Selectel это отдельная услуга объектного хранилища.

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

Но у снапшотов есть ограничения:

• Снапшот хранится на инфраструктуре того же провайдера — если провайдер теряет данные, теряются и снапшоты
• Нет гранулярного восстановления: нельзя достать один файл из снапшота без полного разворачивания
• Цена растёт пропорционально размеру диска
• Снапшот — не замена offsite-бэкапу по правилу 3-2-1

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

Резервное копирование через rsync — простой и надёжный способ

rsync — стандартный Unix-инструмент для синхронизации файлов по SSH. Работает инкрементально: при повторном запуске передаёт только изменившиеся блоки. Не требует установки на стороне сервера-приёмника ничего кроме SSH.

Базовый бэкап директории сайта на удалённый сервер:

# Базовый rsync-бэкап директории сайта
rsync -avz --delete \
  --exclude='*.log' \
  --exclude='cache/' \
  /var/www/example.com/ \
  backup@remote-server.example:/backups/example.com/

Ключи: -a — архивный режим (сохраняет права, владельца, симлинки), -v — вывод прогресса, -z — сжатие при передаче, --delete — удалять на приёмнике файлы, которых уже нет на источнике.

Инкрементальные бэкапы с хардлинками через --link-dest позволяют хранить историю версий без дублирования одинаковых файлов. Каждый запуск создаёт новую директорию с датой, но файлы, не изменившиеся с прошлого раза, занимают место только один раз:

# Инкрементальный бэкап с хардлинками
rsync -avz --delete \
  --link-dest=/backups/example.com/latest/ \
  /var/www/example.com/ \
  backup@remote-server.example:/backups/example.com/$(date +%Y-%m-%d)/

rsync хорошо работает для файловых бэкапов, но не умеет делать дампы баз данных и не поддерживает шифрование из коробки. Для переноса сайта на VPS — те же команды, те же инструменты.

Бэкап баз данных — MySQL и PostgreSQL

Базы данных нельзя бэкапить простым копированием файлов /var/lib/mysql или /var/lib/postgresql на работающем сервере: файлы могут быть в несогласованном состоянии, и восстановить из них базу не получится. Правильный способ — дамп через специализированные инструменты.

MySQL: mysqldump

Чтобы не хранить пароль в скрипте, реквизиты подключения выносятся в /root/.my.cnf:

# /root/.my.cnf
[client]
user=root
password=your_password

# Дамп всех баз MySQL с архивацией
mysqldump --defaults-file=/root/.my.cnf --all-databases | \
  gzip > /root/backups/mysql-$(date +%Y-%m-%d).sql.gz

PostgreSQL: pg_dump

# Дамп одной базы PostgreSQL
sudo -u postgres pg_dump dbname | \
  gzip > /root/backups/pgdump-$(date +%Y-%m-%d).sql.gz

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

Restic — современный инструмент с дедупликацией и шифрованием

restic — инструмент резервного копирования с дедупликацией на уровне блоков и шифрованием по умолчанию. Поддерживает S3-совместимые хранилища, Backblaze B2, SFTP, локальные директории. Каждый бэкап — неизменяемый снапшот, можно откатиться к любой точке.

Инициализация репозитория в S3 и первый бэкап:

# Инициализация репозитория restic на S3-совместимом хранилище
export AWS_ACCESS_KEY_ID=your_key
export AWS_SECRET_ACCESS_KEY=your_secret
restic -r s3:https://storage.example.com/my-bucket init

# Первый бэкап
restic -r s3:https://storage.example.com/my-bucket backup /var/www /etc

# Список снапшотов
restic -r s3:https://storage.example.com/my-bucket snapshots

# Политика хранения: 7 дней, 4 недели, 6 месяцев
restic -r s3:https://storage.example.com/my-bucket forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Команда forget --prune реализует retention policy — автоматическую ротацию копий. Без этого хранилище будет расти бесконечно.

BorgBackup — для тех, кто хранит на своём сервере

BorgBackup ориентирован на хранение через SSH/SFTP на собственном сервере. Отличается превосходной дедупликацией и возможностью монтировать репозиторий как FUSE-файловую систему — удобно для восстановления отдельных файлов без полного разворачивания архива.

# Инициализация Borg-репозитория на удалённом сервере
borg init --encryption=repokey backup@remote:/backups/borg-repo

# Создание архива с именем по дате
borg create backup@remote:/backups/borg-repo::$(date +%Y-%m-%d) \
  /var/www /etc /root \
  --exclude /var/www/*/cache

# Политика хранения
borg prune backup@remote:/backups/borg-repo \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3

Сравнение restic и BorgBackup

Автоматизация через cron — расписание бэкапов

Ручной бэкап, который вы делаете «раз в неделю», — это не система. Нормальная система запускается сама, пишет лог и оповещает об ошибках. Всё это реализуется через cron и небольшой скрипт-обёртку.

Скрипт ежедневного бэкапа с логированием:

# /usr/local/bin/backup.sh — скрипт ежедневного бэкапа
#!/bin/bash
set -euo pipefail
LOG="/var/log/backup.log"
DATE=$(date +%Y-%m-%d)

echo "[$DATE] Backup started" >> "$LOG"

# Бэкап файлов
restic -r s3:https://storage.example.com/bucket backup /var/www /etc \
  >> "$LOG" 2>&1

# Бэкап баз данных
mysqldump --defaults-file=/root/.my.cnf --all-databases | \
  gzip > /tmp/mysql-$DATE.sql.gz
restic -r s3:https://storage.example.com/bucket backup /tmp/mysql-$DATE.sql.gz \
  >> "$LOG" 2>&1
rm /tmp/mysql-$DATE.sql.gz

# Политика хранения
restic -r s3:https://storage.example.com/bucket forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 \
  >> "$LOG" 2>&1

echo "[$DATE] Backup finished" >> "$LOG"

# crontab -e — добавить задание
# Ежедневно в 3:00
0 3 * * * /usr/local/bin/backup.sh

Дать скрипту права на выполнение: chmod +x /usr/local/bin/backup.sh. Запускать от root, чтобы скрипт имел доступ ко всем нужным директориям. После первого автоматического запуска — проверить /var/log/backup.log.

Хранилище S3 — где хранить бэкапы

S3 — стандарт API для объектного хранилища, который поддерживают десятки провайдеров. restic, BorgBackup через rclone и большинство других инструментов умеют работать с любым S3-совместимым сервисом.

Варианты хранилища для offsite-бэкапов VPS:

Для VPS в Германии или другой европейской локации — удобно хранить offsite-бэкапы в другом регионе Европы или в США: это настоящая географическая избыточность.

Синхронизация директории бэкапов в S3 через rclone:

# Установка и настройка rclone
rclone config
# Синхронизация директории бэкапов в S3
rclone sync /root/backups/ remote:my-backup-bucket/vps-name/

Как проверить, что бэкап рабочий

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

Три уровня проверки:

1. Проверка целостности архива — каждую неделю автоматически
2. Тестовое восстановление файла — раз в месяц вручную
3. Полное восстановление на тестовый VPS — раз в квартал

# Проверка целостности репозитория restic
restic -r s3:https://storage.example.com/bucket check

# Восстановление конкретного файла из снапшота
restic -r s3:https://storage.example.com/bucket restore latest \
  --include /etc/nginx/nginx.conf \
  --target /tmp/restore-test/

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

Уведомления о результате бэкапа

Email-нотификации от cron часто теряются в спаме или не доходят вовсе. Надёжнее — отправлять статус в Telegram через Bot API. Создайте бота через @BotFather, получите bot_token и chat_id, добавьте в конец скрипта:

# Уведомление в Telegram об успешном бэкапе
TELEGRAM_TOKEN="your_bot_token"
CHAT_ID="your_chat_id"

curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="[$(hostname)] Backup $(date +%Y-%m-%d): OK" > /dev/null

# При ошибке — добавить в секцию trap:
# trap 'curl -s ... -d text="[$(hostname)] Backup FAILED"' ERR

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

Типичные ошибки при настройке бэкапов VPS

• Бэкапить только файлы без базы данных. Сайт без базы — это пустая директория. MySQL и PostgreSQL требуют отдельного дампа.
• Хранить бэкап на том же диске. Если диск упадёт — потеряете и данные, и бэкап. Минимум — другой VPS или S3.
• Не проверять восстановление. Скрипт пишет «OK» в лог, но репозиторий повреждён. Узнаёте об этом в худший момент.
• Не шифровать offsite-копии. Архив в S3 без шифрования — это все данные сайта и базы в открытом доступе для тех, кто получит ключ от хранилища.
• Забыть про /etc. Конфиги Nginx, SSH, PHP-FPM, crontab, .my.cnf с паролями — без них восстановление занимает часы вместо минут.
• Не настроить ротацию копий. Без forget --prune в restic или borg prune хранилище заполняется за недели. Потом либо платить больше, либо терять старые версии резко.
• Копировать /var/lib/mysql напрямую. Файлы InnoDB на работающем сервере — не резервная копия, а испорченный архив.
• Запускать бэкап от непривилегированного пользователя. Скрипт без прав к /etc или /root/backups молча пропустит нужные директории.

Выбор VPS с нативными снапшотами

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

Снапшоты из панели управления есть у большинства крупных российских провайдеров: стоимость обычно рассчитывается по объёму диска и времени хранения, конкретные цифры — в актуальных тарифах на сайте провайдера. Сравните провайдеров с нативными снапшотами и надёжной инфраструктурой в каталоге VPS free-hosting.ru — более 45 провайдеров с реальными тарифами.

Ну и в заключение

Рабочая стратегия резервного копирования VPS складывается из трёх вещей: правильный выбор что бэкапить, автоматизация через cron, хранение по правилу 3-2-1. Инструменты — restic для облачного хранилища, BorgBackup для SSH-сервера, rsync для простых файловых задач — зрелые и проверенные. Главное, что отличает надёжный бэкап от иллюзии надёжного бэкапа: регулярная проверка восстановления.

Настроили бэкапы — теперь убедитесь, что сервер работает стабильно. Сравните провайдеров с нативными снапшотами и надёжной инфраструктурой в каталоге VPS free-hosting.ru — более 45 провайдеров с реальными тарифами.