Что такое миграция файлов
Мигрировать данные нужно предельно аккуратно, ведь это один из ценнейших активов любой компании. Расскажем, как перенести данные с одного сервера на другой или в облако безопасно, без потерь и с минимальным простоем.
Когда нужно переносить данные
Зачем и почему приходится реструктурировать и переносить хранилища информации? Вот несколько распространенных причин:
- Миграция с переносом данных из-за требований законодательства или смены владельца проекта. Например, после вступления в силу 152-ФЗ, который обязывает хранить персональные данные на территории России, многие компании перенесли клиентскую информацию в российские облака.
- Радикальная смена архитектуры системы хранения данных. Например, смена типа СУБД.
- Масштабная чистка или модификации хранимых данных. Например, применение алгоритма шифрования ко всем файлам.
- Получение преимуществ от перехода на новые технологии. Например, перенос СУБД на облачные базы данных с подключением автоматических бэкапов и системы восстановления после сбоев — чтобы на новый уровень поднять безопасность системы хранения информации и удобство ее использования.
- Повышение скорости работы систем хранения данных и/или снижение стоимости эксплуатации хранилищ за счет внедрения преднастроенных облачных решений.
Первый этап миграции данных: проводим инвентаризацию и делаем бэкапы
Сперва нужно понять, какие данные есть в компании и где они хранятся. В самом простом случае — есть одна база данных и в ней лежат все данные. В больших проектах ситуация с данными сложнее — появляются несколько разных СУБД, key-value хранилища, серверы для поиска, файловые хранилища, документные хранилища, серверы кэширования и так далее. Данных может быть много, а способов их хранения очень много.
Первым делом нужно разобраться с тем, что и где хранится. Проще всего свести всю информацию в таблицу:
- Какие данные хранятся в этой системе.
- Типы данных.
- В чем хранятся: название СУБД, пути к файлам.
- Примерный размер хранимых данных. Некоторые записи обновляются так часто, что их размер можно указать лишь приблизительно.
- Как часто обновляются данные.
- Насколько данные критичны для вашей системы.
- Как часто делаются бэкапы.
- Можете ли вы потерять эти данные. Такое тоже бывает — например, если данные в одной СУБД читаются на основе данных из второй СУБД. Тогда можно первый набор данных удалить и потом восстановить из второго набора.
Затем нужно убедиться, что для всей важной информации есть бэкапы . Если бэкапы не создаются — внедрите инструменты резервного копирования для этих данных.
Дальше можно двигаться только после того, как проведена полная инвентаризация и налажено копирование всего важного и нужного.
Второй этап: планируем миграцию данных
Теперь нужно спланировать фронт работ. Для этого ранжируем все источники информации по важности — от самых важных к менее важным.
Для каждого источника данных нужно подготовить инструменты миграции. Это может быть что угодно, начиная от текстового файла с командами для выполнения на сервере и заканчивая сложными файлами для систем автоматизации развертывания. Инструментарий может быть простым, может быть сложным — но он должен быть задокументирован.
Это нужно, чтобы в случае необходимости миграцию и копирование данных можно было повторить. Например, если придется мигрировать данные повторно или что-то пойдет не так.
В случае, если вы готовитесь в ходе миграции к смене архитектуры — не забудьте подготовить дополнительные тесты для систем, которые переезжают на новые технические решения, например:
- Если вы переносите файлы с дисков серверов на хранение в S3-хранилище — после миграции нужно проверить доступность и целостность всех записей в новой системе.
- Если вы меняете тип СУБД (допустим, с MySQL на PostgreSQL ), то протестируйте не только корректность вставки и удаления записей в БД, но и правильность работы коннектов в базу под нагрузкой, когда у вас запущено несколько копий приложений.
Конечно, у вас должны быть тесты на основные компоненты приложения, но после смены архитектуры потребуется некоторые дополнительные проверки данных.
Третий этап: делаем тестовую миграцию данных
Тестовая миграция нужна, чтобы проверить, как происходит процесс переноса данных от одного провайдера к другому. Вам нужно взять тестовые серверы и выполнить миграцию с ними. Цель эксперимента — убедиться, что инструменты корректно работают и данные после миграции доступны: базы данных работают, файлы открываются, записи грузятся.
Перемещение файлов кажется простой операцией, но иногда в ходе копирования могут случиться неприятные сюрпризы — файлы повреждаются, версии баз данных не совпадают, что-то где-то не загружается. Всегда нужно проверять качество работы ваших скриптов и настроек.
В процессе тестовой миграции часто переносят все данные, то есть имитируют боевую миграцию. Однако если данных много — не обязательно мигрировать их все, это будет слишком долго и трудозатратно, достаточно проверить работоспособность на ограниченной выборке. Скажем, на 1% от общего количества записей.
Четвертый этап: мигрируем данные
После всех предварительных проверок и подготовки можно начинать настоящий перенос:
- Не забудьте уведомить клиентов и пользователей о технических работах.
- Постарайтесь выключить все серверы и сервисы, которые можно, так как в процессе миграции в них не должны появляться новые данные. Те системы, которые выключить нельзя, мигрируют в горячем режиме. Например, через репликацию, поддерживая одновременно по одной копии каждого сервиса в старом и новом дата-центре. Для горячей миграции уже на этом шаге нужно поднять две копии сервисов.
- Сделайте актуальные бэкапы всей информации сразу после выключения, перед началом переноса.
- Двигайтесь строго по плану, который составили заранее. Используйте только те инструменты миграции, которые выбрали и опробовали, не отступайте от сценария.
- После переноса перенастройте все системы на работу с новыми данными, запустите и протестируйте работу всех приложений.
- После этого можно снова запустить сервисы и сделать их доступными для пользователей, но продолжайте смотреть свои системы мониторинга — что-то все равно могло пойти не так, нужно быть в курсе.
Если вы решили не рисковать или не хотите проводить миграцию самостоятельно — запросите помощь у внешних консультантов. Так, у облачных провайдеров можно получить помощь в миграции инфраструктуры или воспользоваться автоматической платформой для миграции серверов, данных и приложений .
Почему в облака мигрировать проще?
Процесс миграции кажется сложным и трудоемким, но в случае с облаками задача становится проще:
- В облаках создание и хранение резервных копий для популярных СУБД обычно автоматизировано — их не нужно делать силами администраторов.
- Гибкие инструменты для работы с облачными хранилищами облегчают перенос и хранение любых данных.
- В облаке проще создавать тестовые стенды для проверки работоспособности миграций. Завести тестовое окружение можно буквально в пару действий, будь то тестовый сервис или целый кластер Kubernetes .
И, конечно, администраторы провайдера помогут вам спланировать и провести миграцию данных. Это сэкономит вам время и деньги, а также поможет минимизировать время недоступности ваших сервисов при переносе.
Читайте также: