Перенос файлового сервера без остановки работы

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

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

Нулевой простой означает короткое управляемое переключение

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

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

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

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

Наконец, назначьте право остановить переключение. Если последняя дельта растет вместо сокращения, проверка ACL показывает расхождения или новый сервер не выдерживает обычную нагрузку, инженер смены должен иметь право сказать «не переключаем». Перенос, отложенный на неделю, неприятен. Перенос, после которого два отдела редактируют разные версии одного договора, обходится дороже.

Сначала зафиксируйте реальную поверхность сервиса

Инвентаризация должна охватывать данные, способы публикации и потребителей, иначе аккуратно скопированный том все равно окажется нерабочим сервисом. Начните с ресурсов SMB, локальных путей, параметров автономного кэширования, квот, теневых копий, антивирусных исключений, заданий резервного копирования и всех имен, по которым клиенты находят сервер. Проверьте DFS Namespaces, CNAME, прямые UNC-пути, подключенные диски через групповые политики и пути внутри приложений.

На Windows Server снимите два независимых списка: конфигурацию общих ресурсов и файловые ACL. Перенос одного не восстанавливает другое. Базовая выгрузка ресурсов выглядит так:

Get-SmbShare |
  Where-Object Special -eq $false |
  Select-Object Name,Path,Description,FolderEnumerationMode,CachingMode |
  Export-Csv C:\Migration\shares.csv -NoTypeInformation -Encoding UTF8

Get-SmbShareAccess -Name "Departments" |
  Export-Csv C:\Migration\departments-share-acl.csv -NoTypeInformation -Encoding UTF8

Сохраните вывод вместе с датой, именем источника и версией сценария. Экспорт только реестровой ветки LanmanServer\Shares полезен для аварийного восстановления конфигурации Windows, но не заменяет читаемый перечень и проверку параметров. Реестр также не объяснит, какие приложения используют путь и кто отвечает за проверку.

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

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

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

Найдите открытые файлы и постоянных писателей. Get-SmbOpenFile показывает текущие открытия на Windows, но снимок за одну минуту не раскрывает ночной импорт, пятничную выгрузку или ежемесячное закрытие периода. Соберите наблюдения хотя бы за полный рабочий цикл и поговорите с владельцами систем. Каталоги, куда служба непрерывно пишет сканы, телеметрию или экспорт, получают отдельный порядок остановки.

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

Новое хранилище проверяют до первой копии

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

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

Убедитесь, что цель видит те же удостоверения. В доменной среде права обычно хранят SID, а не красивое имя группы. Копирование ACL сохранит неизвестный SID так же добросовестно, как рабочий, но доступ от этого не появится. Проверьте доверительные отношения, миграцию учетных записей, разрешение SID, служебные учетные записи и группы с вложенным членством. Не заменяйте неизвестные SID широкой группой ради скорости.

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

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

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

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

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

Первая синхронизация переносит объем

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

robocopy "\\old-fs\Departments" "D:\Shares\Departments" /E /COPYALL /DCOPY:DAT /ZB /R:3 /W:5 /MT:16 /XJ /TEE /LOG:"C:\Migration\departments-pass1.log"

/COPYALL означает данные, атрибуты, метки времени, ACL, владельца и сведения аудита. /DCOPY:DAT сохраняет данные, атрибуты и время каталогов. /ZB сначала использует возобновляемое копирование, а при отказе доступа переходит в режим резервного копирования. Для него учетной записи нужны соответствующие права. /XJ исключает точки соединения и защищает от неожиданного обхода в другое дерево.

Явные /R:3 /W:5 обязательны для управляемого запуска. Документация Microsoft указывает для Robocopy значения по умолчанию в миллион повторов и тридцать секунд ожидания. Одна заблокированная цель с такими настройками способна превратить короткую операцию в бессмысленное ожидание. Число потоков /MT:16 дано как отправная точка, а не универсальный рецепт: его выбирают по результатам теста и уменьшают, если страдает рабочая нагрузка.

Не добавляйте /MIR к первой команде по привычке. Этот параметр равен /E вместе с /PURGE, поэтому удаляет на цели объекты, которых нет на источнике, и может перезаписать параметры безопасности корневого каталога цели. Зеркалирование уместно только после проверки путей и журнала в режиме списка /L, когда команда понимает, какие именно объекты будут удалены. На цели могут уже лежать служебные каталоги снимков или файлы другого процесса.

Код завершения Robocopy тоже требует интерпретации, а не проверки «ноль или не ноль». Коды от 0 до 7 могут означать успешное копирование с различиями, дополнительными или несовпадающими файлами; значение 8 и выше указывает хотя бы на один сбой копирования. Сохраните код, итоговую таблицу журнала и список FAILED. Затем разберите каждый отказ: длинный путь, исчезнувший во время прохода файл, недостаточное право, поврежденный объект или блокировка требуют разных решений.

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

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

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

Права доступа состоят из двух разных слоев

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

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

Снимите контрольные ACL до миграции:

$paths = @(
  "D:\Shares\Departments",
  "D:\Shares\Departments\Finance",
  "D:\Shares\Departments\HR"
)
$paths | ForEach-Object {
  $acl = Get-Acl $_
  [pscustomobject]@{
    Path  = $_
    Owner = $acl.Owner
    Sddl  = $acl.Sddl
  }
} | Export-Csv C:\Migration\acl-source.csv -NoTypeInformation -Encoding UTF8

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

Отдельно проверьте Access-Based Enumeration, если она скрывала недоступные каталоги. Без нее пользователь может увидеть названия чужих папок, хотя открыть их не сможет. Проверьте автономные файлы, если клиенты кэшируют ресурсы, и аудит доступа, если на нем держатся расследования или требования контроля. /COPYALL переносит сведения аудита в ACL, но аудит не заработает без подходящей системной политики на новой стороне.

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

Повторные проходы превращают терабайты в дельту

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

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

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

robocopy "\\old-fs\Departments" "D:\Shares\Departments" /MIR /COPYALL /DCOPY:DAT /ZB /R:3 /W:5 /XJ /L /FP /LOG:"C:\Migration\departments-mirror-dryrun.log"

Параметр /L только перечисляет действия. Изучите строки *EXTRA File и *EXTRA Dir, потому что при настоящем /MIR эти объекты исчезнут с цели. Если цель до переключения доступна только команде миграции и никто не должен создавать там данные, лишние объекты обычно означают ошибочный путь, остаток теста или неожиданное поведение другого процесса. Устраните причину, а не просто разрешите удаление.

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

Снимок VSS может дать согласованную точку чтения для поддерживаемого сценария, но он не отменяет финальную дельту и не гарантирует согласованность любого приложения. Проверьте, что поставщик приложения поддерживает такой способ. Если переносите между разными ОС, используйте инструмент, который сохраняет нужную семантику. Например, для Unix-подобных систем архивный режим rsync сам по себе не включает ACL, расширенные атрибуты и жесткие ссылки во всех нужных сочетаниях; параметры и сопоставление идентификаторов нужно выбирать явно.

Запрет записи делает финальную дельту честной

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

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

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

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

На этом этапе инженер принимает решение go или no-go по заранее записанным условиям. Усталость не должна превращать предупреждения в «наверное, нормально». Остановитесь, если время окна превышено, появились новые ошибки ACL, недоступна Active Directory, провалилась проверка пространства или продолжаются записи. Команда возвращает источник в обычный режим, сохраняет журналы и назначает новое окно после устранения причины.

Переключайте стабильное имя, а не клиентские настройки

Лучшее переключение сохраняет путь, которым уже пользуются сотрудники и приложения. Если клиенты открывают \\company.local\Files\Departments через DFS Namespace, замените цель папки и управляйте направлениями. Если они ходят прямо на \\old-fs\Departments, потребуется перенос сетевой идентичности, контролируемая смена DNS или изменение конфигурации клиентов. Последний вариант создает длинный хвост забытых сценариев и подключенных дисков.

DFS Namespace отделяет логический путь от конкретного сервера, но кэш направлений нужно учитывать. Документация Microsoft указывает типичное значение TTL для направления папки в 1800 секунд, а для корня 300 секунд. Значение можно временно снизить заранее, дать старому TTL истечь, провести переключение и позже вернуть нормальную настройку. Снижение TTL за минуту до окна не выгонит уже закэшированные старые направления.

Перенос имени и IP старого Windows Server на новый уменьшает число клиентских изменений. Storage Migration Service в Windows Server поддерживает такую фазу cutover: цель принимает сетевую идентичность источника, а источник получает другое имя и адрес, сохраняя свои данные. Microsoft предупреждает, что пользователи и приложения могут заметить перерыв из-за перезапусков и времени репликации Active Directory и DNS. Это честное описание, его и стоит положить в ожидания окна.

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

DNS-псевдоним кажется простым, но его нужно проверить с Kerberos и SMB hardening в конкретной конфигурации. Не отключайте проверки имен или защиту аутентификации глобально ради быстрого исправления. Зарегистрируйте нужные имена корректно, проверьте SPN и тестируйте доступ с обычного клиента, а не только локально под доменным администратором.

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

План переключения должен помещаться на одной странице

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

Проверенный порядок выглядит так:

1. Подтвердить готовность цели, резервной копии, связи с владельцами и право на изменение.
2. Остановить приложения-писатели, закрыть сеансы и технически запретить новые записи.
3. Выполнить финальную дельту, разобрать код возврата и контрольный проход /L.
4. Переключить DFS, имя или адрес, затем проверить DNS, Kerberos и SMB с клиентской машины.
5. Разрешить доступ небольшой контрольной группе, выполнить чтение, создание, изменение, переименование и удаление тестового файла.

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

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

В листе укажите ожидаемую форму вывода. Для Robocopy это итоговая таблица с количеством Dirs, Files, Bytes, столбцами Copied, Skipped, Mismatch, FAILED, Extras и кодом процесса. Условие «команда завершилась» бесполезно. Условие «FAILED равно 0, все Extras согласованы, код меньше 8 и контрольный /L не показывает дельту» можно проверить.

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

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

Откат заканчивается до первой записи в новую цель

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

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

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

Источник не форматируют и не переиспользуют на следующий день. В руководстве Storage Migration Service Microsoft советует некоторое время держать старый сервер доступным для извлечения данных, затем выключить, но сохранить перед окончательным выводом. Конкретный срок должен следовать политике резервного копирования, требованиям хранения и риску проекта. Важен сам порядок: сначала подтвержденная эксплуатация новой цели и проверенные резервные копии, потом изоляция, затем утилизация.

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

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