Резервные копии небольшого PHP-сайта: что важно не забыть

Резервная копия сайта — это не архив “на всякий случай”. Она нужна в момент, когда что-то уже случилось: неудачное обновление, ошибка в базе, удалённые файлы, взлом, сбой диска или перенос на другой сервер. В этот момент выясняется, что одного дампа базы мало, а архив uploads никто не делал.

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

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

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

• дамп базы данных;
• директории загрузок: uploads, images, storage;
• локальные конфиги без публикации наружу;
• composer.json и composer.lock;
• список cron-задач;
• конфиги nginx или Apache, если есть доступ;
• инструкцию по восстановлению.

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

Дамп базы

Для MySQL или MariaDB стандартный вариант — mysqldump. Важно сохранять кодировку и не забывать routines, если проект использует процедуры или функции.

mysqldump --single-transaction --routines --triggers \
    -u user -p database > backup.sql

Для больших баз дамп лучше сразу сжимать:

mysqldump --single-transaction -u user -p database | gzip > backup.sql.gz

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

Файлы загрузок

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

tar -czf uploads.tar.gz web/uploads

Если uploads большой, можно использовать rsync на отдельное хранилище:

rsync -av --delete web/uploads/ backup@example:/backups/site/uploads/

Ключ --delete нужно использовать осторожно. Он удаляет на стороне бэкапа то, чего уже нет в исходной папке. Это удобно для зеркала, но плохо защищает от случайного массового удаления.

Конфиги и секреты

Конфиги нужны для восстановления, но хранить их нужно аккуратно. В них могут быть пароли базы, SMTP, API-ключи и токены. Такие файлы нельзя складывать в публичную директорию или отправлять в общий архив без ограничений доступа.

tar -czf config.tar.gz config params .env

Если в проекте секреты уже вынесены в переменные окружения, нужно сохранить инструкцию, какие переменные требуются.

Cron и фоновые процессы

После восстановления сайта часто забывают cron. В результате сайт открывается, но не обновляет данные, не отправляет уведомления и не выполняет регулярные задачи.

crontab -l > crontab.txt

Если используются systemd-сервисы для очередей, стоит сохранить их названия и содержимое unit-файлов.

systemctl list-units | grep queue
systemctl cat yii-queue.service

Автоматизация

Простой shell-скрипт лучше, чем ручное копирование раз в несколько месяцев. Но скрипт должен писать лог и завершаться с ошибкой, если один из шагов не выполнен.

#!/bin/bash
set -e

DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR=/backups/site/$DATE

mkdir -p "$BACKUP_DIR"

mysqldump --single-transaction -u user -p'password' database | gzip > "$BACKUP_DIR/db.sql.gz"
tar -czf "$BACKUP_DIR/uploads.tar.gz" /var/www/site.ru/web/uploads
crontab -l > "$BACKUP_DIR/crontab.txt"

echo "Backup completed: $BACKUP_DIR"

Пароль в скрипте — не лучший вариант. На практике лучше использовать отдельный конфиг MySQL с ограниченными правами и закрытым доступом к файлу.

Проверка восстановления

Бэкап считается рабочим только после тестового восстановления. Хотя бы раз нужно развернуть копию на тестовом сервере или локально и пройти основные сценарии.

1. Создать пустую базу.
2. Импортировать дамп.
3. Развернуть файлы uploads.
4. Настроить локальные конфиги.
5. Выполнить composer install.
6. Открыть сайт и админку.
7. Проверить несколько загруженных файлов.

gunzip < db.sql.gz | mysql -u user -p database

Где хранить копии

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

• ежедневные копии за последние несколько дней;
• еженедельные копии за последний месяц;
• отдельная копия перед крупными обновлениями;
• периодическая проверка восстановления.

Бэкапы не должны быть публично доступны по URL. Файлы вида backup.zip в корне сайта — частая и опасная ошибка.

Короткий чек-лист

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

Бэкап не обязан быть сложным. Но он должен быть полным, регулярным и проверенным. Иначе в критический момент окажется, что копия есть только формально, а восстановить по ней сайт нельзя.