Миграция данных между дисковыми массивами: пошаговые стратегии и проверенные инструменты

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

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

Критичные данные проверяйте на трех уровнях: по количеству и размеру объектов, по контрольным суммам и через тесты приложений. Подробный порядок оценки рисков, проверки бэкапов и подготовки rollback-плана разобран в плане миграции IT-инфраструктуры.

Что означает ats и hh.ru на практике

ATS и hh.ru относятся к рекрутинговым системам и сами по себе не определяют способ миграции дисковых массивов. Если база кандидатов, вложения, резюме или архив документов хранятся на СХД, перенос выполняют по тем же правилам, что и для файлового сервера или базы данных: сначала фиксируют зависимости, затем копируют данные, синхронизируют изменения и проверяют работу приложения.

Для инфраструктурного специалиста важны не названия прикладных систем, а характеристики нагрузки:

• тип данных: файлы, виртуальные диски, базы данных, snapshots или резервные копии;
• режим доступа: последовательный, случайный, смешанный, постоянная запись или преимущественное чтение;
• требования к IOPS и задержке;
• необходимость сохранить ACL, владельцев, группы, extended attributes, hard links и sparse-файлы;
• допустимые значения RPO и RTO.

Например, перенос каталога с документами допускает host-based копирование, если сохранены права и временные метки. Для базы данных нужен согласованный snapshot, штатная репликация или остановка записи перед финальной копией. Crash-consistent snapshot не гарантирует корректное состояние транзакций.

Почему эта задача становится критичной для HR

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

Критичность определяют измеримые параметры:

• RPO показывает, сколько последних изменений допустимо потерять. Если RPO равен 15 минутам, финальная синхронизация должна укладываться в этот интервал либо система должна использовать непрерывную репликацию.
• RTO задает допустимое время восстановления сервиса. При RTO 30 минут план переключения должен содержать готовые команды, проверенные точки монтирования и заранее назначенного ответственного.
• ACL и аудит определяют, кто получит доступ к документам после переноса. Ошибка в сопоставлении UID, GID или доменных групп может открыть закрытые каталоги.

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

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

Практический разбор: где возникает основной эффект

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

Практичный сценарий выглядит так:

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

Для оценки целевой СХД используют IOPS, задержку, пропускную способность и объем свободного пространства. Ориентир в 5 000 IOPS подходит для легких файловых и офисных нагрузок, а высоконагруженной СУБД может потребоваться 500 000 IOPS и выше. Эти числа не заменяют нагрузочное тестирование: профиль блоков, глубина очереди и задержка сети меняют результат.

Инструмент выбирают по границе ответственности:

Практические варианты и методы проверки целостности данных собраны в руководстве по миграции данных для DevOps.

Как WorkHere закрывает этот сценарий

Название WorkHere не описывает инструмент миграции дисковых массивов. Для проекта admin-wiki корректный подход другой: база знаний дает методику, команды и контрольные точки, но не выполняет коммерческие работы по переносу и не продает ПО или оборудование.

Сценарий закрывается техническим регламентом, в котором зафиксированы:

• границы миграции и список сервисов;
• ответственные за источник, целевую СХД, приложения и приемку;
• временные окна первичного копирования и переключения;
• критерии успешного завершения;
• команды для финальной синхронизации и отката;
• срок хранения исходного массива после переключения.

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

7 критериев проверки решения

Перед выбором метода оцените семь критериев. Результат фиксируйте в таблице, а не оставляйте в устных договоренностях.

Отдельно проверьте ограничения лицензий и поддержки. Встроенная функция репликации может работать только между конкретными моделями или версиями. Host-based копирование может не передать атрибуты, которые использует приложение. Специализированное ПО может требовать агента на сервере и отдельного окна обновления.

Пошаговый сценарий внедрения

1. Зафиксируйте границы работ

Составьте список пулов, LUN, файловых систем, экспортов и сервисов. Для каждого объекта укажите владельца, размер, объем изменений в час, критичность, RPO, RTO и способ проверки.

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

2. Проверьте источник и резервную копию

Проверьте состояние RAID, pool, контроллеров, дисков, snapshots и журналов. Для ZFS выполните проверку состояния пула и запланируйте scrub. Для mdadm проверьте синхронизацию массива и ошибки ядра. Для аппаратной СХД изучите состояние cache, батарей контроллера и дисков.

Резервная копия считается пригодной только после тестового восстановления. Наличие файла бэкапа в каталоге не подтверждает возможность вернуть сервис.

3. Подготовьте цель

Создайте целевой pool или файловую систему с нужной схемой дисков, compression, deduplication, record size и политикой snapshots. Не копируйте старые настройки автоматически: параметры, подходящие для HDD, могут ухудшить работу на SSD, а deduplication требует отдельной оценки памяти.

Проверьте:

• свободную емкость и резерв для snapshots;
• сетевые пути и MTU;
• multipath или отказоустойчивость сетевых соединений;
• время на всех узлах;
• UID, GID, доменные группы и правила ACL;
• мониторинг свободного места, ошибок записи и задержки.

4. Стратегия 1, встроенные функции массива

Этот вариант подходит, когда источник и цель совместимы, а функция поддерживает нужный тип объекта. Примерами служат LUN migration, storage replication, snapshots и репликация pool между системами ZFS.

1. Создайте тестовый объект небольшого размера.
2. Проверьте репликацию, восстановление snapshot и переключение доступа.
3. Запустите первичную передачу для рабочего объекта.
4. Контролируйте отставание, ошибки передачи и свободное место на цели.
5. Остановите запись, передайте последний snapshot, переключите экспорт и проверьте сервис.

Для ZFS типовой поток выглядит так:

zfs snapshot -r tank/data@migrate-1
zfs send -R tank/data@migrate-1 | zfs receive -uF newpool/data
zfs snapshot -r tank/data@migrate-2
zfs send -R -i tank/data@migrate-1 tank/data@migrate-2 | zfs receive -uF newpool/data

Ключ -F может удалить изменения на целевом наборе данных, поэтому применяйте его только к подготовленной цели. До запуска проверьте имена datasets и направление потока. После приема выполните zpool status, запустите scrub и сравните список snapshots.

5. Стратегия 2, host-based копирование

Host-based способ используют при переносе между разными производителями, файловыми системами и протоколами. Сервер или отдельный узел читает источник и записывает данные на цель. Метод прозрачен для массива, но требует аккуратной работы с метаданными.

Для Linux можно начать с rsync:

rsync -aHAX --numeric-ids --info=progress2 /mnt/old/ /mnt/new/

Флаги -aHAX сохраняют режимы, владельцев, hard links, ACL и extended attributes в поддерживаемой среде. На BSD или сетевых шарах набор параметров нужно проверить отдельно. Для финального прохода после остановки записи часто используют:

rsync -aHAX --numeric-ids --delete --info=progress2 /mnt/old/ /mnt/new/

Параметр --delete опасен: ошибка в пути может удалить данные на цели. Перед запуском выполните пробный проход с --dry-run, сохраните вывод и убедитесь, что источник и цель указаны в правильном порядке.

Для Windows-среды подходит Robocopy:

robocopy D:/data E:/data /E /COPYALL /DCOPY:DAT /ZB /R:2 /W:5 /TEE /LOG:C:/logs/migration.log

Ключ /MIR синхронизирует зеркальную структуру и может удалить лишние каталоги на цели. Используйте его после проверки dry run и только при ясном понимании результата. После копирования проверьте ACL, владельцев, скрытые файлы, длинные пути и открытие документов из целевого ресурса.

6. Стратегия 3, специализированное ПО

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

• поддержка исходной и целевой СХД;
• работа с нужными протоколами и файловыми системами;
• режим application-consistent для баз и виртуальных машин;
• контроль изменившихся файлов или блоков;
• возобновление после потери сети;
• проверка контрольных сумм;
• отчет о пропущенных объектах и ошибках доступа;
• ограничение нагрузки на диски и сеть;
• понятное удаление агента и возврат к штатной схеме доступа.

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

7. Выполните финальную синхронизацию

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

После финального прохода:

1. сохраните лог копирования;
2. сравните количество файлов и общий размер;
3. проверьте контрольные суммы выбранной выборки или полного набора;
4. подключите целевой экспорт с прежним именем, если это предусмотрено планом;
5. запустите сервисы в определенном порядке;
6. выполните технические и прикладные проверки.

8. Проверьте целостность и переключите трафик

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

• Файловый уровень: количество объектов, объем, хэши, ACL, владельцы, xattr, symlinks и hard links.
• Системный уровень: состояние pool, RAID, snapshots, ошибки ядра, задержка и свободное место.
• Прикладной уровень: вход пользователя, чтение, запись, поиск, создание файла, фоновые задания и резервное копирование.
• Нагрузочный уровень: IOPS, latency, throughput и время ответа в период типичной и пиковой нагрузки.

Пример манифеста для небольшого набора файлов:

find /srv/data -type f -print0 | sort -z | xargs -0 sha256sum > manifest.sha256
sha256sum -c manifest.sha256

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

9. Подготовьте откат

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

Пример логики:

1. Остановить запись и фоновые задания.
2. Зафиксировать журналы и время последней операции.
3. Отключить целевой экспорт.
4. Подключить исходный экспорт в режиме записи.
5. Запустить сервисы и проверить чтение, запись и авторизацию.
6. Определить, какие изменения появились на цели после переключения, чтобы не потерять их при последующей повторной миграции.

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

ROI: как считать без рекламных обещаний

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

Базовая формула:

эффект = стоимость предотвращенного простоя + экономия на старой инфраструктуре - затраты на миграцию

Пример расчета. Если простой сервиса стоит 150 000 рублей в час, двухчасовое окно несет потенциальный ущерб 300 000 рублей. Подготовка, тестовый стенд и работа команды стоят 80 000 рублей. При сокращении окна до 20 минут предотвращенная часть простоя составит 250 000 рублей, а расчетный эффект после затрат будет равен 170 000 рублей.

В расчет включите:

• время инженеров и дежурной команды;
• аренду или покупку целевой СХД;
• стоимость лицензий и поддержки;
• дополнительный трафик и временное хранилище;
• тестирование восстановления;
• стоимость возможного отката;
• резерв на повторный перенос при ошибке.

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

Типовые ошибки

• Копирование без инвентаризации. В план не попадают snapshots, скрытые экспорты, задания резервного копирования или сервисные каталоги. Решение: собрать список объектов через интерфейс СХД, ОС и системы мониторинга.
• Проверка только объема. Одинаковый размер не подтверждает совпадение файлов и прав. Решение: сравнивать количество объектов, манифесты, ACL и результаты прикладных тестов.
• Запуск финальной копии при активной записи. Часть изменений остается на источнике. Решение: заморозить запись, использовать application-consistent snapshot или повторную синхронизацию.
• Непроверенный ключ удаления. rsync --delete и Robocopy /MIR могут удалить данные при ошибке пути. Решение: сначала dry run, затем лог и подтверждение оператором.
• Игнорирование метаданных. Файлы переносятся, но пользователи теряют доступ или приложение не видит xattr. Решение: включить сохранение ACL, владельцев и атрибутов, затем проверить их на выборке.
• Одинаковые имена при двойной записи. Одновременная запись на старый и новый массив создает расхождение. Решение: использовать один источник записи и четко назначить активную копию.
• Отсутствие запаса на цели. После переноса snapshots и рост данных быстро занимают свободное место. Решение: учитывать рост за 6-12 месяцев и резерв под служебные операции.
• Досрочное списание источника. При обнаружении ошибки уже не остается рабочей точки возврата. Решение: сохранить источник в режиме read-only до окончания приемки.
• Переоценка пропускной способности. Скорость канала не равна скорости записи массива. Решение: измерить чтение источника, запись цели и влияние параллельной нагрузки.

Чек-лист перед запуском

• Область: перечислены массивы, pools, LUN, файловые системы, экспорты и зависимые сервисы.
• Данные: зафиксированы объем, число объектов, темп изменений и требуемый запас.
• Параметры: определены RPO, RTO, окно работ и критерии остановки.
• Источник: проверены RAID, pool, контроллеры, диски, snapshots и журналы.
• Бэкап: есть свежая копия, а восстановление проверено на отдельной цели.
• Цель: создан pool или файловая система, проверены совместимость, емкость, сеть и мониторинг.
• Метод: выбраны native replication, rsync, Robocopy или специализированное ПО с обоснованием.
• Пилот: перенесен тестовый набор с большими файлами, мелкими файлами, ACL, symlinks и изменяющимися данными.
• Команды: первичная копия, финальная синхронизация, проверка и откат сохранены в рабочем журнале.
• Переключение: назначены ответственные за ОС, СХД, сеть, приложения и приемку.
• Проверка: подготовлены тесты доступа, чтения, записи, поиска, фоновых заданий и резервного копирования.
• Откат: источник сохранен, порядок возврата проверен, срок наблюдения согласован.

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

Когда WorkHere имеет смысл включить в шорт-лист

Если WorkHere рассматривается как сторонний подрядчик, включайте его в шорт-лист только после проверки конкретного опыта с нужной СХД, файловой системой и прикладной нагрузкой. Уточните, кто отвечает за данные, кто выполняет приемку и кто принимает решение об откате.

Минимальный список вопросов подрядчику:

• Какие модели массивов, версии прошивок и протоколы поддерживаются?
• Как сохраняются ACL, владельцы, xattr, snapshots и специальные файлы?
• Как устроены первичная копия, повторная синхронизация и финальное переключение?
• Как проверяется согласованность баз данных и виртуальных машин?
• Какие логи и отчеты получает заказчик?
• Как измеряются RPO, RTO, IOPS и задержка?
• Как выглядит пошаговый rollback и сколько времени занимает возврат?
• Как долго хранится исходный массив после приемки?

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

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