phpMyAdmin сохранит базу, но не весь WordPress

Я часто разбираю резервные копии после аварии, и phpMyAdmin в этой истории обычно сделал только одну часть работы: выгрузил базу WordPress. В ней нет каталога сайта с темами, плагинами и загрузками. Для восстановления нужны оба компонента, сохранённые примерно на один момент, и проверка на тестовой площадке. Ниже — рабочий порядок без обещаний «одной кнопкой спасти всё».

Что именно сохраняет экспорт phpMyAdmin

phpMyAdmin — веб-интерфейс для работы с базами данных. Если выбрать базу WordPress и экспортировать её в SQL, получится набор инструкций для создания таблиц и записи данных. В базе находятся записи, страницы, комментарии, настройки и часть данных плагинов. Это ценно, но это не весь сайт. Сам экспорт не содержит каталог WordPress с темами, плагинами и загрузками. Официальное руководство WordPress прямо разделяет резервную копию на файлы и базу: для полного восстановления нужны оба компонента. SQL-файл — один из элементов комплекта, а не готовый сайт в коробке.

Префиксы таблиц и сериализованные значения — не повод объявлять phpMyAdmin непригодным. Экспортёр переносит данные базы; он не обязан понимать бизнес-логику WordPress. При обычном восстановлении на совместимую базу значения остаются данными. Проблемы начинаются при выборочном экспорте не тех таблиц, повреждённом или неполном файле, неверной базе назначения, ограничениях импорта либо ручной замене адресов сайта без инструмента, который понимает сериализацию. Само наличие строки «wp_» в дампе не доказывает поломку. Ирония простая: текстовый файл не знает, где лежит сайт, — потому что никто не добавил туда файлы.

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

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

• База: записи и настройки
• Файлы: темы, плагины, загрузки
• Сохраняйте обе части комплекта

Почему импорт проходит, а сайт всё равно не работает

Я считаю успешным импортом только факт, что сервер базы принял SQL-команды без фатальной ошибки. Лишь, что сервер базы принял SQL-команды без фатальной ошибки. Он не подтверждает, что восстановлены все таблицы, файлы и настройки сайта. Если импорт оборвался, часть команд могла выполниться до ошибки. Если вы импортировали дамп не в ту базу, WordPress будет читать другое содержимое. Если в wp-config.php указано старое имя базы, пользователь или пароль, приложение не подключится к восстановленной базе. Параметры подключения и префикс таблиц задаются конфигурацией WordPress; при переносе их нужно сверить с целевой средой, а не менять наугад.

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

Смена версии MySQL или MariaDB сама по себе не означает, что дамп несовместим. Важны конкретные версии, кодировки, режимы SQL, используемые типы данных и права целевого пользователя. Поэтому формулировка «обновите сервер — и ошибка исчезнет» слишком груба: обновление может добавить новые переменные. Сначала зафиксируйте полный текст ошибки, проверьте, завершился ли экспорт, и сопоставьте версии источника и назначения. Для крупного файла используйте метод импорта, подходящий лимитам хостинга. Не удаляйте таблицы действующего сайта до проверки копии и не импортируйте поверх рабочей базы без отдельного плана отката.

Часть данных WordPress хранится в сериализованном формате PHP. Если заменить адрес сайта обычной массовой подстановкой в SQL, длина строки внутри сериализованного значения может перестать совпадать с записанным числом символов. Тогда приложение может неверно прочитать это значение. Это отдельный риск ручного поиска и замены, а не доказательство того, что экспорт из phpMyAdmin «не учитывает сериализацию» и портит базу. Для миграции адреса используйте совместимый с WordPress инструмент, который корректно обрабатывает сериализованные данные, или поручите замену специалисту. Сначала испытайте результат на копии: продуктивная база — неподходящее место для эксперимента.

Полная копия: база, файлы и настройки

Я собираю резервную копию как комплект. В него входят экспорт базы, каталог wp-content (темы, плагины, загрузки и другие данные), wp-config.php и остальные файлы проекта, которые менялись вручную. В типичной установке стоит сохранить весь каталог WordPress: тогда не придётся вспоминать, какой файл ядра был изменён или какой дополнительный каталог лежал рядом. Отдельно учтите файлы за пределами корня сайта, если они участвуют в работе проекта. Не считайте .htaccess обязательным для всех серверов: он используется в конфигурациях Apache, но на другом веб-сервере правила могут находиться в другом месте.

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

Перед копированием определите, где лежит база и какие файлы относятся к этой установке. Экспортируйте все нужные таблицы, скачайте файлы и сохраните комплект под понятным именем с датой и временем. Не оставляйте единственную копию на том же сервере, который она должна спасать. Руководство WordPress советует держать не менее 3–5 последних копий в разных местах. Храните их, например, в отдельном хранилище и на контролируемом локальном носителе. Доступ к архиву ограничьте, а конфигурационные файлы, содержащие секреты подключения, храните защищённо. Несколько копий в одной папке на одном диске — это один сценарий отказа, размноженный на несколько файлов.

После переноса на новый сервер восстановите файлы и импортируйте базу в предназначенную для сайта базу данных. Затем проверьте имя базы, пользователя, пароль, адрес сервера БД и префикс таблиц в wp-config.php. Права пользователя должны позволять WordPress работать с базой. Сначала проверьте сайт на тестовом домене или закрытой среде: главную страницу, вход в админку, несколько записей, изображения, формы и ключевые функции плагинов. Если менялся домен, отдельно проверьте ссылки и сериализованные настройки. Свежую копию ядра можно использовать для ремонта повреждённых файлов ядра, но она не заменяет резервную копию всей установки и не гарантирует совпадение состояния файлов с базой.

• Экспорт базы данных
• Копия файлов проекта
• Отдельное хранилище и несколько поколений

Автоматизация полезна только вместе с контролем

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

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

Экспорт базы можно делать через phpMyAdmin, консоль или средство хостинга; полный набор часто удобнее собирать резервным решением, которое поддерживает и базу, и файлы. Например, документация BackWPup описывает ручное восстановление с импортом базы в phpMyAdmin и отдельной загрузкой файлов, а также собственный сценарий полного восстановления в Pro. Значит, phpMyAdmin может быть одним из способов вернуть базу, но утверждение, что этот плагин обязательно требует phpMyAdmin, неверно. Выбирайте путь, который реально доступен в вашей версии продукта и на вашем тарифе, и заранее разберитесь, что входит в архив.

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

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

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

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

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

Заранее запишите короткую инструкцию: где лежат архивы, какой набор относится к сайту, как получить доступ к хранилищу, какие параметры базы нужны и кто принимает решение об откате. Ограничьте доступ к инструкции и секретам, но не делайте её недоступной в момент аварии. Назначьте ответственного за проверку уведомлений. Если организация не может безопасно восстановить сайт сама, попросите специалиста один раз провести тестовый прогон и оставить понятные шаги. Здесь не нужен театр про «катастрофу, которая обязательно случится». Нужен проверяемый ответ на простой вопрос: если сервер исчезнет сегодня, где взять комплект и сколько действий отделяет его от работающего сайта?

• Восстановите копию в тестовой среде
• Проверьте журнал и функции сайта
• Обновите инструкцию после прогона

Частые вопросы