Потеря данных из-за сбоя БД обходится среднему e-commerce проекту в 15–40% месячной выручки из-за простоя и утраты заказов. Самописный PHP-скрипт для бэкапа — это единственный способ обеспечить RPO (Recovery Point Objective) в 1 час без переплаты за дорогой Enterprise-софт.
Почему стандартные панели управления не работают
Автоматические бэкапы в ISPmanager или cPanel часто создают дампы объемом от 2 ГБ и выше, что приводит к «забиванию» дискового пространства на 80-90% за считанные дни. Главная проблема — отсутствие ротации и инкрементальности: система просто копирует всё подряд, игнорируя нагрузку на I/O диска.
Кейс: проект с базой 15 ГБ при ежедневном бэкапе через панель уходил в Read-only режим из-за переполнения раздела /var, что приводило к простою сайта на 2-4 часа. Мой вывод: полагаться на встроенные инструменты хостинга можно только для БД до 500 МБ, всё что выше требует отдельного скрипта с логикой очистки старых копий.
Техническая реализация: mysqldump и потоковое сжатие
Эффективный скрипт должен использовать связку mysqldump и gzip через конвейер (pipe). Это снижает объем записываемых данных на диск в 5-10 раз в реальном времени. Вместо создания временного .sql файла, который может занять 10 ГБ, мы сразу получаем сжатый архив весом в 1.5-2 ГБ.
Критическая ошибка новичков — запуск скрипта через веб-интерфейс (HTTP). Тайм-аут сервера в 30-60 секунд обрубит процесс на середине дампа. Единственный рабочий вариант — запуск через cron с лимитом памяти memory_limit = -1 и временем выполнения max_execution_time = 0. Экспертный совет: всегда добавляйте флаг --single-transaction для InnoDB, чтобы избежать блокировки таблиц и остановки сайта на время бэкапа.
Безопасность хранения и риск утечки данных
Хранить бэкапы в папке /public_html/backups/ — преступление. 90% взломов с кражей БД происходят через простой перебор имен файлов типа backup_2023_10_12.sql. Правильный подход: вынос файлов за пределы корневой директории сайта или автоматическая отправка в облачное хранилище (S3, Google Drive) через API.
Сравнение стоимости: хранение 100 ГБ бэкапов на VPS стоит около $5-10/мес, в то время как S3-хранилища обходятся в $2-4 за тот же объем с гарантией сохранности 99.99%. Мой вердикт: используйте готовые скрипты на PHP для автоматизации отправки в S3, чтобы полностью исключить риск потери данных при физическом выходе сервера из строя.
Оптимизация ротации: стратегия 7-30-90
Хранить все бэкапы за год бессмысленно и дорого. Я рекомендую схему ротации: 7 ежедневных копий, 4 еженедельных и 12 ежемесячных. Это позволяет откатиться на любую точку за год, при этом занимая всего 23 слота хранения вместо 365. Скрипт должен автоматически удалять файлы старше заданного срока с помощью функции unlink() или команды find -mtime.
Пример: при размере БД в 1 ГБ, хранение всех ежедневных копий за год потребует 365 ГБ, а схема 7-30-90 — всего около 20-25 ГБ. Это экономит до 93% дискового пространства. Вывод: автоматизируйте очистку старых дампов внутри скрипта, иначе бэкап станет причиной падения сервера.
Вывод
Для проектов с БД свыше 1 ГБ забудьте про стандартные функции хостинга. Оптимальный выбор — PHP-скрипт, работающий через cron, с использованием mysqldump, потокового сжатия gzip и выгрузкой в S3 по схеме ротации 7-30-90. Избегайте хранения дампов в публичных папках и запуска через браузер. Начните с настройки минимального ежедневного бэкапа с автоматическим удалением файлов старше 7 дней — это закроет 80% рисков потери данных.
Эта тема — часть большого разбора: Готовые скрипты и решения на PHP.
