Резервное копирование Drupal: пошаговая инструкция

Рабочая копия Drupal — это не только база данных: без каталога sites/default/files исчезнут изображения и документы, а без settings.php сайт не подключится к базе. За 20–40 минут вы соберёте локальный бэкап Drupal 10 или 11 на сервере с Composer и Drush, проверите его содержимое и подготовите восстановление.

Что понадобится до начала

• Drupal 10 или Drupal 11, установленный через Composer.
• Drush 13, доступный как vendor/bin/drush.
• SSH-доступ к серверу и права читать каталог проекта, базу данных и загруженные файлы.
• Свободное место под архивы. Резервная копия базы и файлов может занимать столько же, сколько рабочий сайт.
• Каталог backups вне публичного document root. В примерах Drupal находится в каталоге web; если у вас используется docroot, замените путь.

Важно. Команды ниже запускаются из корня Composer-проекта. Они не содержат паролей и токенов: Drush получает параметры подключения из настроек Drupal.

Сноска. Document root — каталог, который веб-сервер отдаёт браузеру. В Composer-шаблоне Drupal это обычно web; файлы за его пределами нельзя скачать обычным HTTP-запросом.

Пошаговое резервное копирование

1. Проверьте Drupal, Drush и свободное место

   Перейдите в корень проекта и выполните:

   cd /var/www/example.com
   vendor/bin/drush status
   df -h .

   В выводе должны быть версия Drupal, подключённая база данных и доступный Drush. Команда df -h покажет, хватит ли места для копии.

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

2. Создайте отдельный каталог с датой

   Каталог создаётся в корне проекта, но не внутри web. Это защищает копию от прямой раздачи веб-сервером.

   backup_dir="$(pwd)/backups/$(date +%F-%H%M)"
   mkdir -p "$backup_dir"
   printf '%s\n' "$backup_dir"

   Проверка. В терминале появится путь вроде /var/www/example.com/backups/2025-01-30-1420, а команда не завершится сообщением Permission denied.

3. Сохраните базу данных через Drush

   Drush использует те же параметры подключения, что и Drupal, поэтому не нужно вручную копировать пароль из settings.php. Выполните команду с переменной из предыдущего шага:

   vendor/bin/drush sql:dump --result-file="$backup_dir/database.sql"
   
   test -s "$backup_dir/database.sql" && ls -lh "$backup_dir/database.sql"

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

   Проверка. Команда test должна завершиться без вывода ошибки, а ls — показать ненулевой размер database.sql.

4. Заархивируйте загруженные файлы

   В стандартной Composer-структуре Drupal публичные загрузки лежат в web/sites/default/files. Архивируйте каталог с помощью tar:

   tar -czf "$backup_dir/files.tar.gz" \
     -C web sites/default/files
   
   tar -tzf "$backup_dir/files.tar.gz" | head

   Ключ -C web делает пути внутри архива относительными: при восстановлении не появится зависимость от конкретного пути на сервере.

   Проверка. В списке архива должны быть каталоги и файлы из sites/default/files, а команда не должна сообщать tar: sites/default/files: Cannot stat.

5. Сохраните настройки и приватные файлы

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

   cp web/sites/default/settings.php "$backup_dir/settings.php"
   chmod 600 "$backup_dir/settings.php"
   ls -l "$backup_dir/settings.php"

   Откройте settings.php и найдите параметр $settings['file_private_path']. Если он задан, приватный каталог нужно скопировать отдельно. Его путь зависит от конкретной установки, поэтому не подставляйте универсальный путь вроде private вслепую.

   Проверка. Файл settings.php существует и имеет права чтения только для владельца. Если приватный каталог используется, его содержимое также появилось в резервной копии.

6. Экспортируйте конфигурацию Drupal

   Конфигурация хранится в базе, но отдельный экспорт помогает увидеть изменения и перенести настройки между окружениями. Создайте каталог и выгрузите YAML через Drush:

   mkdir -p "$backup_dir/config"
   vendor/bin/drush config:export --destination="$backup_dir/config" --yes
   find "$backup_dir/config" -maxdepth 1 -type f | head

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

   Проверка. В каталоге есть файлы с расширением .yml, включая системную конфигурацию сайта.

7. Проверьте архивы и зафиксируйте контрольную сумму

   Соберите список созданных файлов и посчитайте SHA-256. Это позволит обнаружить повреждение при переносе на другой диск или сервер.

   find "$backup_dir" -maxdepth 1 -type f -printf '%f %s bytes\n'
   sha256sum "$backup_dir"/* > "$backup_dir/SHA256SUMS"
   sha256sum -c "$backup_dir/SHA256SUMS"

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

Резервная копия считается рабочей только после восстановления на отдельной площадке. Файл, который однажды удалось создать, ещё не доказывает, что из него получится вернуть сайт.

Если не получилось

• vendor/bin/drush: No such file or directory. Вы запустили команду не из корня Composer-проекта или зависимости не установлены. Найдите каталог с vendor/bin/drush и повторите команду из него.
• Unable to connect to the database или SQLSTATE[HY000]. Сайт сам не подключается к базе либо у пользователя базы недостаточно прав на чтение. Сначала проверьте drush status, затем настройки подключения и доступность сервера базы.
• tar: ... Cannot stat. Установка использует другой document root или каталог файлов переопределён в настройках. Проверьте фактический путь и значение $settings['file_public_path'], затем повторите архивирование.
• Permission denied при создании дампа или копировании settings.php. У текущего SSH-пользователя нет прав на файл или каталог. Не запускайте всё от имени root автоматически: сначала уточните владельца проекта и настройте минимально необходимые права.
• Архив неожиданно пустой или слишком маленький. Команда могла завершиться с предупреждением, а оболочка продолжила выполнение. Проверьте размер файлов через ls -lh, содержимое через tar -tzf и контрольную сумму.

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

Поднимите копию сайта на тестовом сервере с той же или совместимой версией Drupal и PHP. Создайте пустую базу, импортируйте database.sql, распакуйте files.tar.gz в document root, верните settings.php и проверьте путь приватных файлов. После этого очистите кеш Drupal:

vendor/bin/drush cache:rebuild

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

Что делать дальше

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

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