Введение
Вы открываете сайт, а там белый экран. Или база данных повреждена, и последняя резервная копия — трёхмесячной давности. Знакомо? Большинство владельцев сайтов вспоминают о бэкапах только после серьёзной аварии. А между тем, настройка автоматического резервного копирования — задача на один вечер, и для неё не нужны ни дорогие плагины, ни программист.
В этой статье разберём, как организовать автоматические бэкапы сайта с помощью встроенных инструментов хостинга и простых скриптов. Вы узнаете, как сохранять файлы и базу данных по расписанию, куда складывать копии и как быстро восстановить сайт в случае беды. Всё — своими руками, без лишних затрат.
Сразу оговорюсь: метод подходит для сайтов на виртуальном хостинге или VPS с доступом по SSH. Если у вас конструктор вроде Tilda или Wix, резервное копирование там встроено и настраивается в пару кликов. Но для обычных сайтов на WordPress, Joomla или самописных движках инструкция ниже — то, что нужно.
Почему не плагины?
Плагины резервного копирования вроде UpdraftPlus или BackWPup популярны, но у них есть минусы. Во-первых, они работают внутри самого сайта: если сайт упал, то и плагин может не сработать. Во-вторых, они создают нагрузку на сервер во время создания копии — на слабых хостингах это может привести к таймаутам. В-третьих, бесплатные версии часто ограничены по объёму или расписанию.
Прямое копирование файлов и базы данных через cron и системные утилиты лишено этих недостатков. Вы контролируете процесс полностью, а копии хранятся отдельно от сайта, что критически важно при взломе или заражении.
Что нужно для настройки
Для реализации автоматического бэкапа вам понадобятся:
- Доступ к панели управления хостингом (cPanel, ISPmanager, Plesk или аналог)
- Возможность создавать задания cron (обычно есть в любой панели)
- Доступ по SSH (желательно, но можно обойтись без него)
- Место для хранения копий: отдельная папка на сервере, внешний FTP или облако
Если чего-то из этого нет — например, SSH отключён, — не беда. В панели управления можно запускать команды через «Планировщик заданий» с тем же эффектом.
Шаг 1. Резервное копирование файлов
Файлы сайта — это всё, что лежит в корневой директории: движок, темы, плагины, загруженные картинки. Обычно это папка public_html, www или htdocs. Чтобы сделать копию, нужно упаковать её в архив. Для этого используем утилиту tar, которая есть почти на всех Linux-серверах.
Команда для создания архива:
tar -czf /home/user/backups/site-files-$(date +\%Y\%m\%d).tar.gz -C /home/user/public_html .
Разберём:
tar -czf— создать сжатый gzip архив/home/user/backups/...— путь, куда сохранить архив (замените на свой)$(date +\%Y\%m\%d)— подставит текущую дату, чтобы архивы не перезаписывались-C /home/user/public_html .— перейти в папку сайта и заархивировать всё её содержимое
Если сайт большой (больше 1–2 ГБ), лучше исключить ненужное: кэш, временные файлы. Например, для WordPress можно добавить параметр --exclude:
tar -czf /home/user/backups/site-files-$(date +\%Y\%m\%d).tar.gz --exclude='wp-content/cache' --exclude='wp-content/updraft' -C /home/user/public_html .
После выполнения в папке backups появится архив с файлами. Проверьте его размер — он должен быть меньше размера сайта из-за сжатия. В среднем сжатие уменьшает объём на 40–60%.
Шаг 2. Резервное копирование базы данных
База данных хранит контент: статьи, настройки, пользователей. Файлы без базы — просто каркас. Поэтому копировать нужно и то, и другое. Для дампа MySQL используется утилита mysqldump.
Команда:
mysqldump -u db_user -p'password' db_name > /home/user/backups/db-$(date +\%Y\%m\%d).sql
Замените db_user, password и db_name на свои данные доступа к базе. Они обычно указаны в конфигурационном файле сайта (например, wp-config.php для WordPress).
Чтобы сэкономить место, можно сразу сжимать дамп:
mysqldump -u db_user -p'password' db_name | gzip > /home/user/backups/db-$(date +\%Y\%m\%d).sql.gz
Для больших баз (от 500 МБ) дамп может занять несколько минут. Это нормально, главное — не прерывать процесс.
Шаг 3. Автоматизация через cron
Теперь нужно, чтобы эти команды выполнялись сами по расписанию. В панели хостинга найдите раздел «Планировщик заданий» или «Cron». Создайте новое задание и укажите:
- Интервал: ежедневно, в удобное время (например, в 3:00 ночи, когда сайт наименее нагружен)
- Команду: сначала создание архива файлов, затем дамп базы. Можно объединить в одну строку через
&&:
tar -czf /home/user/backups/site-files-$(date +\%Y\%m\%d).tar.gz -C /home/user/public_html . && mysqldump -u db_user -p'password' db_name | gzip > /home/user/backups/db-$(date +\%Y\%m\%d).sql.gz
Если боитесь ошибиться, создайте два отдельных задания с разницей в 10–15 минут.
Важно: проверьте, что cron-задание действительно выполняется. Для этого после первого запуска загляните в папку backups — там должны появиться свежие файлы с сегодняшней датой.
Шаг 4. Хранение копий вне сервера
Хранить бэкапы на том же сервере, где работает сайт, рискованно: если сервер выйдет из строя или его взломают, копии пропадут вместе с сайтом. Поэтому обязательно настройте выгрузку архивов во внешнее хранилище. Варианты:
- FTP другого хостинга — подойдёт любой бесплатный или дешёвый аккаунт.
- Облачные диски — Google Drive, Яндекс.Диск, Dropbox. Можно использовать утилиту
rcloneдля автоматической синхронизации. - Специализированные сервисы — например, S3-совместимые хранилища (Amazon S3, Backblaze B2 и др.).
Проще всего — rclone. Установите его на сервер, настройте подключение к облаку (инструкции есть на официальном сайте), а затем добавьте в cron команду:
rclone copy /home/user/backups remote:backups --include "*.tar.gz" --include "*.sql.gz"
Эта команда скопирует все свежие архивы в облако. Можно также добавить --delete-after, чтобы удалять старые копии после загрузки.
Шаг 5. Ротация и очистка старых копий
Если не удалять старые архивы, место на диске быстро закончится. Настройте автоматическое удаление копий старше, например, 7 дней. Для этого в cron добавьте команду:
find /home/user/backups -type f -mtime +7 -delete
Она удалит все файлы в папке backups, изменённые более 7 дней назад. Можно настроить и более хитрую ротацию: хранить ежедневные копии за последнюю неделю, еженедельные за месяц, ежемесячные за год. Но для большинства сайтов достаточно 7–10 ежедневных копий.
Пример из практики: у клиента на хостинге с диском 20 ГБ сайт занимал 5 ГБ, а бэкапы без ротации за месяц съели всё свободное место. После настройки хранения только 5 последних копий проблема ушла, а диска стало хватать с запасом.
Шаг 6. Проверка и восстановление
Бэкап, который нельзя восстановить, — бесполезен. Раз в месяц проверяйте, что архивы не битые и база импортируется. Для проверки архива файлов выполните:
tar -tzf /home/user/backups/site-files-20240101.tar.gz | head
Если команда выводит список файлов без ошибок — архив цел. Для проверки SQL-дампа можно импортировать его во временную базу:
gunzip < /home/user/backups/db-20240101.sql.gz | mysql -u db_user -p'password' temp_db
Только не забудьте предварительно создать пустую базу temp_db.
Восстановление сайта из бэкапа — это обратный процесс: распаковать архив файлов в корень сайта и импортировать базу. Подробно останавливаться не буду, но главное — не паниковать и следовать инструкции.
Часто задаваемые вопросы
Как часто нужно делать резервные копии?
Оптимально — ежедневно. Если сайт обновляется редко (раз в неделю), можно делать копии раз в 3 дня. Но ежедневный бэкап — стандарт для большинства проектов.
Что делать, если на хостинге нет cron?
Почти на всех современных хостингах cron есть. Если вдруг нет, можно использовать внешние сервисы-планировщики, которые дёргают скрипт по URL. Но это менее надёжно.
Можно ли хранить бэкапы в том же аккаунте, но в другой папке?
Можно, но это не защитит от потери всего сервера. Лучше выгружать копии наружу — на облако или другой хостинг.
Сколько места занимают бэкапы?
Зависит от размера сайта и сжатия. В среднем, архив файлов и базы сжатый занимает на 50–70% меньше исходного объёма. Например, сайт на 2 ГБ даст бэкап около 800 МБ.
Что важнее: файлы или база данных?
Оба одинаково важны. Без файлов сайт не запустится, без базы — потеряется весь контент. Копируйте и то, и другое.
Заключение
Настроить автоматическое резервное копирование без плагинов и программиста — реально. Потребуется час-два на настройку и немного внимания к деталям. Зато вы получите полный контроль над бэкапами и сэкономите на платных плагинах.
Начните с простого: создайте архив файлов и базы вручную, затем добавьте cron и внешнее хранилище. Проверьте восстановление на тестовом поддомене. И спите спокойно — ваш сайт под защитой.