Резервное копирование сайта: файлы + база без сюрпризов
Бэкап нужен не когда-нибудь, а до того, как обновление сломает сайт или кто-то удалит нужную папку. Правильная копия сайта — это всегда две части: файлы и база данных, снятые в один момент. Соберём скрипт, который сам архивирует сайт по расписанию и увозит копию с сервера, чтобы она пережила даже потерю самого VPS.
Содержание
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →Что именно бэкапить
Сайт состоит из двух независимых частей, и без любой из них восстановление невозможно. Первая — файлы: код, шаблоны, загруженные картинки и документы (папка вроде /var/www/site). Вторая — база данных: тексты записей, настройки, пользователи. Резервная копия обязана содержать обе, снятые примерно в один момент.
Отдельно держите в голове правило 3-2-1: три копии, на двух носителях, одна — вне сервера. Копия, лежащая на том же VPS, что и сайт, спасёт от кривого обновления, но не от потери самого сервера. Поэтому финальный шаг — выгрузка архива на удалённое хранилище.
Хорошая новость: у MAATRIX ежедневные снапшоты всей виртуалки делаются на стороне провайдера автоматически — это базовая страховка «из коробки». Собственный скрипт ниже дополняет её гранулярными копиями сайта, которые можно быстро скачать и развернуть где угодно. Комбинация «снапшот всего сервера плюс отдельный дамп сайта» закрывает оба сценария: и полный отказ VPS, и ситуацию, когда нужно откатить одну случайно удалённую папку или таблицу, не трогая остальное.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать VPS с ежедневными бэкапамиДамп базы данных
Базу снимаем через mysqldump — он делает консистентный текстовый дамп, который потом легко импортировать:
mysqldump -u siteuser -p --single-transaction \
mysite | gzip > /var/backups/db-$(date +%F).sql.gz
Флаг --single-transaction снимает дамп InnoDB без блокировки таблиц, а gzip сжимает результат в разы. Чтобы cron не спрашивал пароль, вынесите его в защищённый файл ~/.my.cnf с правами 600:
[client]
user=siteuser
password=СильныйПароль
Тогда команда упрощается до mysqldump --single-transaction mysite | gzip > ... без флага -p.
Архив файлов
Файлы упаковываем tar с сжатием, добавляя дату в имя:
tar -czf /var/backups/files-$(date +%F).tar.gz \
-C /var/www mysite
Ключ -C заходит в /var/www и кладёт в архив папку mysite относительным путём — так восстанавливать удобнее. Для больших медиатек, где важно копировать только изменения, вместо архива подойдёт инкрементальный rsync в отдельный каталог.
Скрипт и автоматизация через cron
Сложим оба шага в один скрипт /usr/local/bin/backup.sh, который заодно удаляет копии старше 14 дней:
#!/bin/bash
set -e
D=$(date +%F)
DIR=/var/backups
mysqldump --single-transaction mysite | gzip > $DIR/db-$D.sql.gz
tar -czf $DIR/files-$D.tar.gz -C /var/www mysite
find $DIR -name '*.gz' -mtime +14 -delete
Сделайте его исполняемым и запланируйте ежедневный запуск ночью через crontab -e:
sudo chmod +x /usr/local/bin/backup.sh
# в crontab -e:
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Теперь каждый день в 3:00 сервер сам снимает копию сайта и чистит старьё, а лог пишется в файл — есть куда посмотреть, если что-то отвалилось.
Увозим копию с сервера
Финальный шаг по правилу 3-2-1 — отправить архивы туда, где они переживут потерю VPS. Проще всего rsync на другой сервер или домашнюю машину по SSH:
rsync -avz /var/backups/ backupuser@storage-host:~/site-backups/
Если используете облачное объектное хранилище (S3-совместимое), удобен rclone — настраивается один раз и копирует в бакет:
rclone copy /var/backups remote:my-site-backups
Добавьте любую из этих команд последней строкой в backup.sh — и копии будут уезжать автоматически.
Главное — проверять восстановление
Бэкап, который ни разу не разворачивали, — это лотерейный билет. Раз в месяц проверяйте копию на тестовой базе и во временном каталоге:
gunzip -c /var/backups/db-2026-07-08.sql.gz | mysql -u siteuser -p test_restore
tar -xzf /var/backups/files-2026-07-08.tar.gz -C /tmp/check
- Снимайте файлы и базу близко по времени — иначе рассинхрон записей и картинок.
- Храните минимум одну копию вне сервера.
- Следите за местом на диске — переполнение остановит и бэкап, и сайт.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать VPS с ежедневными бэкапамиОбсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →Частые вопросы
Достаточно ли снапшотов VM от провайдера?
Снапшоты всей виртуалки — отличная базовая защита от сбоя сервера. Но собственные дампы файлов и базы удобнее для точечного восстановления и переноса на другой сервер.
Как часто делать бэкап?
Для контентных сайтов — раз в сутки. Для магазинов и активных проектов с заказами имеет смысл дамп базы несколько раз в день.
Почему нельзя копировать файлы БД напрямую?
Копирование файлов работающего MySQL может дать повреждённую копию. Используйте mysqldump с --single-transaction — он снимает консистентный дамп.