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

Что значит «без простоя» и какие сценарии миграции бывают

Без простоя означает окно недоступности файловых шар в пределах 5-15 минут вместо суток непрерывного копирования. Рабочая схема такая: предварительная репликация на новый хост, инвентаризация прав и зависимостей, короткое окно на финальную синхронизацию с закрытием сессий, переключение клиентов через DNS или DFS Namespace, проверка ACL. Полного нуля недоступности не бывает: остается момент, когда запись на старом томе останавливают, догоняют дельту изменений и переводят клиентов на новый адрес.

Длительность окна зависит от объёма дельты, а не от размера шар. Если 5 ТБ уже скопированы и за сутки изменилось 20 ГБ, финальный прогон на скорости 100 МБ/с займет три-четыре минуты, плюс время на закрытие сессий, смену таргета DFS и проверку прав на тестовом каталоге.

Полный простой, короткое окно и почти нулевой простой

Критерий выбора простой: допустимый RTO. Ночь недоступности переносится спокойно, значит достаточно остановить шар и скопировать данные целиком. Допустимо 10-20 минут, планируйте предварительную репликацию с дельта-прогонами. Нужны секунды, без снапшотов на уровне файловой системы или СХД не обойтись: ZFS send передает инкремент между снапшотами, а массивы умеют синхронную репликацию между контроллерами с нулевым RPO.

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

Общие принципы переноса с предварительной синхронизацией и откатом разобраны в материале о переносе данных со старого хранилища на новое: там же сравниваются rsync, ZFS send/receive и репликация на уровне СХД.

Windows, Linux и NAS: чем отличаются подходы

Windows и SMB. Базовый инструмент - robocopy с ключами /MIR и /COPYALL. Для открытых файлов нужен VSS: robocopy запускают из теневой копии тома. Абстракция пути делается через DFS Namespace, тогда смена сервера-владельца шары проходит без правок на клиентах. Второй вариант репликации между Windows-хостами - DFS-R. Учитывайте его ограничения: квота staging-области должна быть не меньше суммарного размера 32 самых больших файлов в реплицируемой папке, иначе репликация может замедлиться или остановиться, а при превышении квоты служба может не суметь реплицировать некоторые большие файлы и папка рассинхронизируется. При установке DFS staging-область часто настраивается размером 4 ГБ, что в современных условиях может оказаться недостаточно. Поэтому DFS-R применяют к профильным задачам, а не к терабайтным архивам без предварительного теста. Требования к staging-области описаны в документации Microsoft How to determine the minimum staging area DFSR needs.

Linux и NFS. Рабочая связка: rsync -aHAX --delete для данных и снапшот LVM или ZFS для консистентности. NFS-клиент видит права в том виде, в котором их отдает сервер, поэтому проверять результат нужно на смонтированной шаре, а не локально на сервере.

NAS и TrueNAS. Основной путь - ZFS send/recv между пулами, включая инкрементальные передачи от снапшота к снапшоту, и периодические snapshot tasks по расписанию. При получении полного репликационного потока ZFS (zfs send -R) сохраняются все свойства, снапшоты, дочерние файловые системы и клоны, поэтому отдельная пересборка прав не нужна. Поведение zfs send -R описано в документации OpenZFS.

Главный источник ошибок во всех трех случаях один: метаданные. NTFS-разрешения ссылаются на SID, POSIX-права на UID и GID, расширенные атрибуты и ACL хранятся отдельными структурами. Инструмент, который копирует только содержимое файлов, оставляет владельцев и права в исходном состоянии приёмника.

Инвентаризация перед миграцией: что нужно знать о данных и клиентах

Инвентаризация отвечает на вопрос, сколько работы предстоит и что именно может сломаться. Её результат - таблица соответствия «старый путь, новый путь, владелец, ответственный за проверку».

Что фиксировать: объём, права, зависимости

Данные. Общий объём, количество файлов и каталогов, топ-10 крупнейших каталогов, максимальная длина пути, наличие симлинков и жёстких ссылок, файлы с нестандартными именами (юникод, пробелы, кавычки, двоеточия). В Windows это PowerShell-командлеты Get-ChildItem с Measure-Object и сортировкой по длине пути, в Linux - find с -printf и -maxdepth, du -sh для каталогов.

Права. ACL на корневых шарах, точки разрыва наследования, владельцы, состав групп доступа, отдельно - нестандартные права на вложенных каталогах. В Windows права выгружаются через icacls с ключом /save, в Linux - через getfacl с ключом -R.

Зависимости. Список клиентов по протоколам SMB и NFS, активные и постоянные маунты, групповые политики с маппингом дисков, скрипты входа, макросы Excel и Word с UNC-путями, конфигурации приложений, файловые базы 1С и аналогичных систем, задания планировщика, таргеты DFS Namespace. Открытые сессии при этом удобно снять списком: Get-SmbOpenFile в Windows, smbstatus и showmount -a в Linux.

Практический ориентир по времени: инвентаризация прав и длинных путей на дереве в 1-2 млн файлов занимает 1-3 часа машинного времени и экономит часы ручных разборов после переключения.

Планирование окна обслуживания и коммуникация

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

Как рассчитать длительность и заложить буфер

Формула простая: объём данных, деленный на реальную пропускную способность канала, умноженный на коэффициент 1,5-2. Пример: 5 ТБ при 100 МБ/с дают около 14 часов на первый прогон, при коэффициенте 1,7 закладывайте 24 часа. Финальная синхронизация считает по дельте: 20 ГБ изменений при той же скорости - это менее 10 минут с буфером.

Пропускную способность берут не из спецификации интерфейса, а из замера: копирование тестового каталога объёмом 50-100 ГБ даёт реальную скорость с учётом мелких файлов, задержек и параллельной нагрузки на диски. Отдельно проверяют узкое место: на тысячах мелких файлов упирается не полоса, а операции ввода-вывода.

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

Кого и как уведомить

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

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

Репликация данных: rsync, robocopy и снапшот-репликация

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

rsync для Linux и NFS: ключевые флаги и метаданные

Рабочий набор: rsync -aHAX --numeric-ids --delete. Расшифровка: -a включает рекурсию и сохранение основных атрибутов, -H переносит жёсткие ссылки, -A (--acls) приводит ACL приёмника в соответствие с ACL источника и подразумевает --perms, -X (--xattrs) сохраняет расширенные атрибуты, --numeric-ids не дает сопоставлять UID и GID между хостами. Для корректной работы -A ACL источника и приёмника должны быть совместимы. Описание ключей приведено в man-странице rsync.

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

Вспомогательные ключи: --dry-run для холостого прогона, --info=progress2 для общего прогресса, --bwlimit для ограничения полосы, чтобы репликация не съела рабочий трафик, --itemize-changes для списка различий между источником и приёмником.

robocopy для Windows/SMB: /MIR, /COPYALL и VSS

Базовый вызов: robocopy источник приёмник /MIR /COPYALL /DCOPY:DAT /R:2 /W:5 /MT:16 /LOG:copy.log. Ключ /MIR зеркалирует содержимое папки, удаляя в приёмнике файлы, которых нет в источнике. Robocopy корректно копирует файлы с их атрибутами и правами доступа NTFS. Ключи /R:2 и /W:5 ограничивают повторы и паузы на заблокированных файлах, /MT:16 включает многопоточность, /LOG фиксирует результат. Синтаксис ключей описан в документации Microsoft по robocopy.

Предупреждение по /MIR: ключ удаляет в приёмнике то, чего нет в источнике. На промежуточных прогонах это нормально, но перед финальным проходом убедитесь, что на приёмник не писали ничего лишнего. Для файлов, доступ к которым закрыт даже для администратора, применяют режим резервного копирования /B: он позволяет избежать ошибки access denied, игнорируя права, которые могли бы помешать чтению или записи, и требует членства в группе «Операторы архива». В этом режиме robocopy переопределяет настройки разрешений файлов и папок (ACL), которые иначе могли бы блокировать доступ.

Снапшот-репликация: ZFS send/recv и репликация СХД

Принцип одинаков для всех реализаций: снимок на источнике, передача инкремента от предыдущего снимка, финальный снимок в окне, переключение. В ZFS снапшот - это доступная только для чтения копия файловой системы или тома; снапшоты создаются чрезвычайно быстро и изначально не потребляют дополнительного места в пуле. Дальше zfs send с ключом -i передает инкремент относительно базового снимка, zfs recv принимает поток на приёмнике, zfs promote делает полученный датасет независимым. При полном репликационном потоке (zfs send -R) сохраняются все свойства, снапшоты, дочерние файловые системы и клоны.

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

Как устроены мгновенные снимки и чем отличаются ZFS и Btrfs от ext4 и XFS по надежности и потреблению памяти, разобрано в статье о Copy-on-Write файловых системах. Если целевая платформа - программное хранилище, пригодится пошаговое руководство по переносу данных в программные системы хранения.

Открытые файлы и блокировки: как получить консистентные данные

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

VSS, LVM и ZFS: как сделать консистентный снимок

Windows: создается теневая копия тома (VSS), robocopy читает данные из неё, после прогона снимок удаляется. Копия дает точку согласованности на момент создания, дальнейшие записи идут в рабочий том и попадают в следующий проход.

Linux: логический том LVM получает снапшот через lvcreate с ключом -s, монтируется только для чтения, rsync читает из точки монтирования. Для ZFS то же самое делает zfs snapshot, причем можно передавать данные прямо из снимка. На СХД снимок презентуется как LUN или шара только для чтения.

Важная оговорка: снимок не отменяет проверку. Он гарантирует, что данные в переносе не менялись во время чтения, но не подтверждает, что права и ссылки перенеслись корректно.

Как закрыть SMB/NFS-сессии перед финальным прогоном

Windows: список открытых файлов дает Get-SmbOpenFile, принудительное закрытие - Close-SmbOpenFile. Пользователей предупреждают заранее, принудительное закрытие применяют в самом начале окна, чтобы не потерять несохраненные правки.

Linux: для SMB состояние показывают smbstatus и lsof, для NFS - showmount -a и проверка экспортов через exportfs. При необходимости службу NFS останавливают или отключают экспорт, после чего сразу запускают финальный проход. Практический порядок действий: уведомление, закрытие сессий, снапшот, финальная синхронизация, проверка, переключение.

Переключение клиентов: DNS, DFS и обновление ссылок

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

DNS, DFS Namespace и GPO: что выбрать

Смена DNS-записи (A или CNAME) - самый быстрый вариант, но работать он будет только при низком TTL и при условии, что клиенты ходят по имени, а не по IP. Прямые UNC-пути с именем старого сервера в этом случае придется обновлять отдельно.

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

GPO и скрипты входа подходят, если DFS не используется: групповой политикой переназначаются сетевые диски на новый сервер. Для NFS-клиентов обновляют записи в fstab или карты autofs, либо заводят DNS-алиас и меняют только его.

Что делать с ярлыками, макросами и базами с UNC-путями

Жёстко прописанные пути встречаются в ярлыках на рабочих столах и в сетевых папках, макросах Excel и Word, конфигурациях приложений, файловых базах 1С и других учетных систем, заданиях планировщика, скриптах выгрузок и отчетности.

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

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

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

Сравнение ACL и владельцев: icacls и getfacl

Windows: icacls с ключом /save и параметром /T выгружает права источника в файл, тот же вызов на приёмнике дает второй файл, разница смотрится обычным сравнением. Для восстановления прав применяют icacls с ключом /restore. При миграции между доменами SID не совпадают, поэтому заранее готовят маппинг, иначе все права придется пересобирать вручную.

Linux: getfacl -R по источнику и приёмнику, затем сравнение выгрузок. Уже скопированное дерево проверяют холостым прогоном rsync с ключами -aHAX: расхождения в правах и атрибутах он показывает построчно.

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

Проверка ссылок, симлинков и длинных путей

Симлинки на Linux проверяют через readlink -f и поиск битых ссылок, на Windows - атрибутом L в выводе dir. Жёсткие ссылки на Linux видны по счетчику ссылок в выводе ls -l, на Windows - через fsutil hardlink list.

Длинные пути - отдельная зона риска. В Windows API максимальная длина пути MAX_PATH определяется как 260 символов, и копирование через проводник такие пути обрезает или пропускает. Поддержку длинных путей можно включить параметром реестра LongPathsEnabled (REG_DWORD) в HKLM\SYSTEM\CurrentControlSet\Control\FileSystem; этот же параметр контролируется групповой политикой Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths. Начиная с Windows 10 (1607) и Windows Server 2016 доступен отдельный параметр групповых политик для включения поддержки длинных путей, по умолчанию он отключён, и для применения настройки требуется перезагрузка компьютера. Копировать такие деревья лучше robocopy. В Linux ограничения другие: 255 байт на элемент пути и 4096 байт на полный путь, что на практике встречается редко, но при переносе из Windows проверить стоит. Ограничение MAX_PATH и параметр LongPathsEnabled описаны в документации Microsoft.

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

Типичные ошибки и как их избежать

Несовпадение прав и потеря ACL

Причины: копирование без ключей сохранения прав (robocopy без ключей переноса NTFS-прав, rsync без -A и -X), перенос через проводник или обычное копирование, миграция между доменами с разными SID. Типичный результат: все файлы получили владельца-администратора и унаследованные права, а пользователи потеряли доступ к своим каталогам.

Профилактика: всегда использовать ключи сохранения прав и атрибутов (для rsync -aHAX, для robocopy - режим с переносом NTFS-прав), проверять ACL на выборке до переключения, для межлесных миграций готовить сопоставление учетных записей заранее.

Длинные пути и обрезка имён

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

Открытые файлы и отсутствие снапшота

Причина: копирование в момент, когда пользователи пишут в файлы, и блокировки SMB, из-за которых robocopy пропускает занятые документы. В журнале это видно строками с ошибкой доступа. Профилактика: снапшот VSS, LVM или ZFS перед финальным прогоном и чтение журнала копирования до переключения.

Забытые зависимости и переключение без плана отката

К списку ошибок добавляются переключение DNS без снижения TTL, пропущенные макросы и базы с UNC-путями, отсутствие критериев «стоп» и плана возврата. Каждая из них лечится подготовкой: TTL снижают за сутки, зависимости инвентаризируют, критерии отказа фиксируют письменно до начала окна.

Финальный чек-лист и план отката

Чек-лист перед переключением

1. Инвентаризация завершена, таблица соответствия путей заполнена.
2. Окно согласовано, уведомления отправлены за день и за час.
3. Предварительная и промежуточная репликация выполнены, журналы без ошибок доступа.
4. Проверенная резервная копия есть, восстановление из неё хотя бы раз тестировалось.
5. TLL DNS снижен, таргеты DFS подготовлены к смене.
6. Снапшот источника создан, финальная синхронизация запущена.
7. SMB и NFS-сессии закрыты, запись на старый сервер остановлена.
8. Права проверены на тестовом каталоге и от имени разных пользователей.
9. DNS или таргет DFS переключены, тестовый клиент открыл и сохранил файл.
10. Мониторинг, журналы копирования и алерты включены, старый сервер переведен в режим только чтения.

План отката: когда и как возвращаться

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

Шаги отката: остановить запись на новом сервере, вернуть DNS или таргет DFS на старый адрес, при необходимости перенести изменения обратно (rsync или robocopy в обратную сторону), уведомить пользователей и разобрать причину. Обратный перенос нужен только если на новом сервере успели появиться изменения.

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