Бэкап WordPress на VPS: автоматизация копий и восстановление

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

Минимальный набор для надёжного бэкапа WordPress на VPS обычно включает:

каталог с файлами WordPress (например, /var/www/example.com или где у тебя размещён сайт);
базу данных MySQL/MariaDB, в которой лежат статьи, страницы, настройки, пользователи;
конфигурацию приложения (wp-config.php), включая параметры подключения к БД;
дополнительные каталоги, если они используются: загрузки вне стандартного wp-content/uploads, плагины по типу must-use, конфиги кэш-слоя.

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

Если у провайдера VPS есть снапшоты уровня диска или возможность ZFS/LVM-снапшотов, это может закрыть часть задачи быстро. Но всё равно обычно остаётся риск неконсистентного состояния БД на момент снимка. Поэтому даже при снапшотах часто делают логический бэкап базы и/или используют корректную последовательность операций (заморозка/останов сервисов).

Файлы, база данных, конфигурации и ключи

К файловой части относится не только ядро WordPress. В неё входят:

wp-content: плагины, темы, uploads;
любые кастомные каталоги, которые ты создал сам;
wp-config.php;
(при наличии) .htaccess, nginx-конфиги, дополнительные файлы, которые влияют на маршрутизацию и безопасность.

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

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

Когда нужны снапшоты уровня диска

Снапшот диска удобен для быстрых откатов, особенно в тестовой среде. Но у него есть ограничения: снимок фиксирует состояние файловой системы и, иногда, память/состояние процессов. Для БД без корректной подготовки снимок может содержать «смешанные» данные.

Если ты всё-таки используешь снапшоты диска как основу, добавь к ним два шага:

бэкап базы (logical dump) по расписанию;
хотя бы редкий, но регулярный тест восстановления на чистой копии VPS.

Тогда даже если снапшот сработает «не идеально», у тебя будет контролируемый источник правды для БД.

Архитектура бэкапа: полный, инкрементальный и оффсайт

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

Для WordPress на VPS чаще всего встречаются три подхода:

Полные бэкапы по расписанию (например, раз в сутки) — просто и предсказуемо, но может быть дорого по месту.
Инкрементальные/дедупликационные схемы (через инструменты типа restic/borg) — обычно экономят место и дают шифрование «из коробки».
Смешанный вариант: снапшот диска для быстрых откатов плюс логические бэкапы для гарантии консистентности.

Если твоя цель — автоматизация и предсказуемое восстановление, дедупликационные инструменты хорошо подходят. Они делают набор «снимков» с сохранением истории, а ещё умеют ротацию по политике хранения.

Как выбрать стратегию под SLA

Если сервис важен и простои стоят денег, ориентируйся на частоту RPO и длительность восстановления RTO. Примерно:

RPO определяет, сколько данных можно потерять (например, насколько далеко назад должен быть бэкап);
RTO определяет, сколько времени потребуется на разворачивание.

Для большинства сайтов на VPS практичным компромиссом становится ежедневный бэкап с историей за несколько дней/недель. Для более критичных систем добавляют более частые бэкапы файлов или базы.

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

Оффсайт: почему хранить только на том же VPS рискованно

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

Варианты:

отдельный сервер (другой VPS) и приём бэкапов по SSH;
объектное хранилище (S3-совместимое);
специализированные бэкап-сервисы.

На практике удобнее всего объектное или SSH-хранилище: ты минимизируешь ручные действия и можешь централизованно настраивать ретеншн.

Шифрование и проверка целостности

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

В инструментах уровня restic/borg шифрование реализовано в клиенте. Это важно: даже если хранилище «утекло», содержимое останется закрытым.

Проверка целостности делается двумя слоями:

инструмент проверяет контрольные суммы при чтении;
ты периодически делаешь тест восстановления и убеждаешься, что WordPress поднимается и открывает страницы.

Шифрование без теста восстановления — это как страховка без проверки полиса.

Подготовка VPS: разметка хранилища и учёт доступа

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

Предположим, что сайт лежит в /var/www/example.com, а база в MySQL/MariaDB. Тогда тебе понадобятся:

пользователь с ограниченными правами для чтения файлов сайта (или отдельные права для доступа к каталогу);
доступ к базе для дампа (обычно учетная запись с правом SELECT на нужные схемы);
доступ к удалённому хранилищу (переменные окружения или файл с секретами в безопасном месте);
установленный инструмент для хранения снапшотов (ниже пример через restic).

Отдельный пользователь и права

Не держи бэкап-скрипты под root без необходимости. Практичный вариант:

создать пользователя wpbackup;
дать ему права читать файлы сайта (на чтение) и писать в локальный временный каталог;
доступ к дампу базы выдавать через отдельную учётку БД, ограниченную минимально необходимыми правами.

Для временных файлов выдели отдельный каталог, например /var/backups/wp-tmp. Его можно очищать по завершении.

Подключение внешнего хранилища (S3/SSH)

Для restic нужно задать репозиторий и параметры доступа. Например, для S3-совместимого хранилища обычно используются переменные окружения RESTICREPOSITORY и RESTICPASSWORD, а также параметры провайдера (AWSACCESSKEYID, AWSSECRETACCESSKEY или их аналоги).

Пример структуры:

RESTIC_REPOSITORY указывает на путь в хранилище (формат зависит от провайдера);
RESTIC_PASSWORD — пароль шифрования репозитория (лучше хранить в защищённом месте, а не прямо в скрипте).

Если выбран SSH-подход (удалённый сервер с restic-риепозиторием), тогда репозиторий указывает на ssh-адрес, а доступ обеспечивается ключом. Это часто проще с точки зрения сетевой инфраструктуры.

Таймзоны и единый формат дат

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

Иначе в момент расследования инцидента ты можешь перепутать порядок бэкапов: лог «за вчера» может оказаться «сегодня» по местному времени. Лучше заранее договориться об одном варианте и придерживаться его в скриптах и в отчётах.

Автоматизация резервных копий WordPress на VPS: файловая часть

Для файловой части важно сохранить:

структуру каталогов;
права/владельца в той мере, в какой это критично;
все изменения wp-content и темы/плагины.

Постоянная практика: не пытаться бэкапить «частично» без понимания зависимостей. Если сегодня это uploads, завтра окажется, что плагин хранит важные данные в wp-content/something, и ты узнаешь это только при восстановлении.

Вариант с restic: снапшоты файлов с дедупликацией

Основная идея restic: ты создаёшь набор снимков (snapshots) репозитория, а restic сам:

шифрует данные;
дедуплицирует одинаковые блоки;
умеет делать prune (удаление старых снапшотов по политике);
проверяет целостность при операциях.

Условно, схема выглядит так:

подготовить директорию репозитория (создание один раз);
выполнять restic backup для нужных каталогов;
делать prune по политике;
логировать результат.

Например, для файлов WordPress можно бэкапить каталог /var/www/example.com. Но лучше исключить то, что не нужно:

временные кэши, которые можно пересоздать;
каталоги, которые растут без смысла в бэкапах (например, огромные кэши, если они воспроизводятся).

Рекомендуемый подход: сначала собери список больших каталогов в твоём wp-content, посмотри, что является источником данных, а что кэшем. Затем делай исключения осознанно.

Команды в общем виде:

restic init (один раз);
restic backup с аргументами exclude;
restic prune с retention policy.

Локальные временные файлы и исключения

С некоторыми плагинами и настройками появляются каталоги, которые постоянно меняются и не несут смысла в бэкапе. Типичный пример — кэши. Часто это:

wp-content/cache;
отдельные папки кэш-плагинов.

Если ты исключаешь кэш, убедись, что после восстановления WordPress продолжит работать. Обычно кэш создаётся заново. Но иногда кэш — это не только скорость, а часть логики (реже). Поэтому исключения лучше вводить после теста восстановления.

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

Схема подписей и меток (tags)

restic поддерживает теги. Это удобно для поиска снимков. Например:

tag=files;
tag=db;
tag=full;

Тогда восстановление можно делать быстрее: не нужно «гадать», какой снимок нужен.

Автоматизация бэкапа базы данных: mysqldump и восстановление

База данных — самая чувствительная часть. С файлом проще: его можно вернуть как есть. С БД важно сделать логический дамп в корректный момент.

В большинстве случаев используется mysqldump. Он создаёт последовательность SQL-команд, по которой можно восстановить содержимое базы. При восстановлении важно, чтобы схема и данные легли корректно.

Экспорт с mysqldump: практичный рецепт

Для MySQL/MariaDB обычно делают дамп так:

блокировка таблиц на время дампа (опционально);
корректная кодировка;
исключение информации, которая не нужна или мешает (например, опциональные параметры).

Ниже пример общего подхода. Конкретные параметры подстрой под свою установку и версию MySQL/MariaDB:

mysqldump \
—single-transaction \
—quick \
—routines \
—events \
—triggers \
-u wpuser -p»${MYSQL_PWD}» \
—databases wpdbname \

/var/backups/wp-tmp/wpdb-$(date -u +%Y%m%dT%H%M%SZ).sql

Опция —single-transaction хорошо подходит для InnoDB: она делает консистентный дамп без жёсткой блокировки. Для MyISAM подход будет другим, но WordPress чаще всего работает с InnoDB.

Если у тебя несколько баз (редко для WordPress) — можно дампить их по списку. Но обычно достаточно одной базы WordPress.

Минимизируй риск: проверка дампа перед записью

Перед тем как отправлять дамп в удалённое хранилище:

проверь, что файл не нулевого размера;
проверь, что в дампе есть ожидаемые маркеры (например, CREATE TABLE или данные);
при возможности проверь, что команда завершилась успешно по коду возврата.

Простая проверка по размеру и статусу уже сильно снижает вероятность «мы залили пустой дамп, думали что всё ок».

Восстановление из дампа: как это работает

При восстановлении дампа тебе потребуется:

создать базу (если её нет);
загрузить SQL в базу через mysql.

Пример:

«`bash mysql -u wpuser -p»${MYSQL_PWD}» \ -e «CREATE DATABASE IF NOT EXISTS wpdbname CHARACTER SET utf8mb4 COLLATE utf8mb4unicodeci;»

mysql -u wpuser -p»${MYSQL_PWD}» \ wpdbname < /path/to/wpdb.sql «`

Параметры CHARACTER SET и COLLATE должны совпадать с тем, как была настроена исходная база. Если ты не знаешь точно, можно восстановить без принудительного charset, если в дампе прописаны нужные настройки. Снова: решает тест восстановления.

Альтернатива: wp-cli db export

Если у тебя есть wp-cli и он корректно настроен на сервере, db export может быть удобным способом сделать дамп в формате, который легче использовать вместе с остальными шагами. Но универсальным вариантом остаётся mysqldump, потому что он не зависит от состояния файлов WordPress.

Если WordPress частично сломан, wp-cli может не запуститься, а mysqldump всё равно сможет выгрузить данные, если учётные данные к БД верны.

Пошаговый план скриптов и расписаний: cron или systemd timers

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

зафиксировать проблему в логах;
не перетирать «всё подряд»;
продолжать работать при следующем запуске.

Практичный план:

подготовить скрипт для файловой части;
подготовить скрипт для дампа базы;
собрать их в единый job, который создаёт «снимок full»;
добавить prune (ротацию);
встроить проверку результата;
настроить расписание и алерты.

Ниже пример структуры и логики. Реальные пути и имена подставь свои.

Структура проекта

Допустим, создаём каталог:

/usr/local/sbin/wp-backup
/var/backups/wp-tmp
конфиг секретов — в /etc/wp-backup (права 600)

Скрипты:

backup-files.sh
backup-db.sh
backup-full.sh
restore.sh (отдельно, по необходимости)

Секреты (например, RESTICPASSWORD, MYSQLPWD) лучше хранить в файле, доступном только владельцу скриптов, и подхватывать его через source.

Пример скрипта для файловой части (restic)

«`bash

#!/usr/bin/env bash

set -euo pipefail

SITE_DIR=»/var/www/example.com»
TMP_DIR=»/var/backups/wp-tmp»
TS=»$(date -u +%Y%m%dT%H%M%SZ)»

restic env должен быть задан в окружении или через /etc/wp-backup/env

: «${RESTICREPOSITORY:?RESTICREPOSITORY not set}» : «${RESTICPASSWORD:?RESTICPASSWORD not set}»

mkdir -p «$TMP_DIR»

restic backup «$SITE_DIR» \ —tag «files» \ —tag «site-example» \ —exclude «/var/www/example.com/wp-content/cache» \ —exclude «/var/www/example.com/wp-content/*/cache» \ —verbose

restic snapshots —tag «files» —tag «site-example» —latest 1 >/dev/null «`

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

Пример скрипта для базы данных (mysqldump + restic)

«`bash #!/usr/bin/env bash set -euo pipefail

DB_NAME=»wpdbname» TMP_DIR=»/var/backups/wp-tmp» TS=»$(date -u +%Y%m%dT%H%M%SZ)» DUMPFILE=»$TMPDIR/${DB_NAME}-${TS}.sql»

: «${MYSQLPWD:?MYSQLPWD not set}» : «${RESTICREPOSITORY:?RESTICREPOSITORY not set}» : «${RESTICPASSWORD:?RESTICPASSWORD not set}»

mkdir -p «$TMP_DIR»

mysqldump \ —single-transaction \ —quick \ —routines \ —events \ —triggers \ -u wpuser -p»${MYSQL_PWD}» \ —databases «$DB_NAME» \ > «$DUMP_FILE»

if [ ! -s «$DUMP_FILE» ]; then echo «Dump file is empty: $DUMP_FILE» >&2 exit 1 fi

restic backup «$DUMP_FILE» \ —tag «db» \ —tag «site-example» \ —remove-after

rm -f «$DUMP_FILE» «`

Обрати внимание на —remove-after. Это сообщает restic удалить локальный файл после успешной отправки. Но мы и так удаляем его в конце. Оставь один механизм, чтобы не запутаться.

Полный job: связка файлов и базы + prune

«`bash #!/usr/bin/env bash set -euo pipefail

TS=»$(date -u +%Y%m%dT%H%M%SZ)»

files

/usr/local/sbin/wp-backup/backup-files.sh

/usr/local/sbin/wp-backup/backup-db.sh

prune (пример политики)

оставь определённый набор: за последние дни/недели/месяцы

restic prune \ —keep-daily 7 \ —keep-weekly 4 \ —keep-monthly 6 \ —tag «site-example» \ —verbose «`

Политику хранения подбирают по реальному объёму и требованиям. Лучше начать с умеренной политики и посмотреть рост репозитория за пару недель.

cron vs systemd timers

cron прост и массов. systemd timers удобнее для управления логами и зависимостей. В обоих случаях принцип одинаков: запуск по расписанию и логирование.

Для cron:

запускай job в ночное время, чтобы не конкурировать с нагрузкой;
не запускай два экземпляра одновременно (это можно решить через lockfile).

Для systemd timers:

можно добавить ConditionPathExists и другие проверки;
журналирование удобно смотреть через journalctl.

В обоих случаях полезно добавить lock, например через flock. Это предотвращает ситуацию «скрипт ещё не завершился, но cron уже запустил следующий».

Логи, уведомления и ретеншн

Логи нужны, чтобы быстро увидеть, что бэкап не прошёл. Минимально:

логируй stdout/stderr в файл или в systemd journal;
сохраняй код возврата.

Оповещения можно делать:

по почте (mailx, msmtp);
в чат (через webhook);
в мониторинг (Prometheus/Alertmanager).

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

Тест восстановления: часть автоматизации

Самая частая ошибка: сделать бэкап по расписанию и ни разу не восстановить на практике. Автоматизация должна включать тест в виде отдельной рутины:

раз в неделю или раз в две недели поднимаешь чистую копию VPS (или временную среду);
восстанавливаешь files и db из последнего удачного снапшота;
проверяешь страницу, вход в админку, загрузку медиа.

Это не «лишняя работа». Это способ гарантировать, что бэкап реально пригоден.

Восстановление WordPress из бэкапа на VPS

Восстановление нужно планировать так же аккуратно, как создание бэкапа. Иначе в момент аварии ты будешь решать проблемы «в реальном времени», где каждая ошибка стоит времени и денег.

Цель восстановления: получить рабочий WordPress и вернуть доступ к сайту.

Плейбук восстановления: файлы и база

Практичная последовательность:

Подготовь новую VPS или временную среду с теми же компонентами (web server, PHP, MySQL/MariaDB).
Восстанови файлы WordPress в каталог, где сайт ожидает ядро.
Восстанови базу данных.
Обнови wp-config.php, если менялись параметры подключения к БД.
Запусти web-сервер и проверь сайт.

При использовании restic восстановление обычно выглядит так:

находишь нужный snapshot;
делаешь restore в каталог;
затем загружаешь дамп в базу.

Примерный сценарий (упрощённо): «`bash

1) найти снапшот

restic snapshots —tag «site-example» —tag «db» —latest 1

2) восстановить дамп базы в tmp

restic restore latest —tag «db» —tag «site-example» —target /var/backups/wp-tmp/restore-db

3) восстановить файлы

restic restore latest —tag «files» —tag «site-example» —target /var/www/example.com «`

Дальше найдёшь восстановленный .sql и импортируешь его через mysql.

Если ты делал бэкап файлов целиком каталога /var/www/example.com, важно убедиться, что при восстановлении не затёрлись чужие конфиги. Лучше восстанавливать в пустой каталог или сначала сделать резервирование текущего состояния на время восстановления.

Типичные ошибки при восстановлении

1. Несовпадение версий PHP и расширений

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

2. Разные учётные данные БД в wp-config.php

Если ты восстановил файлы, но база подключается к старому имени пользователя/паролю, сайт будет ругаться на подключение. Решение: перед импортом БД проверь wp-config.php и соответствие.

3. Права на файлы uploads

После восстановления может быть другой владелец/права. Тогда пользователи не смогут загружать медиа. Решение: после восстановления выставь владельца и права на wp-content/uploads (точно под твою схему web server).

4. Неконсистентность дампа

Если дамп сделан без корректного подхода для текущего движка таблиц, могут быть странные ошибки. Решение: использовать —single-transaction для InnoDB и обязательно делать тест восстановления.

5. Смешивание файлов из разных снимков

Это бывает, когда ты восстанавливаешь файлы из одного snapshot, а дамп базы из другого. В итоге возникают «конфликты версий». Решение: делать единый job, который помечает файлы и базу как связанный full-снимок, или восстанавливать из одного общего набора.

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

Проверка должна быть короткой, но содержательной:

открыть главную и одну внутреннюю страницу (статьи/страницы);
войти в админку;
проверить загрузку медиа (хотя бы один тестовый файл);
проверить работу нескольких критичных плагинов.

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

Лайфхак: если у тебя в админке есть показатель здоровья сайта или ошибки, быстро открой логи PHP/web server и проверь 10–20 строк вокруг последних запросов после восстановления. Так ты заметишь проблему раньше, чем пользователи.

Практика безопасности и надёжности: шифрование, ключи, тестирование

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

Шифрование и управление ключами

RESTIC_PASSWORD (или аналог для borg/restic) должен быть:

одинаковым для доступа к репозиторию;
защищённым и не попадающим в историю команд, логи и репозитории.

Не передавай пароль бэкапа «в чат с коллегой» без безопасного канала. Лучше:

хранить секрет в переменных окружения через систему управления секретами (если есть);
или в защищённом конфиг-файле с правами 600.

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

Регулярные тесты восстановления

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

раз в 1–2 недели выбираешь последний успешный snapshot;
разворачиваешь тестовую среду (можно временно);
восстанавливаешь БД и файлы;
выполняешь чеклист проверки.

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

Защита от ransomware и ошибок оператора

Рансомваре и повреждение файлов — реальный сценарий. Для защиты:

храни бэкап оффсайт;
используй дедупликацию/шифрование на стороне клиента;
ограничь доступ к репозиторию.

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

Если используешь SSH в другой VPS, убедись, что ключи доступа защищены и не унаследованы от «универсальных» аккаунтов.

Контроль качества: метрики, алерты и регулярный аудит

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

Что логировать

Минимально логируй:

время начала и завершения job;
успешность файловой части;
успешность дампа БД;
размер репозитория/количество снапшотов (по возможности);
результат prune (сколько старых снапшотов удалено).

Если есть интеграция с мониторингом, дополнительно логируй:

длительность выполнения;
коды ошибок;
свободное место на диске (если локальные временные файлы завязаны на диск).

Минимальный набор алертов

Алерты должны предупреждать о проблемах до того, как они станут критичными:

не было успешного бэкапа за последние N часов;
job завершился с ошибкой;
репозиторий недоступен (ошибка авторизации, сетевые проблемы);
не удалось создать дамп БД.

На первом этапе достаточно двух алертов: «нет успеха» и «ошибка дампа/файлов». Этого обычно хватает, чтобы не пропустить проблему.

Регулярный аудит процесса

Раз в месяц сделай короткий аудит:

проверь, что бэкап создаётся по расписанию и соответствует политике хранения;
проверь, что нужные теги/snapshot формируются так, как ты их потом используешь при restore;
проверь доступы: не истёк ли ключ/пароль на стороне хранилища;
обнови зависимости (restic), если это безопасно и протестировано.

Аудит не должен занимать много времени. Но он закрывает «тихие» поломки, которые иногда происходят после обновлений ОС или изменения сетевых настроек.

Итог: как сделать бэкап WordPress на VPS автоматизированным и проверяемым

Надёжный бэкап WordPress на VPS — это связка из трёх вещей: что именно ты резервируешь (файлы + база), как ты это автоматизируешь (скрипты + расписание + ротация), и как ты подтверждаешь пригодность для восстановления (тест restore на практике).

Начни с рабочего сценария: файловая часть через restic (или другой инструмент снапшотов) и дамп базы через mysqldump, затем объединяй это в один job. После этого обязательно сделай тест восстановления на свежей среде и только потом включай расписание без ручного контроля.

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