Резервное копирование DLE: ошибки, из-за которых теряют сайт

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

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

Резервная копия DLE состоит как минимум из двух частей: базы данных и файлов сайта. Они дополняют друг друга, но не заменяют.

• База данных — статьи, категории, пользователи, комментарии, настройки, права доступа и часть данных модулей.
• Файлы сайта — движок, шаблоны, загруженные изображения, документы, плагины, дополнительные модули, .htaccess и конфигурация.
• Отдельно сохранённые секреты — доступ к хостингу, базе данных и панели администратора. Их не нужно класть в архив сайта или отправлять в облачный чат.

Для DLE особенно критичны каталоги с загрузками и файл engine/data/dbconfig.php. В нём находятся параметры подключения к базе. Не публикуйте этот файл и не добавляйте его в открытый репозиторий.

Термин: дамп базы данных — текстовый файл с командами, которые позволяют заново создать таблицы и записать в них данные.

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

Что подготовить до начала

Инструкция рассчитана на DLE 17.x и Linux-хостинг с MySQL или MariaDB. На DLE 18.x и других выпусках названия пунктов панели могут отличаться, но принцип тот же.

• доступ к панели хостинга или SSH;
• доступ к phpMyAdmin либо установленная команда mysqldump;
• свободное место минимум в два раза больше размера сайта и базы вместе;
• отдельное хранилище: другой сервер, объектное хранилище или компьютер, который не находится на том же хостинге;
• дата и время последнего успешного бэкапа, записанные в журнале или таблице.

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

Пошаговая схема резервного копирования

1. Зафиксируйте версию DLE и окружение. Запишите версию движка, PHP, MySQL или MariaDB, имя сайта и путь к каталогу. Это пригодится при восстановлении после сбоя.
   Проверка: у вас есть заметка, по которой другой администратор понимает, какой сайт и на каком сервере копировался.
2. Сделайте дамп базы данных. В панели хостинга можно использовать экспорт базы в phpMyAdmin. Для SSH подойдут клиентские утилиты MySQL или MariaDB. Команда ниже запускается из shell и запрашивает пароль интерактивно:

mysqldump --single-transaction --routines --events --triggers --default-character-set=utf8mb4 -h DB_HOST -u DB_USER -p DB_NAME > dle-database-2025-01-01.sql

Замените DB_HOST, DB_USER и DB_NAME на значения из конфигурации DLE. Дату в имени файла подставьте фактическую. Не вписывайте пароль после -p: так он может попасть в историю команд.
Проверка: команда завершилась без ошибки, файл дампа существует и не имеет нулевой размер.

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

tar -czf /backup/dle-files-2025-01-01.tar.gz -C /var/www site

Здесь /var/www — родительский каталог, а site — папка DLE. Пути замените на свои.
Проверка: архив существует, его размер не равен нулю, а список содержимого показывает каталоги engine, templates и папку с загрузками.

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

tar -tzf /backup/dle-files-2025-01-01.tar.gz | head -30

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

1. Скопируйте оба файла за пределы сервера. Оставлять архив только рядом с сайтом опасно: поломка диска, ошибка в панели или взлом затронет и сайт, и его копии.
   Проверка: дата и размер копии видны в независимом хранилище.
2. Проведите пробное восстановление. Разверните файлы и отдельную базу на тестовом поддомене или локальном сервере. Подключите копию базы через конфигурацию тестового DLE, проверьте вход администратора, статьи, изображения, комментарии и формы.
   Проверка: тестовая копия открывается, показывает контент и не выдаёт ошибки подключения к базе.

Частые ошибки новичков

Сохраняют только базу

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

Сохраняют только папку uploads

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

Перезаписывают старую копию

Если каждый новый архив получает имя backup.zip, ошибка при создании может незаметно уничтожить предыдущий рабочий файл. Используйте дату и храните несколько поколений. Минимальный практический набор — последняя копия и несколько более старых, но точное число зависит от частоты публикаций и допустимой потери данных.

Кладут архив в открытый каталог

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

Не проверяют восстановление

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

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

• «Access denied for user» — неверны имя пользователя, пароль или разрешения базы. Сверьте значения с engine/data/dbconfig.php, но не публикуйте этот файл.
• «Unknown database» — база с указанным именем не создана или имя отличается. Сначала создайте пустую базу в панели хостинга, затем импортируйте дамп.
• «MySQL server has gone away» — сервер оборвал большой импорт или соединение. Уточните лимиты хостинга, импортируйте дамп частями через панель или попросите администратора выполнить операцию на сервере.
• «No space left on device» — закончилось место. Удалите временные архивы только после проверки независимой копии и оставьте запас для распаковки.
• Архив распаковывается, но сайт показывает ошибку 500 — проверьте версию PHP, права на файлы, конфигурацию подключения к базе и совместимость модулей. Ошибка 500 сама по себе не указывает на одну конкретную причину.

Как понять, что схема подходит сайту

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

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

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

Сделайте первую пару «дамп базы плюс архив файлов», перенесите её на отдельное хранилище и проведите пробное восстановление на тестовом адресе. После этого зафиксируйте расписание, срок хранения нескольких поколений и ответственного за проверку. В продакшене следите за тремя показателями: дата последней успешной копии, размер архива и время восстановления.