MAATRIX / Блог / Резервное копирование сайта: файлы + база без сюрпризов

Резервное копирование сайта: файлы + база без сюрпризов

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Что именно бэкапить
  2. Дамп базы данных
  3. Архив файлов
  4. Скрипт и автоматизация через cron
  5. Увозим копию с сервера
  6. Главное — проверять восстановление

Что именно бэкапить

['Сайт состоит из двух независимых частей, и без любой из них восстановление невозможно. Первая — файлы: код, шаблоны, загруженные картинки и документы (папка вроде /var/www/site). Вторая — база данных: тексты записей, настройки, пользователи. Резервная копия обязана содержать обе, снятые примерно в один момент.', 'Отдельно держите в голове правило 3-2-1: три копии, на двух носителях, одна — вне сервера. Копия, лежащая на том же VPS, что и сайт, спасёт от кривого обновления, но не от потери самого сервера. Поэтому финальный шаг — выгрузка архива на удалённое хранилище.', 'Хорошая новость: у MAATRIX ежедневные снапшоты всей виртуалки делаются на стороне провайдера автоматически — это базовая страховка «из коробки». Собственный скрипт ниже дополняет её гранулярными копиями сайта, которые можно быстро скачать и развернуть где угодно. Комбинация «снапшот всего сервера плюс отдельный дамп сайта» закрывает оба сценария: и полный отказ VPS, и ситуацию, когда нужно откатить одну случайно удалённую папку или таблицу, не трогая остальное.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS с ежедневными бэкапами

Дамп базы данных

['Базу снимаем через mysqldump — он делает консистентный текстовый дамп, который потом легко импортировать:', '
mysqldump -u siteuser -p --single-transaction \\\n  mysite | gzip > /var/backups/db-$(date +%F).sql.gz
', 'Флаг --single-transaction снимает дамп InnoDB без блокировки таблиц, а gzip сжимает результат в разы. Чтобы cron не спрашивал пароль, вынесите его в защищённый файл ~/.my.cnf с правами 600:', '
[client]\nuser=siteuser\npassword=СильныйПароль
', 'Тогда команда упрощается до mysqldump --single-transaction mysite | gzip > ... без флага -p.']

Архив файлов

['Файлы упаковываем tar с сжатием, добавляя дату в имя:', '
tar -czf /var/backups/files-$(date +%F).tar.gz \\\n  -C /var/www mysite
', 'Ключ -C заходит в /var/www и кладёт в архив папку mysite относительным путём — так восстанавливать удобнее. Для больших медиатек, где важно копировать только изменения, вместо архива подойдёт инкрементальный rsync в отдельный каталог.']

Скрипт и автоматизация через cron

['Сложим оба шага в один скрипт /usr/local/bin/backup.sh, который заодно удаляет копии старше 14 дней:', "
#!/bin/bash\nset -e\nD=$(date +%F)\nDIR=/var/backups\nmysqldump --single-transaction mysite | gzip > $DIR/db-$D.sql.gz\ntar -czf $DIR/files-$D.tar.gz -C /var/www mysite\nfind $DIR -name '*.gz' -mtime +14 -delete
", 'Сделайте его исполняемым и запланируйте ежедневный запуск ночью через crontab -e:', '
sudo chmod +x /usr/local/bin/backup.sh\n# в crontab -e:\n0 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\ntar -xzf /var/backups/files-2026-07-08.tar.gz -C /tmp/check
', '
  • Снимайте файлы и базу близко по времени — иначе рассинхрон записей и картинок.
  • Храните минимум одну копию вне сервера.
  • Следите за местом на диске — переполнение остановит и бэкап, и сайт.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS с ежедневными бэкапами

Частые вопросы

Достаточно ли снапшотов VM от провайдера?

Снапшоты всей виртуалки — отличная базовая защита от сбоя сервера. Но собственные дампы файлов и базы удобнее для точечного восстановления и переноса на другой сервер.

Как часто делать бэкап?

Для контентных сайтов — раз в сутки. Для магазинов и активных проектов с заказами имеет смысл дамп базы несколько раз в день.

Почему нельзя копировать файлы БД напрямую?

Копирование файлов работающего MySQL может дать повреждённую копию. Используйте mysqldump с --single-transaction — он снимает консистентный дамп.

Читайте также