Миграция системы хранения без потери данных: пошаговый план и сравнение методов переноса

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

Рабочий порядок такой: аудит источника и цели, отработка команд на тестовом стенде, первичная синхронизация, серия дельта-синхронизаций, остановка сервисов, финальная синхронизация, переключение нагрузки, проверка целостности и вывод старого массива из эксплуатации. Метод переноса выбирают под инфраструктуру: rsync для файлов и смешанных сред, ZFS send/receive для пулов ZFS, репликацию на уровне СХД (системы хранения данных) для массивов одного вендора.

Почему миграция хранилища - это риск и как его снизить

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

• Несовместимость файловых систем или уровней RAID, которую выясняют уже в процессе копирования.
• Потеря метаданных: POSIX ACL, расширенные атрибуты, жёсткие ссылки, владельцы и группы.
• Скрытые зависимости: скрипты, задания cron, экспорт NFS, шары SMB, символические ссылки на старые пути, тома контейнеров и постоянные тома (PVC) в Kubernetes.
• Открытые файлы и незавершённые транзакции СУБД в момент переключения.
• Опечатки в командах: неверный путь при --delete, забытый флаг, лишний слеш в конце.
• Отсутствие резервной копии или её непроверенное состояние.

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

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

Подготовка к миграции: аудит, инвентаризация и тестовый стенд

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

Аудит источника включает:

• объем данных и число файлов. Миллион мелких файлов переносится часами даже по быстрому каналу, потому что время уходит на операции с метаданными, а не на передачу байт;
• занятые и свободные иноды, размер самого крупного файла;
• список томов, датасетов, снапшотов и квот;
• права доступа, POSIX ACL, расширенные атрибуты, жёсткие ссылки, файлы с нестандартными символами в именах;
• сервисы, которые пишут в хранилище: СУБД, веб-серверы, очереди сообщений, системы резервного копирования;
• точки монтирования, экспорт NFS, шары SMB, монтирования внутри контейнеров и объекты PVC в Kubernetes.

Пропускную способность считают до старта. Передача 10 ТБ по каналу 1 Гбит/с в идеальных условиях занимает около 22 часов, на практике с накладными расходами и мелкими файлами закладывайте 30-50 часов. Канал 10 Гбит/с сокращает первичную синхронизацию до 2-4 часов, но упор часто уходит в дисковые операции, а не в сеть.

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

Что проверить в старом и новом хранилище

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

Уровень RAID планируют отдельно. RAID 0 не даёт избыточности, RAID 5 переживает отказ одного диска, RAID 6 и RAID-Z2 - отказ двух, RAID 10 держит отказ диска в каждой зеркальной паре. Смена уровня RAID меняет не только производительность, но и время восстановления после отказа, а также требования к числу дисков и их объёму.

Пример: перенос данных с ext4 на ZFS меняет поведение системы при внезапном отключении питания. ext4 опирается на журнал и после сбоя проигрывает незавершённые транзакции, ZFS пишет по принципу copy-on-write и после включения может показать повреждённые блоки только при чтении или при scrub. Проверить целостность нового пула нужно до того, как на него переключат нагрузку.

Смена файловой системы или уровня RAID требует отдельного плана и не может быть побочным эффектом миграции.

Резервное копирование перед миграцией

Копию делают до первой команды синхронизации и проверяют восстановлением хотя бы части данных. Схема 3-2-1 применительно к миграции: три копии данных, две разные среды хранения, одна копия вне основного массива.

• Копируйте метаданные и конфигурации: /etc/exports, smb.conf, параметры пулов и массивов, crontab, юниты systemd, манифесты Kubernetes.
• Критичные тома выносят в отдельную очередь копирования и проверяют первыми.
• Проверяйте копию до старта: разверните один том на тестовом стенде и убедитесь, что приложение с ним работает.
• Старый массив во время миграции держите в режиме только чтение, он служит дополнительной страховкой, но не заменяет резервную копию.

Сравнение методов миграции данных: rsync, ZFS send/receive и репликация СХД

Три подхода решают одну задачу разными средствами. rsync работает с файлами и не зависит от типа хранилища. ZFS send/receive передаёт снапшоты на уровне блоков и сохраняет целостность датасета. Репликация на уровне СХД копирует тома силами самих массивов.

rsync: когда подходит и какие флаги важны

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

Базовый запуск с сохранением прав, жёстких ссылок, POSIX ACL и расширенных атрибутов:

rsync -aHAX --numeric-ids --info=progress2 /srv/data/ user@target:/srv/data/

Флаги, которые чаще всего определяют результат:

• -a включает рекурсию, права, временные метки, владельца и группу;
• -H сохраняет жёсткие ссылки, без него они превращаются в отдельные копии файлов;
• -A переносит POSIX ACL, -X расширенные атрибуты; обе опции требуют поддержки в сборке rsync на обеих сторонах;
• --numeric-ids сохраняет числовые UID и GID, если базы пользователей на источнике и цели различаются;
• --delete удаляет на цели файлы, которых нет на источнике. Ошибка в пути или лишний слеш в конце превращают этот флаг в инструмент потери данных, поэтому первый запуск с ним делают через --dry-run;
• --partial оставляет частично перенесённые файлы и помогает при обрыве связи. Для чистоты проверок надёжнее --partial-dir: незавершённые файлы складываются в отдельный каталог и не путаются с готовыми;
• -W отключает поблочное сравнение и ускоряет передачу по быстрому каналу;
• --info=progress2 показывает общий прогресс и требует rsync 3.1 и новее.

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

rsync -aHAXn --delete --itemize-changes /srv/data/ /mnt/new/data/

Ограничения: rsync переносит NFSv4 ACL не так полно, как POSIX ACL, а перенос контекстов SELinux зависит от сборки и набора опций. Оба момента проверяйте на тестовом стенде до боевого запуска. Стратегии и инструменты для переноса между массивами, включая ZFS и rsync, разобраны в статье Миграция данных между дисковыми массивами: пошаговые стратегии и проверенные инструменты.

ZFS send/receive: преимущества для ZFS-инфраструктуры

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

Создание снапшота и первая передача:

zfs snapshot tank/data@migr-base

zfs send tank/data@migr-base | ssh user@target zfs receive backup/data

Инкрементальная передача изменений между снапшотами:

zfs snapshot tank/data@migr-01

zfs send -i tank/data@migr-base tank/data@migr-01 | ssh user@target zfs receive backup/data

Ограничения и детали:

• ZFS нужен на обеих сторонах, а принимающий пул должен поддерживать все флаги функций источника;
• версию пула на источнике перед миграцией не поднимают, иначе старый принимающий узел не сможет принять поток;
• если приём запускали с флагом -s, состояние частично принятого потока сохраняется. Токен возобновления считывают командой zfs get receive_resume_token на целевом датасете и передают в zfs send -t, чтобы продолжить передачу вместо полного повтора;
• флаг -c отправляет данные в сжатом виде, если включено сжатие; принимающая сторона должна поддерживать соответствующую функцию;
• для проверки целостности после передачи запускают scrub на целевом пуле и смотрят статус пула.

Репликация на уровне СХД: минимальный простой

Массивы реплицируют тома между собой в синхронном или асинхронном режиме. Синхронная репликация подтверждает запись только после её фиксации на второй стороне, поэтому RPO близок к нулю, но задержка записи растёт. Асинхронная передаёт изменения с задержкой в секунды или минуты и меньше влияет на производительность.

Сценарии, где метод оправдан:

• замена массива одного вендора без остановки сервисов: тома переключаются на новое оборудование, хосты продолжают работать через multipath;
• миграция между площадками с требованием минимального RPO;
• консолидация нескольких массивов в один в пределах поддерживаемой матрицы совместимости.

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

Пошаговый план миграции: от первичной синхронизации до переключения

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

Первичная и дельта-синхронизация

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

• Для rsync первичный запуск делают без --delete, а при необходимости ограничивают полосу через --bwlimit, чтобы не занять рабочий канал;
• для ZFS первая передача идёт от базового снапшота, все последующие - инкрементальные;
• следите за метриками: задержка ввода-вывода на источнике, заполнение кэша, пропускная способность канала;
• дельта-синхронизации запускают по расписанию, каждая следующая занимает меньше времени, потому что переносит только изменения.

Остановка сервисов и финальная синхронизация

Финальную дельту делают, когда записи в источник прекращены. Для файлового сервера это режим только чтение или остановка SMB и NFS. Для СУБД корректный останов либо снапшот тома с предварительным сбросом буферов на диск.

Порядок действий:

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

Критерий завершения этапа: повторный запуск синхронизации не переносит ни одного файла.

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

Переключение - самый рискованный этап, поэтому его расписывают по минутам.

1. Размонтировать старое хранилище или перевести его в режим только чтение.
2. Смонтировать новое хранилище по тем же путям, обновив записи в /etc/fstab по UUID, чтобы порядок дисков не влиял на загрузку.
3. Обновить конфигурации: экспорт NFS, шары SMB, пути данных в приложениях, тома контейнеров, объекты хранения в Kubernetes.
4. Запустить сервисы и проверить логи на ошибки доступа и отсутствующие файлы.
5. Оставить старый массив в режиме только чтение до подтверждения успеха, минимум на несколько дней.

План отката пишут заранее и проверяют на тестовом стенде: вернуть старые точки монтирования и конфигурации, запустить сервисы, зафиксировать инцидент и причину. Если откат не тестировали, он не считается планом.

Пример таймлайна для хранилища 10 ТБ и канала 10 Гбит/с:

Проверка целостности данных после миграции

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

Контрольные суммы и сравнение метаданных

• Число файлов и суммарный объём: сравните вывод find /srv/data -type f | wc -l и du -sb /srv/data на обеих сторонах.
• Контрольные суммы критичных файлов. Соберите хеши на источнике и цели и сравните списки: find /srv/critical -type f -print0 | sort -z | xargs -0 sha256sum > sums.txt. Для 10 ТБ сплошное чтение при скорости 200 МБ/с занимает около 14 часов, поэтому чаще считают хеши только для важных каталогов.
• Права и владельцы: сравните вывод getfacl и stat для выборки каталогов.
• Жёсткие ссылки: проверьте, что на цели сохранилось то же число ссылок на файл.
• Расширенные атрибуты и контексты SELinux: убедитесь, что они перенеслись и приложение получает доступ к данным без ошибок.
• ZFS: запустите scrub и проверьте статус пула. Команда zpool status покажет ошибки контрольных сумм, если они есть.

Быстрый способ сравнить деревья без записи на цель:

rsync -aHAXnc --delete --itemize-changes /srv/data/ /mnt/new/data/

Пустой вывод означает совпадение по составу и содержимому файлов. Флаг -c заставляет rsync сравнивать файлы по контрольной сумме, а не по размеру и времени изменения.

Методики проверки целостности и инструменты для минимизации простоя, включая подходы к сверке данных, разобраны в руководстве Миграция данных: пошаговое руководство, стратегии ETL/ELT и проверка целостности для DevOps.

Тестовое восстановление и проверка сервисов

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

Что делать, если миграция прервалась на середине

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

Возобновление rsync и ZFS send/receive

• rsync идемпотентен: повторный запуск с теми же флагами докачает изменения. Флаг --partial сохраняет недописанный файл и продолжает его при следующем запуске, --partial-dir убирает частичные файлы в отдельный каталог.
• Код возврата 23 означает частичный перенос из-за ошибок, код 24 - файлы исчезли во время копирования. Оба случая требуют разбора причины, а не слепого повторения.
• ZFS send/receive: если принимающая сторона запускалась с флагом -s, состояние частично принятого потока сохраняется. Токен получают командой zfs get receive_resume_token на целевом датасете и передают в zfs send -t. Без сохранённого состояния инкремент придётся начать от последнего полностью принятого снапшота.
• Перед возобновлением проверьте, что датасет на цели не монтировался и не изменялся, иначе токен станет недействительным.

Откат и повторная попытка

Решение принимают по состоянию цели:

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

Каждый инцидент фиксируйте: время, команду, текст ошибки, действие. Эти записи ускоряют повторную попытку и помогают скорректировать план перед следующей миграцией.

Риски смены файловой системы и уровня RAID

Смена файловой системы или уровня RAID меняет семантику хранения: снапшоты, квоты, сжатие, поведение при сбое питания. Копирование файлов не переносит эти свойства автоматически.

Совместимость метаданных и атрибутов

• POSIX ACL и расширенные атрибуты переносятся только при поддержке на обеих сторонах и правильных флагах копирования.
• Контексты SELinux хранятся в расширенных атрибутах, их перенос зависит от сборки утилиты и опций, проверяйте выборочно на тестовом стенде.
• Жёсткие ссылки без флага -H превращаются в отдельные файлы, растёт занимаемое место.
• Квоты и проектные лимиты придётся настраивать заново: ext4 использует проектную квоту через включённую функцию, XFS - проектные квоты, ZFS - отдельные свойства датасета.
• Ограничения на имена файлов различаются: длина имени и допустимые символы в разных ФС совпадают не всегда, а файлы с нестандартными символами ломают скрипты обработки.

Производительность и поведение при сбоях

• RAID 5 и RAID-Z1 при замене вышедшего диска читают весь массив. При заявленном уровне неисправимых ошибок чтения 10^14 бит полное чтение диска объёмом 8 ТБ даёт заметную вероятность сбоя, поэтому для больших дисков выбирают RAID 6, RAID-Z2 или зеркала.
• ZFS работает по принципу copy-on-write и не имеет проблемы write hole, но требователен к объёму оперативной памяти: под ARC резервируют память отдельно, а для коррекции ошибок памяти используют модули ECC. Распространённая оценка для рабочих нагрузок: не менее 1 ГБ памяти на 1 ТБ данных плюс базовый объём для системы.
• Btrfs даёт снапшоты и send/receive, однако уровни RAID 5 и RAID 6 в этой ФС исторически считаются менее надёжными из-за незакрытой проблемы write hole. Для миграции выбирайте RAID 1 или RAID 10.
• Смена уровня RAID невозможна без пересборки, а сама пересборка повышает нагрузку на диски и риск отказа второго диска. Планируйте её отдельно от переноса данных.
• После перехода проверьте производительность на реальной нагрузке: различаются размер блока, выравнивание записей и поведение кэша.

Чек-лист и документирование миграции

1. Аудит источника и цели, оценка объёма, числа файлов и времени передачи.
2. Сравнение файловых систем, уровней RAID, поддержки ACL, атрибутов и снапшотов.
3. Резервная копия по схеме 3-2-1 и проверка восстановления.
4. Тестовый стенд с отработкой команд, переключения и отката.
5. Первичная синхронизация на работающей системе с контролем нагрузки.
6. Дельта-синхронизации по расписанию до минимального объёма изменений.
7. Окно обслуживания: остановка сервисов, финальная дельта, переключение.
8. Проверка целостности: число файлов, контрольные суммы, права, scrub.
9. Функциональные тесты приложений и замер производительности.
10. Наблюдение после переключения, старый массив в режиме только чтение.
11. Вывод старого хранилища из эксплуатации после периода стабильной работы.

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

Общий план переезда серверов и сервисов с чек-листом аудита и сценариями отката приведён в руководстве Практическое руководство по миграции серверов: от планирования до запуска.