Как сделать и проверить резервную копию базы перед миграцией

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

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

Почему копию нужно создавать до миграции

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

Резервная копия позволяет вернуться к известному состоянию, если миграцию нельзя безопасно отменить обычной командой. Откат структуры не всегда равен откату данных: во время неудачной операции могли измениться значения, последовательности, индексы или служебные объекты. В некоторых системах часть операций DDL поддерживает транзакции, а часть выполняется отдельно, поэтому рассчитывать только на автоматический rollback нельзя.

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

Что проверить до создания копии

Сначала определите тип базы данных, её версию, имя экземпляра и способ подключения. Для PostgreSQL, MySQL, MariaDB и SQLite используются разные инструменты резервного копирования и восстановления. Не следует применять команду от другой СУБД только потому, что она похожа по названию.

Проверьте следующие условия:

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

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

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

Проверить подходящий вариант можно на странице Beget.

Как создать логическую копию

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

Для PostgreSQL пример экспорта может выглядеть так:

pg_dump --format=custom --file=site-before-migration.dump имя_базы

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

Для MySQL или MariaDB часто используют логический дамп:

mysqldump --single-transaction --routines --events --triggers --databases имя_базы > site-before-migration.sql

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

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

Копия средствами хостинга

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

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

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

Перед настройкой откройте Beget и сверьте актуальные условия.

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

Как проверить, что копия пригодна

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

sha256sum site-before-migration.dump

Контрольная сумма подтверждает, что файл не изменился при копировании, но не доказывает, что база полностью восстанавливается. Для архивов PostgreSQL можно просмотреть перечень объектов:

pg_restore --list site-before-migration.dump

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

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

Результат проверки зафиксируйте: имя архива, контрольную сумму, время восстановления, версию СУБД и выявленные ограничения. Если восстановление не удалось, такую копию нельзя считать готовой к миграции.

Как подготовить и выполнить изменение

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

Безопасный порядок часто строится по принципу совместимости. Сначала добавляют новый столбец или таблицу, не удаляя старую структуру. Затем приложение выпускается с поддержкой обоих вариантов, данные постепенно переносятся, выполняется проверка, и только после этого устаревший объект удаляется отдельной миграцией. Такой подход уменьшает риск простоя при поэтапном обновлении нескольких экземпляров приложения.

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

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

Что делать при неудаче

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

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

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

Краткий чек-лист

Перед изменением структуры базы данных необходимо:

1. Определить СУБД, версию и состав объектов.
2. Остановить или учесть процессы, которые могут менять данные.
3. Создать свежую логическую копию или согласованный snapshot.
4. Сохранить архив в защищённом и независимом месте.
5. Проверить размер, завершение экспорта и контрольную сумму.
6. Восстановить копию в изолированной среде.
7. Проверить данные, индексы, ограничения и работу приложения.
8. Зафиксировать номер миграции и критерии остановки.
9. Выполнить изменение в согласованное окно.
10. Сохранить архив и журнал результата до окончания срока хранения.

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

Что почитать дальше

• MySQL или PostgreSQL: каких данных не хватает для выбора хостинга
• База данных n8n: когда нужен отдельный сервис, а когда хватит SQLite
• Как выбрать виртуальный сервер для сайта и приложения: критерии
• Какие данные сохранить после запуска сайта: карточка проекта
• Администрирование сайта после запуска: что проверять и кто отвечает

Обложка вдохновлена гравюрой Альбрехта Дюрера «Меланхолия I» (1514). Посмотреть оригинал в коллекции Метрополитен-музея.