Перенос базы данных между серверами и версиями СУБД: как сделать без потери данных
Содержание 17 разделов
Что важно знать перед переносом продакшн-базы — от выбора метода до требований 187-ФЗ и 152-ФЗ
Рано или поздно с базой данных приходится что-то делать: переезжать на новый сервер или в облако, обновлять устаревшую версию СУБД, которая больше не получает патчей безопасности, либо вовсе менять СУБД — например, из-за ухода зарубежного вендора или требований по импортозамещению. Каждая из этих задач звучит просто («скопировать данные»), но на практике легко превращается в многочасовой простой сервиса, повреждённые индексы или тихо потерянные строки, которые обнаруживаются через месяц.
Материал будет полезен тем, кто планирует перенос базы данных: IT-руководителям, которые выбирают стратегию и оценивают риски, и разработчикам или администраторам, которым предстоит реализовать перенос технически. Разберём, чем отличаются виды миграции, какие есть инструменты и методы, что нужно учитывать российским компаниям и какие ошибки чаще всего приводят к проблемам.
Что вообще считается «миграцией базы данных»
Под общим термином «миграция базы данных» скрываются задачи разной степени сложности. Их принято делить по направленности.
Миграция хранилища переносит базу между серверами без изменения её логической модели. Миграция версии обновляет СУБД и требует проверки совместимости. Переход между разными СУБД затрагивает типы данных, SQL, процедуры, триггеры и расширения, а перенос при смене приложения дополнительно меняет бизнес-модель и связи между сущностями.
Также важно различать миграцию БД по масштабу изменений: полный перенос всей базы из источника в приёмник — например, из локальной инфраструктуры в облако, — и версионное обновление, когда база обновляется до новой версии СУБД для совместимости с приложением Такие виды миграции связаны либо с преобразованием хранимых данных в новый формат, либо с модернизацией ПО [2].
Для практики важнее не терминология, а то, что каждый из этих сценариев требует своего подхода к рискам и инструментам — дальше разберём их по отдельности.
Как проходит перенос технически
Перенос между серверами с той же СУБД
Это самый предсказуемый случай: версия СУБД не меняется, меняется только физическое или виртуальное окружение. Основная задача — перенести данные, схему, индексы и права доступа так, чтобы на новом сервере всё работало идентично старому, и корректно переключить на него приложения. Такой перенос описан, в частности, в документации ряда российских low-code и учётных систем: миграция базы данных позволяет перенести базу вместе с данными для той же СУБД, например с одного сервера Microsoft SQL Server на другой например, с одного сервера Microsoft SQL Server на другой [3].
Здесь риски в основном инфраструктурные: разная версия ОС, отличающиеся настройки кодировки и локали, сетевые ограничения, недостаточная производительность диска на новом сервере.
Переход между версиями одной СУБД
Здесь риск выше, потому что у большинства СУБД внутренний формат хранения данных меняется от версии к версии, и старые файлы данных нельзя просто скопировать в новую версию. На примере PostgreSQL, для которого этот процесс описан в официальной документации особенно подробно, для крупных релизов формат хранения данных подвержен изменениям, что усложняет обновление для крупных релизов формат хранения данных подвержен изменениям, что усложняет обновление [4]. Новые крупные версии, как правило, вводят и изменения, заметные пользователю, поэтому может потребоваться доработка кода приложения — все такие изменения перечисляются в примечаниях к выпуску, и особое внимание стоит уделять разделу про миграцию Новые крупные версии также типично вносят некоторые заметные пользователю несовместимости, поэтому могут потребоваться изменения в прикладном программировании [4].
PostgreSQL официально поддерживает три способа обновления между крупными версиями:
- pg_dump / pg_restore — логическая выгрузка и загрузка в новый кластер. Способ позволяет контролировать схему и преобразования, но продолжительность зависит от объёма базы, индексов и скорости восстановления. Для подготовки дампа используют утилиты совместимой новой версии и обязательно проверяют восстановление на тестовой площадке [4].
- pg_upgrade обновляет кластер PostgreSQL до новой major-версии без полного логического восстановления. Он сокращает окно работ, но требует совместимых бинарных версий, проверки расширений и отдельного контрольного запуска по официальной инструкции [5].
- Логическая репликация — способ обновления с минимальным простоем: новая версия СУБД разворачивается как подписчик и получает данные из старой в режиме, близком к реальному времени, после чего трафик переключается на неё. Логическая репликация не переносит автоматически схему, индексы и последовательности — их нужно создать на стороне подписчика заранее логическая репликация переносит только данные и не переносит схему, индексы, последовательности и ещё пару тонкостей [6].
Похожие принципы (логический дамп, бинарный upgrade, репликация) в том или ином виде используются и в других промышленных СУБД — конкретные инструменты и их названия стоит уточнять по документации нужной версии.
Переход между разными СУБД
Это самый трудоёмкий сценарий, потому что различаются не только форматы хранения, но и диалекты SQL, типы данных, синтаксис хранимых процедур и триггеров. Для перехода, например, с Oracle на PostgreSQL на рынке есть специализированные инструменты — самый известный из них — ora2pg, который анализирует структуру исходной базы и генерирует SQL-скрипты для загрузки в PostgreSQL, и не требует глубоких знаний Oracle кроме параметров подключения Ora2Pg создает скрипты SQL, которые можно загрузить в базу данных PostgreSQL... Этот инструмент прост в использовании и не требует обладания знаниями о базах данных Oracle, кроме способности указать параметры, необходимые для подключения к базе данных Oracle [7].
Автоматическая конвертация Oracle в PostgreSQL имеет пределы. Доля кода, которую удаётся преобразовать инструментом, зависит от количества PL/SQL-пакетов, триггеров, локальных функций, расширений и конструкций вроде CONNECT BY. Поэтому результат оценивают не общей процентной цифрой, а инвентаризацией объектов, пробной конвертацией и перечнем кода, который потребуется переписать и протестировать [8].
Это значит, что переход между разными СУБД правильнее планировать не как разовый скрипт, а как отдельный проект с аудитом кода, тестированием и этапом ручной доработки — параметрами, которые нельзя надёжно оценить без предварительного технического обследования.
Российская специфика: когда выбор СУБД — это не только техника
Реестр отечественного ПО и импортозамещение
Для многих российских компаний вопрос миграции связан не только с обновлением версии, но и с уходом от иностранных СУБД. В Едином реестре российского программного обеспечения зарегистрированы, в частности, СУБД на основе PostgreSQL — Postgres Pro и РСУБД ЛИНТЕР В реестр российского ПО были включены: РСУБД ЛИНТЕР (5.9, 6.0, 6.1, БАСТИОН) и СУБД Postgres Pro [9]. Postgres Pro продвигается разработчиком и партнёрами как решение для замены Oracle, MS SQL Server и других зарубежных СУБД, соответствующее требованиям реестра российского ПО Postgres Pro входит в реестр российского ПО (рег. № 104) — подходит для импортозамещения Oracle, MS SQL и других зарубежных СУБД [10]. Технически такой переход — частный случай перехода между разными СУБД, описанного выше, включая перенос хранимого кода и работу с ora2pg или его коммерческим аналогом.
Требования 187-ФЗ для объектов КИИ
Если система, к которой относится база данных, признана значимым объектом критической информационной инфраструктуры (КИИ) — например, речь идёт об информационных системах в здравоохранении, энергетике, транспорте, финансовом секторе и ряде других отраслей, — вопрос выбора СУБД регулируется отдельно. Закон определяет субъектов КИИ как госорганы, российские юрлица и предпринимателей, которым принадлежат информационные системы и автоматизированные системы управления в перечисленных сферах к субъектам КИИ относятся госорганы, российские юрлица и предприниматели, которым принадлежат информационные системы (ИС), интеллектуальные транспортные системы (ИТС) и автоматизированные системы управления (АСУ) в сфере здравоохранения, науки, транспорта, связи, энергетики, госрегистрации прав на недвижимость, в финсекторе, ТЭКе, атомной, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности [11].
Требования 187-ФЗ и связанные планы перехода применяют к организациям и системам, которые относятся к субъектам и значимым объектам критической информационной инфраструктуры. Для обычной коммерческой системы выбор СУБД определяется задачей, договорными требованиями и собственной моделью угроз. Если база обслуживает объект КИИ, применимость, сроки и требования к программному обеспечению сверяют с официальными актами и документами ответственного подразделения.
Локализация персональных данных по 152-ФЗ
Если в базе данных обрабатываются персональные данные граждан РФ, при миграции нужно отдельно учитывать требования о локализации. Закон обязывает при сборе персональных данных обеспечивать запись, систематизацию, накопление, хранение и извлечение персональных данных граждан РФ с использованием баз данных, физически расположенных на территории России оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации [14]. Требование касается именно первичного сбора и хранения данных, а не любой обработки в целом.
Это особенно важно учитывать, если миграция сопровождается переездом инфраструктуры в облако, — нужно заранее убедиться, что новый сервер физически размещён на территории РФ, если в базе есть персональные данные граждан России.
Варианты реализации переноса
По степени влияния на работающую систему выделяют несколько подходов к переносу.
Простой перенос («в одну итерацию»). База выгружается целиком, переносится и загружается на новом сервере, после чего трафик переключается. Подходит для небольших баз и некритичных сервисов, где допустим технологический простой.
Непрерывная миграция. Данные копируются в фоне, пока старая база продолжает обслуживать нагрузку, а трафик переключается на новую базу только после того, как данные синхронизированы Перенос происходит без остановки системы: данные копируются в фоне, затем трафик переключается на новую базу [15]. Такой подход используют там, где критична каждая минута простоя — например, в крупных интернет-магазинах и банках Так делают в крупных интернет-магазинах и банках, где критична каждая минута простоя [15]. Технически на PostgreSQL это чаще всего реализуется через логическую репликацию.
Постепенная миграция (по частям). Данные переносятся не все сразу, а частями, что занимает больше времени, но безопаснее — в любой момент можно откатить процесс при возникновении ошибки Данные переносятся не все сразу, а частями. Этот способ дольше, но безопаснее, потому что можно в любой момент откатить процесс, если возникла ошибка [15].
Dual-write и постепенный backfill. Приложение временно пишет одновременно в старую и новую базу, пока происходит перенос исторических данных, а затем источник истины переключается на новую систему — паттерн, часто применяемый как раз для минимизации риска несогласованности при сложных миграциях с изменением схемы.
Выбор конкретного варианта зависит не от предпочтений исполнителя, а от допустимого простоя (RTO), допустимой потери данных (RPO) и того, насколько сильно меняется схема и логика при переносе.
Практические этапы миграции
Вне зависимости от конкретного метода, разумный процесс переноса базы данных обычно включает такие шаги.
- Аудит исходной базы. Разбор структуры: таблицы, поля, типы данных, зависимости, объём, используемые расширения и хранимый код. На этом шаге определяется, что действительно нужно переносить, а что можно архивировать или не переносить вовсе.
- Выбор целевой платформы и метода переноса. Тот же сервер или другая СУБД, локальная инфраструктура или облако, простой перенос или перенос без остановки — с учётом требований к простою и регуляторных ограничений, разобранных выше.
- Подготовка тестовой среды. Разворачивается копия целевой системы, в неё загружается часть или полный слепок реальных данных, максимально приближенный к боевому окружению.
- Прогон миграции на тестовой копии. Перенос выполняется в тестовом контуре, проверяется целостность данных, работоспособность приложений и производительность запросов.
- Подготовка и проверка плана отката. План отката прописывается и тестируется ещё до старта основной миграции, а не придумывается по ходу дела, если что-то пойдёт не так Сделайте и проверьте план отката. Пропишите, как вернуться назад, если что-то пойдёт не так. Проверьте этот сценарий до запуска [16].
- Перенос данных в продакшн-окружение согласно выбранному методу — с фиксацией контрольных точек, по которым можно сверить целостность.
- Переключение и мониторинг. После переноса важно контролировать ошибки и скорость работы новой базы, и только убедившись, что всё стабильно, отключать старую Переключение и мониторинг. Контроль за ошибками и скоростью работы. Если всё хорошо, старую базу можно отключать [15].
Ограничения, ошибки и риски
Большая часть проблем при миграции связана не с самими инструментами переноса, а с организацией процесса.
Отсутствие чёткого плана и распределения ответственности. Один из типичных сценариев провала — когда всю миграцию берёт на себя один человек без заранее продуманного плана с этапами и дедлайнами всю работу взвалили на одного человека (самого себя) и не продумали до старта четкий план миграции с этапами и дедлайнами [17]. Разделение миграции на этапы обязательно вне зависимости от того, происходит перенос бесшовно или с небольшим простоем Разделять миграцию на этапы обязательно — неважно, куда и как вы переносите инфраструктуру, бесшовно это происходит или с небольшим даунтаймом [17].
Непроверенные резервные копии. Если перед миграцией есть сомнения в исправности бэкапов, миграцию лучше отложить до решения этой проблемы, а не начинать перенос «на удачу» — последствия при сбое могут быть серьёзными.
Пропуск тестирования на копии данных. Пропуск проверки на тестовой среде — частая причина потери данных при миграции; лучше потратить время на тесты заранее, чем потом восстанавливать всё с нуля Пропуск проверки может привести к потере данных. Лучше потратить лишний час на тесты, чем потом восстанавливать всё заново [15].
Недооценка объёма ручной доработки при смене СУБД. Как отмечалось выше, автоматизированный перенос кода с одного диалекта SQL на другой закрывает часть, но не всю задачу — оставшуюся часть кода нужно закладывать в план как отдельный этап с ручным тестированием, а не как погрешность.
Отсутствие сверки целостности после переноса. Без явного контроля версий и истории изменений сложно понять, какое конкретно действие вызвало сбой, если он произойдёт: миграция без прослеживаемости истории превращается в чёрный ящик, где при ошибке невозможно понять, какое изменение структуры её вызвало Без этого миграция превращается в «черный ящик». При возникновении ошибки невозможно понять, какое изменение структуры вызвало сбой [18].
Игнорирование шифрования при передаче данных. Для чувствительных данных — например, персональных данных или финансовой информации — важно, чтобы передача между исходным и целевым сервером шла по защищённому каналу, а не в открытом виде.
Как выбрать подходящий вариант
Единого «правильного» способа миграции не существует — выбор зависит от нескольких факторов, которые стоит явно проговорить до начала проекта:
- Допустимый простой. Если сервис не может останавливаться даже на короткое время, нужно рассматривать логическую репликацию или dual-write, а не простой дамп/restore.
- Масштаб изменений. Перенос между серверами с той же СУБД — это в первую очередь инфраструктурная задача. Обновление версии СУБД требует изучения списка несовместимостей конкретного релиза. Переход между разными СУБД — это полноценный проект с аудитом кода.
- Регуляторный контур. Если система относится к значимым объектам КИИ или обрабатывает персональные данные граждан РФ, выбор целевой СУБД и площадки размещения нужно сверять с требованиями 187-ФЗ и 152-ФЗ ещё на этапе планирования, а не постфактум.
- Наличие ресурсов на тестирование. Чем сложнее миграция, тем больше времени должно закладываться на прогон в тестовой среде и на ручную доработку кода, который не переносится автоматически.
Часто для обновления версии в рамках одной и той же СУБД достаточно штатных инструментов и внимательного администратора. А вот переход на другую СУБД, особенно с переносом хранимой логики, обычно требует отдельного технического обследования и, как правило, помощи специалистов с опытом именно такой миграции.
Как может помочь «Пятый фактор»
Перенос базы данных редко сводится к одной команде копирования — обычно это связка из аудита текущей схемы, оценки регуляторных требований, выбора метода переноса и последующей интеграции приложений с новой базой. Команда «Пятого фактора» может изучить текущую инфраструктуру и структуру данных, оценить возможные варианты переноса — от простого обновления версии до перехода на другую СУБД, — и помочь с разработкой плана миграции, тестированием или консультацией по конкретным техническим и регуляторным вопросам. Если для задачи достаточно правильно настроенных штатных инструментов конкретной СУБД без привлечения внешней разработки — это тоже стоит проговорить на этапе аудита, чтобы не усложнять проект без необходимости.
Вывод
Перенос базы данных — это управление рисками, а не разовая техническая операция. Для одной и той же СУБД современные инструменты — логические дампы, pg_upgrade-подобные утилиты, логическая репликация — закрывают большинство сценариев с предсказуемым результатом. При переходе между разными СУБД к техническим рискам добавляется объём ручной доработки кода, который никакой инструмент не автоматизирует полностью. А для российских компаний к этому добавляется ещё один слой — необходимость сверять выбор СУБД и место хранения данных с требованиями по импортозамещению, безопасности КИИ и локализации персональных данных. План, тестовая среда и проверенный откат снижают риск сильнее, чем выбор конкретного инструмента.
Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.
Источники
[1] mkskom.ru — Миграция данных: что такое миграция базы данных и зачем это нужно — https://mkskom.ru/blog/migraciya-dannyh
[2] timeweb.cloud — Миграция базы данных: обзор — https://timeweb.cloud/blog/migraciya-bazy-dannyh-kak-sdelat
[3] mytessa.ru — Миграция базы данных и файлов — TESSA 3.5 — https://mytessa.ru/docs/3.5/adm/admin/migration/
[4] postgresql.org — Documentation: Upgrading a PostgreSQL Cluster — https://www.postgresql.org/docs/current/upgrading.html
[5] postgresql.org — Documentation: pg_upgrade — https://www.postgresql.org/docs/current/pgupgrade.html
[6] habr.com (OTUS) — Миграции Postgres с использованием логической репликации — https://habr.com/ru/companies/otus/articles/958718/
[7] learn.microsoft.com — Oracle в Базу данных Azure для PostgreSQL: Руководство по миграции Ora2Pg — https://learn.microsoft.com/ru-ru/azure/postgresql/migrate/how-to-migrate-oracle-ora2pg
[8] ibs-training.ru — Миграция с Oracle на PostgreSQL: подводные камни и инструменты для перехода — https://ibs-training.ru/about/news/Migratsiya_s_Oracle_na_PostgreSQL_podvodnye_kamni_i_instrumenty_dlya_perekhoda/
[9] fap.sbras.ru — В реестр российского ПО включены СУБД на базе PostgreSQL: ЛИНТЕР и Постгрес Про — https://fap.sbras.ru/node/4437
[10] migsoft.ru — Postgres Pro — российская СУБД, купить лицензию — https://migsoft.ru/postgrespro
[11] interfax.ru — Минцифры предложило сроки перевода значимых объектов КИИ на российское ПО — https://www.interfax.ru/russia/1088934
[12] asta74.ru — Изменения 187-ФЗ о переходе субъектов критической инфраструктуры на отечественное ПО и ПАК — https://asta74.ru/news/izmeneniya-187-fz-o-perekhode-subektov-kriticheskoy-infrastruktury-na-otechestvennoe-po-i-pak
[13] soc.ussc.ru — Укрепление безопасности КИИ: детальный анализ изменений 187-ФЗ — https://soc.ussc.ru/news/187_fz
[14] wcr-consulting.com — Локализация персональных данных по 152-ФЗ: требования — https://wcr-consulting.com/blog/2026/03/13/lokalizaciya-baz-dannyh-personalnyh-dannyh/
[15] practicum.yandex.ru — Миграция базы данных: как сделать, примеры, инструменты для миграции — https://practicum.yandex.ru/blog/migraciya-baz-dannyh/
[16] kt-team.ru — Миграция данных: типовые проблемы и решения — https://www.kt-team.ru/blog/data-migration-common-issues-and-solutions
[17] selectel.ru — Разбираем частые ошибки при миграции инфраструктуры — https://selectel.ru/blog/migration_errors/
[18] vc.ru — Изучаем миграцию базы данных: цели, примеры и пошаговая инструкция — https://vc.ru/dev/3001766-migratsiya-bazy-dannykh-tseli-primery-i-poshagovaya-instruktsiya