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

Чтобы восстановить Drupal после сбоя, нужны как минимум дамп базы данных и пользовательские файлы сайта. На Drupal 10 и 11 их можно сохранить через Drush и обычный архиватор Linux; подготовка займёт несколько минут, но время создания копии зависит от размера базы и каталога файлов. Ниже — последовательность для сайта, который работает в Linux и доступен через командную строку.

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

Инструкция рассчитана на Drupal 10 или 11, установленный через Composer, и совместимую с вашей версией Drupal версию Drush. Команды запускаются из корневого каталога проекта в Bash. Перед работой проверьте версию Drush командой drush --version и убедитесь, что она поддерживает вашу версию Drupal: совместимость зависит от выпуска Drush. Drush должен находить сайт из текущего каталога.

Также нужны права на чтение каталога пользовательских файлов и запись в место, куда вы положите копию. Храните её вне публичного корня сайта: архив может содержать личные данные, а настройки сайта — чувствительную информацию. Проверьте, где Drupal хранит публичные и приватные файлы: приватный путь часто задают отдельно в настройках и он не обязательно находится в sites/default/files.

• Доступ к серверу по SSH и рабочая командная строка.
• Установленные Drupal и Drush, а также доступ к базе данных, настроенный для сайта.
• Свободное место вне веб-каталога: для дампа и архива может понадобиться место, сопоставимое с размером базы и файлов.
• Известный путь к каталогу приватных файлов, если сайт его использует.

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

Сделайте копию базы и файлов

Сначала перейдите в корень Drupal — туда, где находится файл composer.json. Создайте каталог для копии вне веб-каталога. В примере это $HOME/drupal-backups; замените путь, если на сервере домашний каталог не подходит для хранения больших файлов.

1. Создайте каталог с ограниченным доступом. Выполните команды:

   mkdir -p "$HOME/drupal-backups"
   chmod 700 "$HOME/drupal-backups"
   

   Права 700 оставляют доступ к каталогу владельцу. Проверка: команда ls -ld "$HOME/drupal-backups" показывает каталог с правами владельца для чтения, записи и входа.
2. Сохраните базу данных. Укажите полный путь к выходному файлу:

   drush sql:dump --result-file="$HOME/drupal-backups/database.sql"
   

   Drush возьмёт параметры подключения из конфигурации сайта. Проверка: файл database.sql существует и не пустой. Если команда завершилась ошибкой, не переходите к архивированию: сначала исправьте сообщение Drush о подключении или правах.
3. Заархивируйте публичные файлы. Для стандартного каталога Drupal выполните из корня проекта:

   tar -czf "$HOME/drupal-backups/public-files.tar.gz" -C web/sites/default files
   

   Этот путь подходит для типичной установки Composer, где веб-корень — каталог web. Если ваш веб-корень или путь к файлам другой, подставьте фактический путь. Проверка: архив есть, а команда tar -tzf "$HOME/drupal-backups/public-files.tar.gz" выводит список файлов.
4. Сохраните приватные файлы и синхронизируемую конфигурацию, если они есть. Найдите реальные пути в настройках сайта и настройках импорта конфигурации. Создайте отдельные архивы командой tar -czf, указав для каждого каталога его родительский путь через -C. Не угадывайте расположение приватных файлов и каталога конфигурации: они могут находиться вне проекта. Проверка — список содержимого каждого архива соответствует нужному каталогу.
5. Уберите копию с сервера. Скопируйте каталог резервных копий в отдельное хранилище, доступное только уполномоченным. Проверка: файлы открываются из места хранения, а не только остаются в домашнем каталоге сервера.

Что именно должно попасть в копию

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

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

Проверьте копию восстановлением

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

На тестовой среде подготовьте пустую базу и подключите Drush к нужному сайту. Команда ниже импортирует SQL-файл в настроенную базу; запускайте её только после проверки окружения и резервирования данных, которые там уже есть:

drush sql:cli < "$HOME/drupal-backups/database.sql"

Чтобы вернуть публичные файлы в стандартный каталог Composer-проекта, перейдите в корень проекта и распакуйте архив. Сначала убедитесь, что целевой каталог правильный: архив содержит путь files/.

tar -xzf "$HOME/drupal-backups/public-files.tar.gz" -C web/sites/default

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

Если команда не сработала

• Drush не находит сайт. Перейдите в корень проекта с composer.json. Если проект использует несколько сайтов, уточните у администратора правильный каталог и настройки выбора сайта; не запускайте дамп, пока не уверены, к какой базе подключён Drush.
• Ошибка подключения к базе. Проверьте доступность базы и настройки подключения сайта. Не публикуйте содержимое файла настроек и не вставляйте пароли в команду или журнал.
• «Permission denied» при архивировании. Текущий пользователь не может прочитать файлы или записать архив. Попросите выдать необходимые права или запустите операцию от учётной записи, предназначенной для обслуживания сайта; не решайте проблему открытием доступа всем пользователям.
• «No space left on device». На файловой системе закончился объём. Проверьте свободное место в каталогах источника и назначения, затем используйте разрешённое внешнее хранилище.
• Архив создан, но нужных файлов нет. Вероятно, указан не тот путь или приватные файлы лежат отдельно. Сверьте настройки сайта и список содержимого архива, после чего соберите копию заново.

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

Зафиксируйте, какие каталоги входят в резервную копию, где она хранится и кто имеет к ней доступ. Настройте регулярное создание копий в соответствии с тем, сколько данных сайт может потерять между резервированиями; период выбирайте по частоте обновлений и требованиям проекта, а не по универсальному совету. Отдельно проверяйте, что копирование завершается успешно, и периодически проводите тестовое восстановление. Обновление Drupal, Drush и расширений — отдельная задача: версии должны соответствовать конкретному проекту.