Копия, которая лежит на том же сервере, что и данные, не защищает почти ни от чего. Отказ диска, ошибка в команде, взлом, блокировка аккаунта у провайдера — всё это уносит оригинал и копию одновременно. Отдельный сервер для бэкапов в другой стране стоит $6 в месяц и превращает любую из этих аварий из катастрофы в неприятность на пару часов. Разберём, сколько места реально нужно, где его взять, как настроить копирование так, чтобы взломщик не мог удалить копии, и как держать резервную площадку, на которую можно переключиться.
Зачем отдельный сервер, а не папка /backup
Классическое правило резервного копирования — 3-2-1: три копии данных, на двух разных носителях, одна из них в другом месте. Для VPS это переводится просто: рабочие данные на основном сервере, свежая копия там же для быстрого отката, и ещё одна — на отдельной машине в другом дата-центре.
От чего защищает отдельный сервер:
- Отказ железа или инцидент в дата-центре. Редко, но случается, и тогда недоступно всё, что было на площадке.
- Ошибка администратора.
rm -rfне в той папке,DROP TABLEне в той базе, скрипт миграции, который прошёлся по продакшену. - Взлом и шифровальщики. Если злоумышленник получил root на основном сервере, он удалит и локальные копии. Удалённые — только если вы ему это позволили (об этом ниже).
- Проблемы с аккаунтом. Спор с провайдером, ошибка в оплате, блокировка — данные могут стать недоступны на время, которого у бизнеса нет.
Что копировать
- Данные — базы, загруженные пользователями файлы, документы. То, что невозможно восстановить. Приоритет номер один.
- Конфигурация —
/etc/nginx,/etc/php, сертификаты, crontab, правила firewall, файлы.env. Восстановимо, но часами, а без неё система не поднимется. - Код — обычно уже в Git-репозитории, отдельная копия ему не нужна.
Не копируйте кэши, временные файлы, node_modules, логи старше недели. Лишние гигабайты замедляют копирование, и его начинают запускать реже — ровно тогда, когда оно понадобится.
Сколько места нужно
Оценка на пальцах: объём данных × число хранимых версий ÷ коэффициент сжатия и дедупликации. Современные инструменты вроде restic и borg хранят только изменившиеся блоки, поэтому 14 ежедневных версий сайта на 5 ГБ занимают не 70 ГБ, а обычно 7–10 ГБ. Дампы баз данных хорошо сжимаются — в 5–10 раз.
| Что копируете | Объём данных | Хватит тарифа | Цена/мес |
|---|---|---|---|
| 1–3 сайта на CMS, базы до 1 ГБ | до 5 ГБ | Lite, 20 ГБ | $6 |
| Магазин с фото товаров | 5–15 ГБ | Start, 30 ГБ | $10 |
| Несколько проектов с медиа | 15–25 ГБ | Medium, 40 ГБ | $20 |
| Большие файловые архивы | 40–80 ГБ | Elite–Exclusive, 80–100 ГБ | $60–90 |
Если данных больше 100 ГБ, VPS как хранилище становится дорогим — смотрите на объектные хранилища или выделенный сервер с большими дисками. Для типичных сайтов и магазинов хватает Lite или Start.
Где держать копию
Главное правило — не в той же локации, что и основной сервер. Цена во всех 41 странах одинаковая, поэтому выбирать можно по удобству:
| Основной сервер | Резерв | Логика |
|---|---|---|
| Финляндия | Нидерланды или Чехия | Другой дата-центр в ЕС, NVMe, быстрый канал между площадками |
| Нидерланды | Финляндия | То же в обратную сторону |
| Россия | Казахстан или Финляндия | Другая юрисдикция, но близко к аудитории — удобно для резервной площадки |
| Любая европейская | Казахстан | Вне ЕС и вне РФ: защита от регуляторных рисков в одной юрисдикции |
Одно ограничение: если в копии персональные данные россиян, помните о 152-ФЗ — при сборе они должны храниться в РФ. Зарубежная копия допустима как дополнительная, но первичная база должна быть в России. Уточняйте у юриста, как это применимо к вашему случаю.
Lite в Финляндии под бэкапы — $6/мес Lite в Нидерландах — $6/мес
Как настроить: копирование, которое нельзя удалить
Самая частая ошибка — основной сервер сам заливает копии на бэкап-сервер по SSH с полным доступом. Тогда взломщик, получивший root на основном, получает и ключ к бэкапам — и удаляет их первым делом. Есть два правильных варианта.
Вариант 1: бэкап-сервер забирает сам (pull)
Основной сервер ничего никуда не отправляет. Бэкап-сервер по расписанию подключается к нему и забирает данные. Ключ доступа хранится только на бэкап-сервере, и с основного до копий не добраться.
На основном сервере — скрипт, который готовит дамп базы:
#!/bin/sh mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
На бэкап-сервере — cron, который забирает его вместе с файлами:
0 3 * * * rsync -az --delete deploy@MAIN_IP:/var/backups/ /backup/main/db/ 5 3 * * * rsync -az --delete deploy@MAIN_IP:/var/www/ /backup/main/www/
Для хранения нескольких версий поверх rsync используйте rsnapshot — он делает ежедневные и недельные снимки через жёсткие ссылки, почти не расходуя место.
Вариант 2: основной отправляет, но только дописывает (append-only)
Удобнее, когда основных серверов несколько. На бэкап-сервере поднимается restic rest-server с флагом --append-only: клиенты могут добавлять новые снимки, но не могут удалять старые. Очистка по расписанию хранения (restic forget --keep-daily 7 --keep-weekly 4 --prune) запускается только на самом бэкап-сервере.
Сколько версий хранить
Одна последняя копия защищает от отказа железа, но не от порчи данных: если база испортилась вчера, а копия снялась сегодня, вы аккуратно скопировали поломку. Разумный минимум — 7 ежедневных и 4 недельных копии. Для магазина с постоянными заказами дамп базы стоит делать чаще — каждый час или каждые несколько часов: вопрос в том, сколько заказов вы готовы потерять.
Резервная площадка: копия, на которую можно переключиться
Следующий уровень — не просто хранить копию, а держать на втором сервере готовое окружение: тот же веб-сервер, та же версия PHP и базы. Тогда при аварии вы не собираете сервер с нуля, а разворачиваете последнюю копию и меняете DNS. Время восстановления сокращается с дня до часа.
Для этого бэкап-серверу нужно чуть больше ресурсов — обычно Start вместо Lite, чтобы проект на нём хотя бы запустился. Держите DNS-записи с коротким TTL (300 секунд), тогда переключение займёт минуты. Порядок переноса с проверкой через hosts мы расписали в инструкции «Как перенести сайт без простоя» — при аварийном переключении он тот же, только быстрее.
Непроверенный бэкап — это не бэкап
Самая частая беда не в том, что копирования нет, а в том, что оно годами идёт в никуда: архив битый, дамп обрезан на середине, в копию не попала половина каталогов. Узнают об этом в момент аварии.
- Раз в квартал разверните копию на резервном сервере и убедитесь, что проект поднимается. Заодно замерьте, сколько времени это заняло, — эту цифру стоит знать до аварии.
- Каждый день проверяйте, что копия свежая: простой скрипт, который шлёт уведомление, если последнему файлу больше суток. Или подключите мониторинг с такой проверкой.
- Следите за местом на бэкап-сервере: заполненный диск молча останавливает копирование.
Если не хочется собирать всё это самостоятельно — посмотрите страницу резервного копирования.
Коротко
- Копия на том же сервере — не бэкап. Нужен отдельный сервер в другой стране.
- Для сайтов и магазинов хватает Lite за $6 или Start за $10: дедупликация и сжатие экономят место в разы.
- Настраивайте так, чтобы основной сервер не мог удалить копии: pull с бэкап-сервера или append-only.
- Храните 7 ежедневных и 4 недельных версии; базу магазина — чаще.
- Резервная площадка с готовым окружением сокращает восстановление до часа.
- Раз в квартал проверяйте восстановление вживую.