MAATRIX / Блог / Миграция базы данных на VPS без потери данных

Миграция базы данных на VPS без потери данных

Блог MAATRIX · 2026-07-07

Перенос базы на новый VPS кажется рискованным, но при аккуратном плане простой сводится к минутам. Разберём проверенный порядок: снять дамп, перенести файл, восстановить на новом сервере, сверить данные и переключить приложение. Команды приведены для PostgreSQL и MySQL.

Содержание

  1. План миграции и оценка простоя
  2. PostgreSQL: dump и restore
  3. MySQL: dump и restore
  4. Проверка целостности
  5. Переключение и откат
  6. Куда переносить базу

План миграции и оценка простоя

['Миграция БД — это последовательность из пяти шагов, и порядок здесь важнее скорости.', '
  • Подготовка — поставить ту же мажорную версию СУБД на новый VPS.
  • Дамп — снять согласованную копию данных.
  • Перенос — доставить дамп на новый сервер.
  • Восстановление — загрузить данные и проверить целостность.
  • Переключение — перевести приложение на новую БД.
', 'Совпадение мажорных версий критично: восстановить дамп из PostgreSQL 16 в 14 не выйдет. Проверьте версию источника заранее:', '
psql --version   # PostgreSQL\nmysql --version  # MySQL/MariaDB
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для базы данных

PostgreSQL: dump и restore

['Для переноса используют pg_dump. Формат custom (-Fc) удобнее обычного SQL: он сжат и позволяет восстанавливать параллельно.', '
# на старом сервере\npg_dump -Fc -U dbuser -d dbname -f dbname.dump
', 'Переносим файл на новый VPS по SSH:', '
scp dbname.dump user@NEW_SERVER_IP:/tmp/
', 'На новом сервере создаём базу и восстанавливаем в несколько потоков — на многоядерном VPS это заметно быстрее:', '
sudo -u postgres createdb dbname\npg_restore -U dbuser -d dbname -j 4 /tmp/dbname.dump
', 'Флаг -j 4 распараллеливает загрузку по четырём воркерам, что хорошо ложится на ядра AMD EPYC и NVMe.']

MySQL: dump и restore

['В MySQL/MariaDB роль pg_dump играет mysqldump. Ключ --single-transaction снимает согласованную копию InnoDB без блокировки таблиц.', '
# на старом сервере\nmysqldump --single-transaction --routines --triggers \\\n  -u dbuser -p dbname | gzip > dbname.sql.gz
', '
scp dbname.sql.gz user@NEW_SERVER_IP:/tmp/
', 'На новом сервере создаём базу и заливаем дамп:', "
mysql -u root -p -e 'CREATE DATABASE dbname CHARACTER SET utf8mb4;'\ngunzip < /tmp/dbname.sql.gz | mysql -u root -p dbname
", 'Ключи --routines и --triggers важны: без них хранимые процедуры и триггеры не попадут в дамп, и приложение сломается уже после переключения.']

Проверка целостности

['Перед переключением сверьте, что данные приехали полностью. Самый простой контроль — число строк в ключевых таблицах на обоих серверах.', "
# PostgreSQL\npsql -U dbuser -d dbname -c 'SELECT count(*) FROM orders;'\n# MySQL\nmysql -u dbuser -p dbname -e 'SELECT COUNT(*) FROM orders;'
", 'Также проверьте, что создались индексы, последовательности (sequences) и права пользователей — их часто забывают. Убедитесь, что новое приложение подключается и выполняет тестовый запрос без ошибок.', 'Отдельно сверьте размер базы и число объектов — это быстрый способ заметить недокачанные данные. В PostgreSQL текущее значение sequence легко отстаёт, если данные заливались в обход обычного INSERT, поэтому после restore стоит выровнять счётчики, иначе первые же вставки упадут на конфликте первичного ключа.', '
# PostgreSQL: размер базы и список таблиц\npsql -U dbuser -d dbname -c "SELECT pg_size_pretty(pg_database_size(\'dbname\'));"\npsql -U dbuser -d dbname -c \'\\dt\'
']

Переключение и откат

['Чтобы простой был минимальным, на время миграции переведите приложение в режим только чтения или короткое обслуживание, снимите финальный дамп, восстановите и поменяйте строку подключения.', '
# пример строки подключения в .env\nDATABASE_URL=postgres://dbuser:pass@NEW_SERVER_IP:5432/dbname\nsudo systemctl restart myapp
', 'Старый сервер не удаляйте сразу — оставьте его на несколько дней как путь отката. Если на новой БД всплывёт проблема, вы вернёте строку подключения назад за минуту.', '
  • Разные мажорные версии — restore не пройдёт.
  • mysqldump без --routines — потеряны процедуры и триггеры.
  • Забыли про права и sequences — приложение падает после переключения.
  • Сразу снесли старый сервер — некуда откатиться.
']

Куда переносить базу

['Целевой VPS должен быть быстрее и надёжнее прежнего, иначе миграция теряет смысл. NVMe + AMD EPYC у MAATRIX ускоряют и восстановление дампа, и последующую работу базы, а локации UK и США дают выбор под аудиторию. Оплата картой РФ, СБП, криптой или токеном MAAT удобна при переезде с зарубежного провайдера, ежедневные бэкапы страхуют уже на новом месте, а root-доступ и быстрый запуск позволяют развернуть окружение за считанные минуты.']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать VPS для базы данных

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

Как снизить простой при миграции?

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

Нужна ли одинаковая версия СУБД?

Мажорная версия должна совпадать или быть новее на приёмнике. Восстановить дамп из более новой версии в старую нельзя; для апгрейда используют pg_upgrade или логический дамп.

Как быстро откатиться, если что-то пошло не так?

Не удаляйте старый сервер сразу. Верните прежнюю строку подключения в конфиге приложения и перезапустите его — откат займёт меньше минуты.

Читайте также