Бэкап PHP-сайта и MySQL

Бэкап скрипта — дамп MySQL плюс архив файлов (код + загрузки + конфиг). Одно без другого бесполезно: «только файлы» дадут пустые карточки, «только база» — картинки 404. Перед обновлением, сменой хостинга и крупной правкой в админке копия обязательна.

Хранить бэкап на том же диске, что и сайт, — лучше чем ничего, но при смерти VDS умрёт всё вместе. Второй носитель / другой сервер / S3-класс хранилища.

Минимум перед обновлением

1. Дамп всех таблиц нужной базы.
2. Архив document root, особенно каталоги вроде files/, upload/.
3. Отдельно сохранить конфиг с доступами (он может перезатереться при распаковке нового релиза).
4. Проверить: архив открывается, дамп не нулевой длины, импорт на тестовую БД проходит.

Обновление без затирания пользовательского: поддержка и обновления.

Дамп MySQL

mysqldump -u user -p --single-transaction --routines dbname > dump.sql

--single-transaction удобен для InnoDB. На shared — экспорт из phpMyAdmin или кнопка бэкапа в панели Beget/Timeweb/ISPmanager. Большие базы через веб-интерфейс часто обрываются по таймауту — тогда только SSH/CLI.

Кодировка utf8mb4. Подробнее про перенос дампа: миграция MySQL.

Файлы

tar -czf site-$(date +%F).tar.gz /var/www/site

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

Права после восстановления выровняйте: chmod.

Что считать проверкой

«Файл лежит в папке backups» — ещё не проверка. Проверка: развернуть на копии хоста или в отдельную базу + папку, открыть главную и админку. Раз в квартал достаточно, если боитесь забыть. После первого же провального restore спасибо себе скажете.

Расписание

• Ежедневный дамп БД (ночь).
• Файлы — ежедневно или хотя бы загрузки ежедневно, код — после изменений.
• Хранить несколько точек: 7 дней + один недельный.

Cron для скрипта продукта и cron для бэкапа — разные задачи. Про расписание PHP: cron. Следить, что диск не забит старыми архивами: мониторинг.

Перед переносом

Переезд на другой сервер начинается с бэкапа, не с удаления DNS. Порядок: перенос скрипта. Локальная копия на MicroServer тоже годится как учебный restore: локальный сервер, импорт — phpMyAdmin.

Снимки VDS

Снапшот гипервизора полезен, но не заменяет логический дамп. Снапшот откатывает всю машину; точечно вернуть одну таблицу из него больнее. Держите оба уровня, если данные дорогие.

Firewall и доступ к серверу бэкапов: firewall, VDS.

Если уже «сломали без копии»

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

Что именно класть в архив файлов

Обязательно: PHP-код (если не восстанавливаете из git), каталоги загрузок, конфиг с доступами, .htaccess если используете Apache, шаблоны если правили. Можно исключить: cache, временные thumbnails если они пересобираются, vendor при условии что умеете composer install на целевой машине.

На shared без SSH vendor чаще кладут в архив. На VDS с Composer — как удобнее команде. Про Composer: локально, на сервере тот же принцип.

Имена и ротация

Имя файла с датой спасает: board-2026-10-06.sql, board-files-2026-10-06.tar.gz. Храните хотя бы неделю ежедневных и один «хороший» снимок после удачного релиза. Удаляйте старьё осознанно — иначе диск VDS стопнется ночью, и мониторинг начнёт орать уже по другой причине: мониторинг.

Восстановление по шагам

1. Развернуть файлы в каталог сайта (или рядом и переключить root).
2. Создать пустую базу utf8mb4, импортировать дамп — миграция.
3. Прописать доступы в конфиге.
4. Выровнять владельца и права — chmod.
5. Проверить главную, админку, одну карточку с картинкой.

Если картинки 404 — в архив не попал upload либо URL в базе смотрит на другой домен. После смены домена обновите настройки сайта. Перенос целиком: перенос скрипта.

Бэкап только через панель хостера

Кнопка «бэкап» на Beget/Timeweb/ISPmanager удобна. Минусы: не всегда понятно, есть ли внутри files/, как быстро скачать, сколько точек хранится. Раз в месяц скачивайте архив к себе. Не надейтесь, что «у них точно есть» в день пожара — читайте срок хранения тарифа заранее.

Согласованность файлов и базы

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

Шифрование и хранение

Дамп = все пользователи и иногда токены. Храните в закрытом каталоге, на шифрованном диске, не в публичном www/backups отдаваемом Nginx. Случайно открытый каталог бэкапов — подарок сканеру. На VDS закройте путь в nginx и правами FS. Firewall сам по себе файл не спрячет: firewall.

Локальная копия на MicroServer для тренировки restore полезна: локальный сервер, импорт — phpMyAdmin. Установка с нуля после тотальной потери, когда бэкапа нет — уже установка и смирение с потерей данных.

Не храните единственную копию бэкапа в /var/www/site/backup внутри document root — Nginx может начать отдавать sql кому угодно, если location кривой. Вынесите за пределы root или закройте deny all. Имена файлов с датой и размером после копирования сверяйте глазами: нулевой dump.sql после failed cron — не бэкап. Добавьте в мониторинг проверку «файл сегодняшней даты существует и больше N байт»: мониторинг. Перед обновлением продукта бэкап обязателен даже если «маленький патч»: обновления. Перенос на новый сервер начинается с той же дисциплины: перенос, дамп. На VDS не забудьте права после restore: chmod.