Перенос данных

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

Когда нужно переносить данные

Зачем и почему приходится реструктурировать и переносить хранилища информации? Вот несколько распространенных причин:

1. Миграция с переносом данных из-за требований законодательства или смены владельца проекта. Например, после вступления в силу 152-ФЗ, который обязывает хранить персональные данные на территории России, многие компании перенесли клиентскую информацию в российские облака.
2. Радикальная смена архитектуры системы хранения данных. Например, смена типа СУБД.
3. Масштабная чистка или модификации хранимых данных. Например, применение алгоритма шифрования ко всем файлам.
4. Получение преимуществ от перехода на новые технологии. Например, перенос СУБД на облачные базы данных с подключением автоматических бэкапов и системы восстановления после сбоев - чтобы на новый уровень поднять безопасность системы хранения информации и удобство ее использования.
5. Повышение скорости работы систем хранения данных и/или снижение стоимости эксплуатации хранилищ за счет внедрения преднастроенных облачных решений.

Первый этап миграции данных: проводим инвентаризацию и делаем бэкапы

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

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

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

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

Важно!

Дальше можно двигаться только после того, как проведена полная инвентаризация и налажено копирование всего важного и нужного.

Второй этап: планируем миграцию данных

Теперь нужно спланировать фронт работ. Для этого ранжируем все источники информации по важности - от самых важных к менее важным.

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

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

• Если вы переносите файлы с дисков серверов на хранение в S3-хранилище - после миграции нужно проверить доступность и целостность всех записей в новой системе.
• Если вы меняете тип СУБД (допустим, с MySQL на PostgreSQL), то протестируйте не только корректность вставки и удаления записей в БД, но и правильность работы коннектов в базу под нагрузкой, когда у вас запущено несколько копий приложений.

Конечно, у вас должны быть тесты на основные компоненты приложения, но после смены архитектуры потребуется некоторые дополнительные проверки данных.

Третий этап: делаем тестовую миграцию данных

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

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

Важно!

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

Четвертый этап: мигрируем данные

После всех предварительных проверок и подготовки можно начинать настоящий перенос:

1. Не забудьте уведомить клиентов и пользователей о технических работах.
2. Постарайтесь выключить все серверы и сервисы, которые можно, так как в процессе миграции в них не должны появляться новые данные. Те системы, которые выключить нельзя, мигрируют в горячем режиме. Например, через репликацию, поддерживая одновременно по одной копии каждого сервиса в старом и новом дата-центре. Для горячей миграции уже на этом шаге нужно поднять две копии сервисов.
3. Сделайте актуальные бэкапы всей информации сразу после выключения, перед началом переноса.
4. Двигайтесь строго по плану, который составили заранее. Используйте только те инструменты миграции, которые выбрали и опробовали, не отступайте от сценария.
5. После переноса перенастройте все системы на работу с новыми данными, запустите и протестируйте работу всех приложений.
6. После этого можно снова запустить сервисы и сделать их доступными для пользователей, но продолжайте смотреть свои системы мониторинга - что-то все равно могло пойти не так, нужно быть в курсе.

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

Почему в облака мигрировать проще?

Процесс миграции кажется сложным и трудоемким, но в случае с облаками задача становится проще:

1. В облаках создание и хранение резервных копий для популярных СУБД обычно автоматизировано - их не нужно делать силами администраторов.
2. Гибкие инструменты для работы с облачными хранилищами облегчают перенос и хранение любых данных.
3. В облаке проще создавать тестовые стенды для проверки работоспособности миграций. Завести тестовое окружение можно буквально в пару действий, будь то тестовый сервис или целый кластер Kubernetes.