Как сделать бэкап сайта на VPS: файлы, база данных, расписание и восстановление

Бэкап сайта на VPS — это не один архив в папке /backup. Нормальная backup strategy отвечает на пять вопросов: что бэкапить, куда складывать, как часто запускать, сколько хранить и как проверять восстановление.

Для небольшого сайта минимальный набор резервных копий обычно включает:

• Файлы сайта;
• Базу данных;
• uploads и пользовательские файлы;
• Конфиги приложения;
• Конфиги веб-сервера;
• cron-задачи;
• SSL-сертификаты или инструкции по их восстановлению;
• отдельную копию за пределами основного VPS.

Если речь о WordPress, одного архива с файлами недостаточно. Нужны минимум две части: файлы WordPress и MySQL dump базы данных. В файлах лежат темы, плагины, uploads и код сайта. В базе — записи, страницы, пользователи, настройки, заказы WooCommerce и большая часть динамического контента.

Хранить бэкап только на том же VPS опасно. Если сервер будет удалён, диск сломается, аккаунт заблокируют или злоумышленник получит доступ к системе, локальные бэкапы могут исчезнуть вместе с сайтом. Поэтому рабочая схема обычно сочетает локальную копию для быстрого восстановления и удалённое хранилище для аварийного случая.

Snapshot VPS полезен, но не заменяет обычный бэкап. Snapshot хорошо помогает быстро откатить весь сервер после неудачного обновления, но он не всегда удобен для восстановления отдельной базы, одного каталога uploads или конкретной версии сайта, а также не предназначен для долгосрочного хранения.

Для удобства составили таблицу:

Расписание можно настроить через cron: например, каждый день делать MySQL dump, архивировать нужные каталоги и отправлять копию в object storage или на отдельный backup-сервер. При этом лучше, чтобы бэкап-сервер забирал резервную копию, а не сервер клал на него).

Главная ошибка — думать, что бэкап существует, пока не случилась авария. Архив может оказаться пустым, база может не восстановиться, права файлов могут сломаться, а скрипт бэкапа мог перестать работать месяц назад.

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

Если в архиве есть персональные данные, заказы, email-адреса, документы или пользовательские файлы, бэкап нужно защищать: ограничивать доступ, шифровать архивы и не складывать их в публичные директории сайта.

Хорошая backup strategy не делает сайт неуязвимым, но превращает аварию из катастрофы в управляемую задачу: восстановить файлы, импортировать базу, проверить конфиги и вернуть сайт в работу.

Что должно входить в backup strategy

Backup strategy — это не просто команда, которая создаёт архив. Это понятная схема, по которой сайт можно восстановить после ошибки, взлома, удаления файлов, сбоя диска или неудачного обновления.

Для небольшого сайта стратегия должна отвечать на пять вопросов: что именно сохранять, где хранить копии, как часто их делать, сколько держать старые версии и как проверять, что восстановление действительно работает.

Что бэкапить

В первую очередь нужно бэкапить всё, без чего сайт нельзя вернуть в рабочее состояние. Для статического сайта это могут быть только файлы. Для WordPress, интернет-магазина, форума или личного кабинета обязательно нужна ещё и база данных.

Минимальный набор обычно включает:

• Файлы сайта;
• Базу данных;
• Загруженные изображения и документы;
• Конфиги приложения;
• Конфиги веб-сервера;
• cron-задачи;
• Важные .env-файлы;
• Инструкции по восстановлению SSL-сертификатов;
• Список установленных сервисов и версий.

Для WordPress особенно важно не забыть базу данных. В файлах лежат темы, плагины, uploads и ядро WordPress. Но записи, страницы, пользователи, настройки, комментарии, заказы WooCommerce и многие данные плагинов находятся именно в базе.

Если сделать только архив файлов, сайт после аварии может открыться технически, но без контента, настроек и заказов. Поэтому файлы и база должны идти вместе как две части одного бэкапа.

Когда понятно, что именно нужно сохранять, следующий вопрос — где эти копии будут лежать. От места хранения зависит, переживут ли бэкапы реальную аварию.

Куда складывать бэкапы

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

Но такой вариант нельзя считать полноценной защитой. Если VPS удалят, диск сломается, аккаунт заблокируют или злоумышленник получит доступ к серверу, локальные бэкапы могут исчезнуть вместе с сайтом.

Поэтому лучше использовать несколько уровней хранения:

Для небольшого сайта рабочая схема может быть такой: короткий локальный бэкап на VPS для быстрого восстановления и отдельная удалённая копия в object storage или на backup-сервере.

Идеально, если одно из мест хранения бэкапа будет у другого провайдера, или даже в локальном офисе, на случай глобальной аварии.

Если в бэкапах есть персональные данные, заказы, email-адреса или документы пользователей, архивы нужно защищать: ограничивать доступ, не хранить их в публичной директории сайта и при необходимости шифровать.

После выбора места хранения нужно определить частоту. Один сайт меняется раз в месяц, другой принимает заказы каждый день, и расписание бэкапов для них не должно быть одинаковым.

Как часто делать резервные копии

Частота бэкапов зависит от того, как часто меняются данные. Чем чаще на сайте появляются новые записи, заказы, пользователи, комментарии или загруженные файлы, тем чаще нужно делать резервные копии.

Для небольшого WordPress-сайта можно использовать как отправную точку такую базовую схему:

Если сайт — это блог, где новые материалы выходят редко, ежедневного бэкапа базы и еженедельного бэкапа файлов обычно достаточно. Если это интернет-магазин, база должна сохраняться чаще, потому что в ней находятся заказы, клиенты, статусы оплат и настройки WooCommerce.

Перед обновлением WordPress, темы, плагинов, PHP, базы данных или веб-сервера лучше делать отдельный бэкап вручную. Такой бэкап нужен не вместо расписания, а как дополнительная точка отката перед рискованным действием.

Для правильной и корректной оценки частоты резервного копирования, необходимо подумать о показателе RPO (Recovery Point Objective) - буквально, данные за какой промежуток времени могут быть безвозвратно потеряны, исходя из этого частота может быть увеличена, или вообще переделана вся стратегия резервного копирования.

Но частота — только половина стратегии. Если хранить все копии бесконечно, место быстро закончится. Если хранить только одну последнюю копию, можно перезаписать хороший бэкап уже после поломки.

Сколько хранить бэкапы

Срок хранения бэкапов должен учитывать два сценария. Первый — авария обнаружилась сразу, и нужно восстановить вчерашнюю версию. Второй — проблема появилась давно, но заметили её только через несколько дней или недель.

Например, сайт могли взломать сегодня, а обнаружить вредоносный код только через неделю. Если хранится только последняя копия, она уже может содержать заражённые файлы. Или важные данные, которые были удалены давно внезапно понадобились.

Для небольшого сайта можно использовать простую схему ротации:

• Ежедневные копии — хранить 7–14 дней;
• Недельные копии — хранить 4–8 недель;
• Месячные копии — хранить 3–6 месяцев;
• Отдельные бэкапы перед крупными изменениями — хранить до завершения проверки.

Эта схема не универсальна, но она лучше, чем один архив backup-latest.tar.gz, который постоянно перезаписывается.

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

Когда расписание и срок хранения определены, остаётся главный вопрос: можно ли из этих архивов действительно восстановить сайт.

Как проверять восстановление

Бэкап нельзя считать рабочим, пока не проверено восстановление. Архив может создаваться без ошибок, но внутри не окажется базы, uploads, нужных конфигов или корректных прав доступа.

Проверять restore лучше не на боевом сайте, а на тестовом окружении: временном домене, поддомене, отдельной директории или отдельном VPS.

Минимальная проверка восстановления выглядит так:

1. Распаковать файлы сайта.
2. Создать новую базу данных.
3. Импортировать SQL dump.
4. Проверить конфиг подключения к базе.
5. Настроить права на файлы и каталоги.
6. Открыть сайт в браузере.
7. Проверить админку, формы, изображения и ключевые страницы.

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

Для интернет-магазина важно протестировать каталог, корзину, оформление заказа, письма, статусы заказов и личный кабинет пользователя.

Проверку восстановления не обязательно делать каждый день. Но её нужно проводить регулярно и обязательно после изменения схемы бэкапа: нового скрипта, нового хранилища, смены базы данных, переноса сайта или обновления инфраструктуры.

Именно restore показывает, есть ли у сайта настоящий бэкап. Пока восстановление ни разу не проверяли, есть только надежда, что архив когда-нибудь поможет.

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

После общей backup strategy нужно разобрать состав самого сайта. Ошибка многих владельцев VPS в том, что они сохраняют только папку с файлами и считают, что этого достаточно.

Для простого статического сайта такой подход иногда работает. Но для WordPress, интернет-магазина, форума, личного кабинета или любого динамического проекта сайт состоит из нескольких частей: файлов, базы данных, пользовательских загрузок, конфигов и задач, которые запускаются по расписанию.

Файлы сайта

Файлы сайта — это код, шаблоны, темы, плагины, статические ресурсы и структура проекта. Обычно они находятся в директории вроде: /var/www/example.com/ или в другой папке, которую использует панель управления, фреймворк или конкретная настройка VPS.

Для WordPress в файловый бэкап обычно входят:

• Ядро WordPress;
• Темы;
• Плагины;
• Каталог wp-content;
• Пользовательские изменения в коде;
• Файлы .htaccess, если используется Apache;
• Дополнительные скрипты и статические файлы.

Архив файлов помогает восстановить внешний вид сайта, плагины, кастомный код и структуру проекта. Но сам по себе он не возвращает записи, страницы, пользователей, заказы и настройки, если эти данные хранятся в базе.

Поэтому после файлов нужно обязательно перейти к базе данных. Для динамического сайта это не дополнение, а вторая половина резервной копии.

База данных

База данных хранит динамическую часть сайта. В WordPress это записи, страницы, пользователи, комментарии, настройки, меню, заказы WooCommerce, статусы оплат и данные многих плагинов.

Если сохранить только файлы, но потерять базу, сайт может технически открыться, но останется без основного содержимого.

Для MySQL или MariaDB обычно делают SQL dump: mysqldump -u db_user -p database_name > database_name.sql

Для автоматического бэкапа команду обычно используют в скрипте, где доступ к базе берётся из защищённого конфигурационного файла или переменных окружения. Пароль не стоит оставлять в открытом виде в публичных файлах или в истории команд.

Для нескольких баз можно делать отдельные dumps или общий бэкап всех баз, если это оправдано: mysqldump --all-databases > all-databases.sql

Но для восстановления конкретного сайта удобнее иметь отдельный dump нужной базы. Так меньше риск случайно затронуть другие проекты на том же VPS.

Файлы и база вместе уже позволяют восстановить большую часть сайта. Но на VPS есть ещё конфиги, без которых сайт может не запуститься даже при наличии архива и SQL dump.

Конфиги веб-сервера и приложения

Конфиги определяют, как сайт запускается, куда направляется трафик, какая версия PHP используется, как приложение подключается к базе и какие переменные окружения нужны для работы.

Для веб-сервера это могут быть конфиги Nginx или Apache:

/etc/nginx/sites-available/example.com

/etc/nginx/nginx.conf

/etc/apache2/sites-available/example.com.conf

Для приложения это могут быть:

• .env;
• wp-config.php;
• Конфиги фреймворка;
• Настройки подключения к базе;
• Параметры кэша;
• Ключи API;
• Настройки очередей;
• Параметры почты и SMTP.

Такие файлы нужно бэкапить аккуратно. В них часто есть пароли, токены, секретные ключи и доступы к внешним сервисам. Поэтому архивы с конфигами нельзя хранить в публичной директории сайта или отдавать по прямой ссылке.

Если конфиги потеряны, сайт может быть восстановлен частично, но не запуститься: база есть, файлы есть, а подключение к базе, домен, rewrite-правила, PHP-FPM или переменные окружения настроены неправильно.

После конфигов важно отдельно посмотреть на пользовательские файлы. Именно они часто занимают больше всего места и меняются чаще, чем код сайта.

Uploads и пользовательские файлы

Uploads — это загруженные изображения, документы, вложения, аватары, медиафайлы и другие данные, которые пользователи или администраторы добавляют через сайт.

В WordPress основной каталог загрузок обычно находится здесь: /var/www/example.com/wp-content/uploads/

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

Uploads стоит рассматривать отдельно от кода сайта. Код темы и плагинов может меняться редко, а загруженные файлы — каждый день. Поэтому для них может понадобиться другое расписание бэкапов.

Например, файлы WordPress можно архивировать раз в неделю, а uploads — ежедневно или несколько раз в неделю, если сайт активно обновляется.

Также важно учитывать размер. Каталог uploads может занимать десятки гигабайт, и если каждый раз делать полный архив, бэкапы быстро заполнят диск. В таких случаях стоит использовать инкрементальные копии, синхронизацию в удалённое хранилище или отдельную политику хранения.

Когда файлы, база, конфиги и uploads покрыты, остаются небольшие, но важные элементы инфраструктуры: SSL и cron-задачи.

SSL-сертификаты и cron-задачи

SSL-сертификаты не всегда нужно бэкапить как обычные файлы. Если используется Let’s Encrypt, сертификат обычно можно легко выпустить заново. Но важно сохранить или задокументировать способ восстановления: домен, веб-сервер, certbot, пути к конфигам и команды перевыпуска.

Если сертификаты коммерческие, кастомные или завязаны на ручную выдачу, их нужно хранить аккуратнее: вместе с приватными ключами, цепочками сертификатов и инструкцией по установке.

Пути могут выглядеть так:

/etc/letsencrypt/

/etc/ssl/

Но архивировать приватные ключи нужно только в защищённом виде. Если такой архив попадёт в чужие руки, злоумышленник может использовать ключ для атак на доверие к сайту.

Cron-задачи тоже часто забывают. Через cron могут запускаться бэкапы, очистка кэша, рассылки, парсеры, обновления, импорты товаров, генерация sitemap и другие фоновые задачи.

Посмотреть cron текущего пользователя можно так: crontab -l

Системные cron-задачи могут находиться в:

/etc/crontab

/etc/cron.d/

/etc/cron.daily/

/etc/cron.weekly/

Если восстановить сайт без cron-задач, он может открываться, но часть процессов перестанет работать: не будут уходить уведомления, обновляться товары, очищаться временные файлы или запускаться резервное копирование.

В итоге полноценный бэкап сайта — это не только архив /var/www. Для восстановления нужны файлы, база данных, uploads, конфиги, важные системные настройки, SSL-инструкции и cron-задачи. Чем лучше описан состав бэкапа, тем меньше неожиданностей будет во время restore.

Практический пример: WordPress на VPS

WordPress на VPS удобно рассматривать как типичный небольшой сайт: есть файлы, база данных, загруженные изображения, плагины, темы, конфиги и периодические изменения.

Для такого сайта хороший бэкап лучше собирать не одним большим архивом, а несколькими частями. Так проще восстановить не весь сервер целиком, а конкретный элемент: базу, uploads, тему, плагин или состояние VPS перед обновлением.

Бэкап файлов WordPress

Файлы WordPress обычно находятся в директории сайта. Например: /var/www/example.com/

Перед бэкапом удобно создать отдельную директорию для архивов: mkdir -p /backup/example.com

Затем можно сделать архив файлов сайта: tar -czf /backup/example.com/site-files-$(date +%F).tar.gz /var/www/example.com

Такой архив сохранит структуру сайта, темы, плагины, ядро WordPress, .htaccess, если используется Apache, и другие файлы проекта.

Но в WordPress большая часть содержимого хранится не в файлах. Поэтому архив директории сайта нужно дополнять бэкапом базы данных.

MySQL dump базы данных

База данных WordPress хранит записи, страницы, пользователей, комментарии, настройки, меню, заказы WooCommerce и данные многих плагинов.

Для MySQL или MariaDB можно сделать dump базы: mysqldump -u db_user -p wordpress_db > /backup/example.com/wordpress-db-$(date +%F).sql

После этого SQL-файл можно дополнительно сжать: gzip /backup/example.com/wordpress-db-$(date +%F).sql

На практике имя базы, пользователя и пароль берут из wp-config.php:

define( 'DB_NAME', 'wordpress_db' );

define( 'DB_USER', 'db_user' );

define( 'DB_PASSWORD', 'db_password' );

define( 'DB_HOST', 'localhost' );

Пароль от базы не стоит оставлять в открытом виде в скриптах, публичных директориях или истории команд. Для автоматизации лучше использовать защищённый конфигурационный файл с ограниченными правами или отдельного пользователя базы с нужными правами.

Файлы сайта и dump базы уже дают основу для восстановления WordPress. Но для активного сайта стоит отдельно подумать об uploads: этот каталог часто меняется чаще, чем темы и плагины.

Архив uploads отдельно

Каталог uploads в WordPress обычно находится здесь: /var/www/example.com/wp-content/uploads/

В нём лежат изображения, документы, медиафайлы, файлы товаров, вложения и другие материалы, загруженные через админку или пользователями.

Если сайт активно обновляется, uploads удобно бэкапить отдельно:

tar -czf /backup/example.com/uploads-$(date +%F).tar.gz /var/www/example.com/wp-content/uploads

Такой подход полезен по двум причинам.

Во-первых, uploads может занимать много места. Не всегда удобно каждый день архивировать весь WordPress, если реально меняются только медиафайлы и база.

Во-вторых, отдельный архив uploads упрощает частичное восстановление. Например, если после миграции пропали изображения, не нужно разворачивать весь сайт — достаточно восстановить каталог загрузок.

Для больших сайтов лучше рассмотреть не полный архив uploads каждый раз, а синхронизацию в удалённое хранилище. Но для небольшого WordPress-сайта отдельный архив часто остаётся самым понятным вариантом.

Файлы, база и uploads помогают восстановить сам сайт. А snapshot VPS нужен для другого сценария — быстрого отката всего сервера.

Snapshot VPS

Snapshot VPS — это снимок состояния сервера на уровне провайдера. Он может включать диск, систему, установленные пакеты, конфиги, файлы сайта и базу в том состоянии, в котором они были на момент создания снимка.

Snapshot особенно полезен перед рискованными действиями:

• Обновлением PHP;
• Обновлением базы данных;
• Массовым обновлением WordPress-плагинов;
• Изменением конфигов Nginx или Apache;
• Переносом сайта;
• Сменой панели управления;
• Крупными работами на сервере.

Если после обновления сайт перестал открываться, snapshot позволяет быстро откатить весь VPS к предыдущему состоянию.

Но snapshot не стоит считать единственным бэкапом. У него есть ограничения: он зависит от провайдера, может храниться в той же инфраструктуре, не всегда удобен для восстановления одного файла или одной базы, может влиять на быстродействие VPS целиком и не заменяет удалённую копию.

Поэтому snapshot лучше использовать как дополнительный уровень защиты, а не как основную backup strategy.

После локальных архивов и snapshot остаётся самый важный вопрос: что будет, если основной VPS будет потерян целиком. Для этого нужна копия за пределами сервера.

Копия в удалённое хранилище

Удалённая копия защищает от сценария, когда основной VPS недоступен, удалён, взломан или повреждён. Если все бэкапы лежали только на нём, восстановиться будет не из чего.

Для удалённого хранения можно использовать:

• Object storage;
• Отдельный backup-сервер;
• SFTP-хранилище;
• Облачное хранилище;
• Другой VPS, предназначенный только для резервных копий.

Простая логика такая: бэкап создаётся локально, затем копируется за пределы основного сервера.

Например, если используется отдельный backup-сервер, копию можно отправлять через rsync: rsync -avz /backup/example.com/ backup-user@backup.example.net:/backups/example.com/

Или через scp:

scp /backup/example.com/site-files-$(date +%F).tar.gz backup-user@backup.example.net:/backups/example.com/

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

Для object storage обычно используют CLI-инструменты провайдера или совместимые S3-клиенты. В таком случае важно настроить права доступа так, чтобы бэкапы не были публичными, и использовать учётные данные с правами только на запись (не на удаление), а ротацию настраивать средствами S3.

Если в архивах есть персональные данные, заказы, email-адреса, документы или пользовательские файлы, перед отправкой в удалённое хранилище стоит использовать шифрование.

Практичная схема для WordPress на VPS выглядит так: файлы сайта архивируются отдельно, база сохраняется через MySQL dump, uploads можно выносить в отдельный архив, перед важными работами создаётся snapshot, а готовые копии отправляются в удалённое хранилище. Такая схема не самая сложная, но она закрывает основные риски небольшого сайта.

Как настроить расписание бэкапов через cron

Когда понятно, что именно нужно бэкапить, следующий шаг — автоматизация. Ручной бэкап перед крупными изменениями полезен, но он не заменяет расписание: в обычные дни владелец сайта легко забудет сделать копию.

На VPS для регулярных задач часто используют cron. Через него можно запускать скрипты бэкапа каждый день, раз в неделю или по другому расписанию.

Важно не собирать всё в одну непрозрачную команду. Лучше разделить задачи: отдельно база, отдельно файлы, отдельно удаление старых архивов и отдельно проверка логов.

Ежедневный бэкап базы

База данных меняется чаще всего. В WordPress в ней хранятся записи, страницы, пользователи, настройки, комментарии, заказы WooCommerce и данные плагинов. Поэтому базу обычно бэкапят ежедневно, а для активных интернет-магазинов — ещё чаще.

Простой скрипт для ежедневного dump может выглядеть так:

#!/bin/bash

BACKUP_DIR="/backup/example.com/db"

DATE=$(date +%F)

DB_NAME="wordpress_db"

DB_USER="db_user"

mkdir -p "$BACKUP_DIR"

mysqldump -u "$DB_USER" -p "$DB_NAME" | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"

Такой пример показывает принцип, но в рабочем скрипте пароль лучше не вводить вручную и не хранить в открытом виде. Безопаснее использовать отдельный конфигурационный файл MySQL с ограниченными правами или другой защищённый способ авторизации.

Например, можно вынести доступы в файл, который доступен только нужному пользователю, и использовать его в скрипте:

mysqldump --defaults-extra-file=/root/.my.cnf wordpress_db | gzip > /backup/example.com/db/db-$(date +%F).sql.gz

После этого задачу можно добавить в cron:

crontab -e

Пример запуска каждый день в 03:10:

10 3 * * * /usr/local/bin/backup-db.sh >> /var/log/site-backup.log 2>&1

База — самая чувствительная часть динамического сайта, но одних SQL dump недостаточно. Файлы WordPress, темы, плагины и uploads тоже должны попадать в расписание.

Еженедельный бэкап файлов

Файлы сайта обычно меняются реже, чем база. Темы, плагины, код и структура проекта обновляются не каждый день, поэтому для небольшого сайта часто достаточно еженедельного архива.

Пример скрипта для файлов WordPress:

#!/bin/bash

BACKUP_DIR="/backup/example.com/files"

DATE=$(date +%F)

SITE_DIR="/var/www/example.com"

mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/site-files-$DATE.tar.gz" "$SITE_DIR"

Если uploads меняется часто и занимает много места, его можно бэкапить отдельно от остальных файлов. Например, код сайта — раз в неделю, а uploads — ежедневно или несколько раз в неделю.

Для еженедельного запуска через cron можно использовать такую запись:

30 3 * * 0 /usr/local/bin/backup-files.sh >> /var/log/site-backup.log 2>&1

Здесь скрипт запускается по воскресеньям в 03:30. Время лучше выбирать так, чтобы на сайте было меньше активности и нагрузка от архивации не мешала пользователям.

Перед крупными обновлениями WordPress, PHP, базы данных, темы или плагинов лучше делать дополнительный ручной бэкап. Расписание закрывает регулярную защиту, но не отменяет точку отката перед рискованными изменениями.

Когда база и файлы начинают сохраняться регулярно, быстро появляется новая проблема: архивы занимают всё больше места. Поэтому нужна ротация.

Ротация старых архивов

Ротация удаляет старые бэкапы по правилам, чтобы диск не заполнился архивами. Без ротации резервные копии могут сами стать причиной аварии: сайт перестанет работать из-за нехватки места на VPS.

Самый простой вариант — удалять ежедневные копии старше определённого срока:

find /backup/example.com/db -type f -name "*.sql.gz" -mtime +14 -delete

Эта команда удалит SQL-архивы старше 14 дней.

Для файловых архивов можно использовать другой срок, например 30 дней:

find /backup/example.com/files -type f -name "*.tar.gz" -mtime +30 -delete

Но удалять всё по одному правилу не всегда удобно. Лучше заранее определить политику хранения:

Ротацию можно добавить отдельной cron-задачей:

0 4 * * * /usr/local/bin/rotate-backups.sh >> /var/log/site-backup.log 2>&1

Важно не удалять старые копии до того, как новая копия успешно создана и отправлена в удалённое хранилище. Иначе можно остаться без актуального бэкапа. Поэтому оптимально в скрипт ротации добавить проверку на наличие актуального файла, или сделать единый скрипт резервного копирования с удалением только в случае успеха.

Автоматизация должна не только создавать и удалять архивы. Нужно ещё понимать, прошёл ли бэкап успешно. Для этого нужны логи.

Проверка логов бэкапа

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

Поэтому вывод скриптов лучше записывать в лог:

10 3 * * * /usr/local/bin/backup-db.sh >> /var/log/site-backup.log 2>&1

30 3 * * 0 /usr/local/bin/backup-files.sh >> /var/log/site-backup.log 2>&1

0 4 * * * /usr/local/bin/rotate-backups.sh >> /var/log/site-backup.log 2>&1

Периодически лог нужно просматривать:

tail -n 100 /var/log/site-backup.log

Также полезно проверять размер свежих архивов:

ls -lh /backup/example.com/db/

ls -lh /backup/example.com/files/

Если вчерашний dump базы весил 300 MB, а сегодняшний внезапно весит 2 KB, это повод остановиться и проверить скрипт. Формально файл создан, но внутри может не быть полноценного бэкапа.

Для более надёжной схемы можно добавить уведомления: отправку сообщения в email, Slack или систему мониторинга при ошибке. Главное — не узнавать о сломанном бэкапе только после аварии.

Расписание через cron закрывает регулярность, но не решает вопрос хранения. Локальные архивы удобны, однако полноценная защита появляется только тогда, когда копии уходят за пределы основного VPS.

Где хранить бэкапы

Место хранения бэкапов так же важно, как и сам архив. Если резервная копия лежит рядом с сайтом и зависит от того же сервера, она может исчезнуть вместе с ним.

Хорошая схема хранения должна закрывать несколько сценариев: случайное удаление файла, поломку сайта после обновления, сбой VPS, потерю доступа к серверу и повреждение локального диска.

На том же VPS

Локальный бэкап на том же VPS удобен для быстрых восстановлений. Например, если случайно удалили файл, сломали тему WordPress или нужно откатить базу за вчерашний день, архив рядом и его можно быстро использовать.

Такой вариант подходит для короткого хранения:

• Последние SQL dump;
• Свежие архивы файлов;
• Копии перед обновлением;
• Временные бэкапы перед изменением конфигов.

Но локальный бэкап не защищает от серьёзной аварии. Если сервер будет удалён, диск сломается, аккаунт заблокируют или злоумышленник получит root-доступ, бэкапы могут пропасть вместе с сайтом.

Ещё одна проблема — место на диске. Если складывать архивы на тот же VPS без ротации, они могут заполнить диск и сами вызвать сбой сайта.

Поэтому локальные копии лучше использовать как быстрый слой восстановления, а не как единственное место хранения.

На отдельном backup-сервере

Отдельный backup-сервер защищает от потери основного VPS. Это может быть другой VPS, выделенный сервер, сетевое хранилище или отдельная машина, куда основной сервер отправляет архивы.

Такой вариант удобен, если нужно больше контроля: можно настроить rsync, SFTP, SSH-ключи, отдельные права доступа, ротацию и собственную структуру каталогов.

Пример отправки бэкапов через rsync:

rsync -avz /backup/example.com/ backup-user@backup.example.net:/backups/example.com/

Backup-сервер не должен быть просто “ещё одной папкой с полным доступом”. Лучше использовать отдельного пользователя, ограниченные права и ключи, которые позволяют записывать бэкапы, но не дают лишнего доступа к основному серверу.

Также важно следить за свободным местом, логами передачи и сроком хранения старых архивов. Если backup-сервер переполнится, новые копии могут перестать сохраняться, а владелец сайта узнает об этом только после аварии.

Отдельный сервер даёт контроль, но требует обслуживания. Если хочется меньше администрирования, часто удобнее использовать object storage.

В object storage

Object storage подходит для удалённого хранения архивов: SQL dump, файлов сайта, uploads и зашифрованных копий. Такой формат удобен тем, что хранилище отделено от VPS и обычно хорошо подходит для автоматической загрузки файлов.

В object storage можно настроить:

• Отдельный bucket для бэкапов;
• Ограниченные ключи доступа;
• lifecycle rules для удаления старых копий;
• Версионирование;
• Хранение в другом регионе;
• Политику доступа без публичного чтения.

Главное правило — bucket с бэкапами не должен быть публичным. В архивах могут быть персональные данные, заказы, email-адреса, конфиги, документы пользователей и другие чувствительные данные.

Если бэкапы содержат такие данные, их лучше шифровать до отправки в object storage. Тогда даже при ошибке в настройках доступа архив не будет лежать в открытом виде.

Object storage хорошо подходит для аварийного восстановления, но не всегда удобен для мгновенного отката всего сервера. Для этого часто используют snapshot VPS.

В snapshot VPS

Snapshot VPS — это снимок состояния сервера на уровне провайдера. Он полезен, когда нужно быстро откатить весь сервер после неудачного обновления, изменения конфигов или крупной миграции.

Snapshot особенно уместен перед действиями, которые могут затронуть всю систему:

• Обновление PHP;
• Обновление базы данных;
• Изменение версии ОС;
• Настройка панели управления;
• Перенос сайта;
• Массовое обновление WordPress, темы и плагинов;
• Изменение конфигов Nginx, Apache или PHP-FPM.

Но snapshot не заменяет обычные бэкапы. Он зависит от провайдера, может храниться в той же инфраструктуре и не всегда удобен, если нужно восстановить только одну базу, один каталог uploads или отдельный файл.

Ещё один нюанс — консистентность данных. Если snapshot делается во время активной записи в базу, состояние приложения может быть неидеальным. Для важных проектов snapshot лучше сочетать с обычными database dump и файловыми бэкапами.

Snapshot — хороший инструмент быстрого отката, но полноценная backup strategy строится не на одном варианте хранения.

Почему лучше сочетать несколько вариантов

Надёжная схема бэкапов обычно сочетает несколько уровней хранения. Каждый вариант закрывает свой риск, но ни один не решает все задачи сразу.

Для небольшого сайта можно использовать такую схему:

Практичный минимум: локальная копия на VPS плюс удалённая копия за его пределами. Для более аккуратной схемы можно добавить snapshot перед важными работами и object storage для долгого хранения.

Главная ошибка — хранить единственный бэкап там же, где находится сайт. Такой архив помогает только при мелких проблемах, но не спасает при потере VPS.

Лучше думать о хранении через вопрос: “что будет, если основной сервер исчезнет прямо сейчас?” Если ответ — “бэкапы тоже исчезнут”, схему нужно менять.

Как проверить восстановление

Бэкап нельзя считать рабочим только потому, что архив создался без ошибки. Настоящая проверка начинается в момент восстановления: база должна импортироваться, файлы — распаковаться, права — не сломаться, а сайт — открыться в браузере.

Проверять restore лучше не на боевом сайте. Безопаснее использовать тестовое окружение: отдельный VPS, временный домен, поддомен, локальную машину или изолированную директорию. Так можно спокойно проверить архивы и не рисковать рабочим проектом.

Восстановление базы на тестовом окружении

Для динамического сайта база данных — один из главных элементов восстановления. Если SQL dump повреждён, неполный или сделан не от той базы, сайт может открыться с ошибками или потерять часть контента.

На тестовом окружении нужно создать новую базу:

mysql -u root -p -e "CREATE DATABASE restore_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Затем импортировать dump:

gunzip < /backup/example.com/db/db-2026-01-15.sql.gz | mysql -u root -p restore_test

Если dump не сжат, команда будет проще:

mysql -u root -p restore_test < /backup/example.com/db/db-2026-01-15.sql

После импорта стоит проверить, что таблицы действительно появились:

mysql -u root -p -e "SHOW TABLES FROM restore_test;"

Для WordPress также важно убедиться, что в базе есть таблицы с нужным префиксом: например, wp_posts, wp_options, wp_users, wp_postmeta.

Если база восстановилась без ошибок, можно переходить к файлам сайта. Без них база сама по себе не даст рабочий WordPress, интернет-магазин или приложение.

Проверка файлов и uploads

Файлы сайта нужно распаковать в тестовую директорию, а не поверх боевого проекта. Например:

mkdir -p /var/www/restore-test

tar -xzf /backup/example.com/files/site-files-2026-01-15.tar.gz -C /var/www/restore-test

После распаковки нужно проверить, что структура выглядит ожидаемо. Для WordPress внутри должны быть файлы и каталоги вроде:

wp-admin/

wp-content/

wp-includes/

wp-config.php

index.php

Отдельно проверьте uploads. В WordPress этот каталог обычно находится здесь:

/wp-content/uploads/

Если uploads не восстановлены, сайт может открываться, но изображения, документы, файлы товаров и медиафайлы будут отсутствовать. Для интернет-магазина это может означать пустые карточки товаров, сломанные инструкции, пропавшие вложения или недоступные цифровые товары.

Также стоит проверить размер восстановленных файлов. Если архив uploads должен занимать несколько гигабайт, а после распаковки получилась почти пустая папка, значит бэкап был неполным или восстановление прошло неправильно.

Когда база и файлы восстановлены, сайт всё ещё может не запуститься из-за прав доступа. Поэтому следующий шаг — проверить владельца файлов и разрешения.

Проверка прав доступа

После восстановления файлы могут оказаться под неправильным пользователем. Например, архив распаковали от root, а веб-сервер работает от www-data. В результате сайт может открываться с ошибками, не загружать изображения, не обновлять плагины или не писать кэш.

Проверить владельца файлов можно так:

ls -la /var/www/restore-test

Для типичной связки Nginx/Apache с PHP-FPM владельцем часто делают пользователя веб-сервера или отдельного пользователя сайта. Например:

chown -R www-data:www-data /var/www/restore-test

Права тоже должны быть аккуратными. Для WordPress часто используют ориентир:

find /var/www/restore-test -type d -exec chmod 755 {} \;

find /var/www/restore-test -type f -exec chmod 644 {} \;

Но это не универсальное правило для всех проектов. Некоторые приложения требуют отдельные права на каталоги кэша, uploads, storage, logs или временные файлы.

Особое внимание стоит уделить конфигам с секретами: .env, wp-config.php, файлам с ключами API и доступами к базе. Они не должны быть доступны публично и не должны иметь слишком широкие права.

После проверки прав можно запускать сайт на тестовом домене или временном адресе и смотреть, работает ли он как полноценный проект.

Проверка сайта после restore

Финальная проверка восстановления — это не просто открыть главную страницу. Главная может загрузиться из кэша, а проблемы проявятся в админке, формах, корзине, изображениях или подключении к базе.

Для WordPress нужно проверить:

• Открывается ли главная страница;
• Работают ли внутренние страницы;
• Открывается ли админка;
• Видны ли изображения из uploads;
• Работают ли постоянные ссылки;
• Активны ли нужные плагины;
• Корректно ли подключена тема;
• Нет ли ошибок PHP в логах.

Для интернет-магазина проверка должна быть шире:

• Открывается ли каталог;
• Работают ли карточки товаров;
• Добавляется ли товар в корзину;
• Проходит ли оформление заказа;
• Создаётся ли заказ в админке;
• Отправляются ли письма клиенту и администратору;
• Сохраняются ли статусы оплаты и доставки;
• Работает ли личный кабинет.

Также стоит проверить конфиги веб-сервера, подключение к базе, cron-задачи и фоновые процессы. Сайт может открываться в браузере, но не выполнять регулярные задачи: очистку кэша, импорт товаров, генерацию sitemap, отправку уведомлений или создание новых бэкапов.

После тестового restore полезно зафиксировать результат: какая копия восстановилась, сколько времени занял процесс, какие команды использовались и какие проблемы возникли. Это превращает восстановление из разовой импровизации в понятную инструкцию.

Если restore ни разу не проверяли, бэкап остаётся предположением. Рабочей резервной копией можно считать только ту, из которой сайт уже удалось восстановить хотя бы на тестовом окружении.

Типовые ошибки при бэкапе сайта

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

Поэтому ошибки в backup strategy лучше разобрать заранее. Они типовые, но именно из-за них небольшой сбой часто превращается в полную потерю сайта.

Хранить бэкап только на том же VPS

Локальный бэкап на том же VPS удобен, но он не должен быть единственным. Он помогает, если нужно быстро вернуть удалённый файл, откатить базу за вчерашний день или восстановиться после неудачного обновления.

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

Ещё один риск — заполнение диска. Если архивы складываются на тот же сервер без ротации, они могут занять всё свободное место. В результате сайт начнёт работать нестабильно, база может перестать записывать данные, а новые бэкапы не будут создаваться.

Правильнее использовать локальные копии только как быстрый слой восстановления. Основной аварийный бэкап должен лежать за пределами VPS: на отдельном backup-сервере, в object storage или другом защищённом хранилище.

Даже если бэкап хранится в правильном месте, это ещё не значит, что из него можно восстановиться. Следующая частая ошибка — никогда не проверять restore.

Не проверять restore

Бэкап без проверки восстановления — это не гарантия, а предположение. Архив может выглядеть нормальным, занимать много места и создаваться по расписанию, но при восстановлении оказаться бесполезным.

Проблемы могут быть разными:

• SQL dump создавался не от той базы;
• Архив файлов не содержит uploads;
• Файл повреждён;
• Бэкап обрывался из-за нехватки места;
• Скрипт не сохранял ошибки;
• База не импортируется из-за кодировки или версии;
• После восстановления ломаются права доступа;
• В архиве нет нужных конфигов.

Проверять restore лучше на тестовом окружении: отдельном VPS, временном домене, поддомене или локальной машине. Нужно не просто распаковать архив, а убедиться, что сайт открывается, база подключается, изображения видны, формы работают, а админка доступна.

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

Проверка restore показывает, какие части бэкапа действительно рабочие, а какие существуют только формально. Особенно часто на этом этапе обнаруживается, что сохранялись только файлы, но не база данных.

Бэкапить только файлы без базы

Для динамического сайта архив файлов не равен полноценному бэкапу. WordPress, WooCommerce, форумы, личные кабинеты и многие CMS хранят основную информацию в базе данных.

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

Если сохранить только файлы, после аварии можно восстановить оболочку сайта, но не его содержимое.

Для WordPress минимальный бэкап должен включать:

• Архив файлов сайта;
• SQL dump базы данных;
• Каталог uploads;
• Конфиги вроде wp-config.php;
• Информацию о версии PHP, базе и веб-сервере.

Особенно критична база для интернет-магазинов. Потеря SQL dump может означать потерю заказов, клиентов, статусов оплат и истории покупок.

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

Когда в бэкапе есть база, uploads и конфиги, появляется другой вопрос: как защищены сами архивы. Если внутри персональные данные, хранить их в открытом виде опасно.

Не шифровать архивы с персональными данными

Бэкапы часто содержат больше чувствительных данных, чем кажется. В них могут быть email-адреса, телефоны, заказы, адреса доставки, документы, пользовательские файлы, API-ключи, пароли к базе и конфиги приложения.

Если такой архив лежит без шифрования, его утечка может быть опаснее, чем обычный доступ к публичной части сайта. Особенно если бэкап отправляется в удалённое хранилище, хранится на стороннем сервере или передаётся между системами.

Минимальные меры защиты:

• Не хранить архивы в публичной директории сайта;
• Ограничивать права доступа к папке с бэкапами;
• Использовать отдельные ключи для backup-хранилища;
• Шифровать архивы с персональными данными;
• Не передавать бэкапы по незащищённым каналам;
• Удалять устаревшие копии по политике хранения.

Например, архивы не должны лежать в директории вроде:

/var/www/example.com/backup/

Если такая папка случайно станет доступна из браузера, бэкап можно будет скачать напрямую.

Для чувствительных данных лучше использовать шифрование до отправки в удалённое хранилище. Тогда даже при ошибке в настройках доступа архив не окажется полностью открытым.

Но защита архивов не решает ещё одну проблему: можно аккуратно хранить бэкапы и всё равно не заметить, что они давно перестали создаваться.

Узнавать о сломанном бэкапе только после аварии

Одна из самых неприятных ситуаций — обнаружить проблему с бэкапом в момент восстановления. Например, сайт уже сломан, а последние архивы пустые, старые, повреждённые или вообще не создавались последние два месяца.

Такое часто происходит, если нет мониторинга и проверки логов. Скрипт мог перестать работать после обновления MySQL, смены пароля, изменения пути к сайту, заполнения диска или переноса проекта в другую директорию.

Формально cron-задача может оставаться на месте, но бэкап при этом не создаётся.

Чтобы не узнать об этом слишком поздно, нужно проверять:

• Дату последнего успешного бэкапа;
• Размер свежих архивов;
• Логи скрипта;
• Свободное место на диске;
• Успешную отправку в удалённое хранилище;
• Наличие ошибок при dump базы;
• Периодический restore на тестовом окружении.

Полезно добавить уведомления об ошибках: email, Slack или систему мониторинга. Даже простое сообщение “бэкап не создался” лучше, чем тишина до аварии.

В итоге хорошая backup strategy должна не только создавать архивы, но и подтверждать, что они появились, не пустые, отправлены в нужное место и хотя бы периодически восстанавливаются. Без этого бэкап остаётся слабым местом, а не защитой сайта.

Заключение

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

Для небольшого сайта минимально нужно сохранять файлы, базу данных, uploads, конфиги, важные cron-задачи и инструкции по восстановлению SSL. Для WordPress особенно важно помнить, что файлы и база данных — разные части сайта. В файлах лежат темы, плагины и медиа, а в базе — записи, страницы, пользователи, настройки и заказы WooCommerce.

Хранить резервные копии только на том же VPS опасно. Локальный архив помогает быстро восстановить файл или базу, но не спасает, если сервер удалён, диск повреждён или доступ к VPS потерян. Поэтому рабочая схема должна включать удалённое хранилище: отдельный backup-сервер, object storage или другой независимый вариант.

Snapshot VPS полезен как быстрый откат перед обновлениями и крупными изменениями, но он не заменяет обычные бэкапы. Для восстановления отдельной базы, uploads или конкретной версии сайта удобнее иметь отдельные архивы и SQL dump.

Главный критерий качества бэкапа — не сам факт создания архива, а успешный restore. Если восстановление ни разу не проверяли, нельзя быть уверенным, что архив поможет после аварии. Поэтому хотя бы периодически нужно поднимать сайт из резервной копии на тестовом окружении и проверять базу, файлы, uploads, права доступа, админку, формы и ключевые сценарии.

Хорошая backup strategy превращает аварию из катастрофы в понятный порядок действий: достать нужную копию, восстановить базу, распаковать файлы, проверить конфиги, поправить права и вернуть сайт в работу.

FAQ

Как часто нужно делать бэкап сайта на VPS?

Частота зависит от того, как часто меняются данные. Для небольшого WordPress-сайта обычно достаточно ежедневного бэкапа базы и еженедельного бэкапа файлов.

Для интернет-магазина базу лучше сохранять чаще, потому что в ней находятся заказы, клиенты, статусы оплат и настройки WooCommerce. Перед обновлениями WordPress, PHP, базы данных, темы, плагинов или конфигов веб-сервера стоит делать отдельный ручной бэкап.

Достаточно ли snapshot VPS для защиты сайта?

Нет, snapshot VPS полезен, но не должен быть единственным бэкапом. Он хорошо подходит для быстрого отката всего сервера после неудачного обновления или изменения конфигов.

Но snapshot зависит от провайдера и не всегда удобен, если нужно восстановить одну базу, один каталог uploads или отдельный файл. Поэтому snapshot лучше сочетать с обычными файловыми архивами, SQL dump базы и копией в удалённое хранилище.

Что обязательно бэкапить в WordPress?

Для WordPress нужно бэкапить файлы сайта и базу данных. В файлах находятся ядро WordPress, темы, плагины, wp-content, uploads и пользовательские изменения. В базе хранятся записи, страницы, пользователи, комментарии, настройки, меню, данные плагинов и заказы WooCommerce.

Также стоит сохранить wp-config.php, конфиги веб-сервера, cron-задачи и информацию о версии PHP, MySQL/MariaDB и ключевых расширениях.

Можно ли хранить бэкапы на том же VPS?

Можно, но только как дополнительный быстрый слой восстановления. Локальная копия удобна, если нужно быстро вернуть удалённый файл или откатить базу за вчерашний день.

Но хранить бэкап только на том же VPS нельзя. Если сервер будет удалён, диск сломается или злоумышленник получит доступ к системе, локальные архивы могут исчезнуть вместе с сайтом.

Как понять, что бэкап действительно рабочий?

Бэкап считается рабочим только после проверки восстановления. Нужно взять архив, поднять сайт на тестовом окружении, импортировать базу, распаковать файлы, проверить uploads, права доступа, конфиги и работу сайта в браузере.

Для WordPress стоит проверить главную страницу, внутренние страницы, админку, медиафайлы, постоянные ссылки и плагины. Для интернет-магазина — каталог, корзину, оформление заказа, письма и личный кабинет.

Нужно ли шифровать бэкапы сайта?

Если в бэкапах есть персональные данные, заказы, email-адреса, документы, пользовательские файлы, ключи API или пароли к базе, архивы лучше шифровать.

Особенно это важно при отправке в удалённое хранилище или на отдельный backup-сервер. Даже если доступ к хранилищу будет настроен неправильно, зашифрованный архив снизит риск утечки данных.

Что хуже: не делать бэкапы или не проверять восстановление?

Оба варианта опасны. Но непроверенный бэкап создаёт ложное чувство безопасности. Владелец сайта может быть уверен, что всё защищено, а после аварии обнаружить, что архив пустой, база не импортируется или uploads не сохранились.

Поэтому backup strategy должна включать не только создание копий, но и проверку логов, контроль размера архивов, отправку в удалённое хранилище и регулярный тест restore.

Список источников

1. WordPress Developer Resources — Backing Up Your Database

2. WordPress Developer Resources — Backing Up Your WordPress Files

3. MySQL Documentation — mysqldump: A Database Backup Program

4. Ubuntu Manpages — cron