Резервная копия нужна, чтобы сайт вернулся в работу после сбоя. На VPS этот процесс никто не настроит за вас: панель хостинга дампов не делает. Дальше разберём, что копировать, по какому расписанию, где хранить архивы и как проверить, что они восстанавливаются. Инструкция рассчитана на обычный сайт на Linux с MySQL или MariaDB, без привязки к конкретной CMS.
Что именно нужно бэкапить на VPS
Начните со списка. Восстановить файлы без базы — значит вернуть пустой сайт с картинками, но без товаров, заказов и пользователей. Бывает и наоборот.
- Файлы сайта: движок, темы, шаблоны, плагины, загруженные изображения и документы.
- База данных: товары, заказы, учётные записи, настройки, сообщения из форм.
- Конфигурация окружения: настройки nginx или Apache, пулы php-fpm, файлы с доступами.
- Задачи cron и systemd-таймеры. Без них часть сценариев после переезда просто не запустится.
- SSL-сертификаты и ключи. Автопродление настроить проще, но копия лишней не будет.
- Почтовые ящики и правила фильтрации, если почта живёт на том же сервере.
Дальше разделите данные по частоте изменений. Заказы и товары обновляются каждый день, конфигурация веб-сервера — раз в несколько месяцев. Для первого нужен ежедневный цикл, для второго хватит ежемесячного. Так вы не тратите диск на копии того, что не менялось.
Какую схему выбрать: полный, инкрементный или дифференциальный бэкап
| Схема | Что попадает в копию | Когда подходит | На что смотреть |
|---|---|---|---|
| Полный бэкап | Все файлы и база целиком | Небольшие сайты, разовая копия перед обновлением | Долго и много места |
| Инкрементный | Только изменения с момента прошлой копии | Каталоги с большим объёмом вложений | Восстановление зависит от всей цепочки копий |
| Дифференциальный | Изменения с последнего полного бэкапа | Компромисс по размеру и скорости восстановления | Объём растёт до следующего полного копирования |
| Реплика базы данных | Постоянная копия данных в реальном времени | Магазины, где простой стоит дорого | Реплика повторяет ошибку в данных, архивный дамп всё равно нужен |
На практике схемы совмещают: раз в неделю снимают полный архив, между ними — инкременты, а базу дампят отдельно каждый день. Реплика дополняет этот набор, но не заменяет его.
Как настроить автоматический бэкап базы и файлов
База данных
Базовый вариант — mysqldump в cron. Для живой базы обязательны флаги --single-transaction и --quick, иначе дамп может получиться битым: данные меняются, пока вы их читаете. Добавьте --routines и --triggers, иначе хранимые процедуры не попадут в архив.
Пароль не держите в тексте скрипта. Положите доступы в отдельный файл с правами 600 и передавайте его через --defaults-extra-file. Дамп упаковывайте в gzip и называйте с датой — так проще найти нужную копию и настроить удаление старых по возрасту.
Когда база измеряется десятками гигабайт, логический дамп идёт часами. Тогда смотрят на физическое копирование или на реплику, а дамп оставляют как вторую линию.
Файлы сайта
Для небольших каталогов хватит tar с архивом. Для больших лучше подходят инструменты с дедупликацией: они хранят изменённые блоки, а не файлы целиком, и недельные копии не разрастаются до размера диска. Перед архивацией исключайте кеш, временные файлы и логи — они весят много, а восстановить их нечем.
Расписание
Рабочая связка выглядит так: ежедневно ночью дамп базы, раз в неделю полный архив файлов, раз в месяц копия на внешний носитель. Перед крупным обновлением CMS или плагинов снимайте копию вручную. Подробнее про настройку цикла и хранение архивов — в разборе как организовать резервное копирование на VPS.
Где хранить копии, чтобы сервер не остался единственной точкой отказа
Копия на том же диске, где лежит сайт, спасает от случайного удаления файла. От отказа сервера она не спасает. Вариантов хранения несколько:
- Отдельный диск на том же VPS — быстро, но уязвимо к потере самого сервера.
- Второй сервер у другого провайдера — защищает от сбоя площадки.
- Объектное S3-совместимое хранилище — дёшево при росте объёмов, удобно для автоматизации.
- Офисный NAS — медленнее, зато копия физически под вашим контролем.
Ориентир — правило трёх копий: три экземпляра данных, на двух разных носителях, один из них вне основной площадки. Если копии уезжают на отдельный сервер, ограничьте к нему доступ: ключи вместо паролей, нестандартный порт, настроенный файрвол на VPS и шифрование самих архивов.
Отдельный случай — сайты на CMS со своим хостингом. У хостинга для 1С-Битрикс автоматические бэкапы и защита от DDoS входят в тариф (1С-Битрикс), но это копии в инфраструктуре провайдера. Свой архив на внешнем носителе всё равно пригодится. Если часть сервисов пока живёт в зарубежных облаках, держите под рукой разбор про смену зарубежной CRM на белорусские облачные сервисы — логика переезда похожа.
Как проверить, что бэкап восстановится
Архив без проверки — это надежда, а не резерв. Раз в квартал поднимайте тестовый сервер и разворачивайте на нём копию: сначала базу, потом файлы, потом конфигурацию. Отдельно проверяйте контрольные суммы архивов, чтобы поймать повреждение до аварии.
Быстро собрать окружение помогает BitrixVM: готовый стек для 1С-Битрикс разворачивается на чистом сервере за считанные минуты (Aspro). Для других CMS время на подготовку сервера сопоставимо, если под рукой есть скрипт установки.
Типичные ошибки
- Хранить копии на том же диске, что и сайт.
- Ни разу не пробовать восстановление.
- Снимать дамп живой базы без транзакций — получается битый файл, который «успешно» создался.
- Оставлять пароль от базы в открытом виде в cron или скрипте.
- Не следить за свободным местом: диск заполняется, задача падает молча.
- Складывать архивы в папку, доступную по HTTP.
- Настроить уведомления только об успехе и не заметить, что задание не запускалось три недели.
3 шага, с которых стоит начать на этой неделе:
- Выпишите, что именно восстанавливаете: файлы, база, конфиги, cron, почта.
- Настройте ежедневный дамп базы и недельный архив файлов, сразу с выгрузкой на внешнее хранилище.
- Поднимите тестовый сервер и восстановите из копии одну базу целиком — до того, как это понадобится в аварийном режиме.
