Миграция данных между СХД: как подготовить перенос и снизить риск простоя

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

В этой статье:

• Какие тома и приложения затронет перенос
• Совместимость старой и новой СХД
• Способы миграции между СХД
• Подготовка плана работ и окна переключения
• Перенос данных и переключение приложений
• Проверка целостности данных после миграции
• Возврат к исходной СХД при сбое
• Вопросы и ответы

Какие тома и приложения затронет перенос

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

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

Как определить состав данных для переноса

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

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

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

1. Получить список томов и сетевых папок. В системе управления СХД посмотреть их названия, идентификаторы, емкость и настройки доступа. Для блочных устройств выяснить, каким серверам они предоставлены. Для файловых ресурсов определить, кто использует общие папки.
2. Найти соответствующие диски на серверах. Проверить, какие устройства видит операционная система, какие разделы на них созданы и где они подключены. Для сопоставления использовать идентификаторы дисков. Буквы и названия могут отличаться от обозначений на СХД.
3. Изучить виртуальную инфраструктуру. В системе управления виртуализацией посмотреть, где размещены виртуальные машины и их диски. Если несколько серверов совместно используют одно хранилище, нужно учесть все связанные с ним рабочие системы.
4. Уточнить расположение данных приложений. Выяснить у администраторов, где находятся файлы баз данных, журналы транзакций и рабочие каталоги. Некоторые программы используют несколько дисков, поэтому их состав нужно проверять целиком.
5. Разобраться с ресурсами неизвестного назначения. Найти ответственных, изучить доступные сведения об использовании и выяснить, нужны ли данные действующим приложениям.

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

Как зафиксировать связи между томами и приложениями

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

Пример для условной корпоративной инфраструктуры:

Ресурс СХД	Где используется	Назначение	Ответственный
Том с файлами БД	Сервер баз данных	Основные файлы системы учета	Администратор БД
Том с журналами	Сервер баз данных	Журналы транзакций той же системы	Администратор БД
Общее хранилище	Узлы виртуализации	Диски виртуальных машин	Администратор виртуализации
Сетевая папка	Рабочие станции сотрудников	Общие документы	Администратор файловой службы

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

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

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

Совместимость старой и новой СХД

Новая СХД может подходить по емкости и производительности, но у действующих серверов возникнут проблемы с доступом к данным, если оборудование или программное обеспечение не поддерживают ее подключение. Например, сервер использует Fibre Channel, а выбранная система хранения работает только через iSCSI.

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

Поддержка протоколов и серверного оборудования

Начать стоит с протоколов, через которые серверы получают доступ к хранилищу. Для блочного подключения обычно применяют Fibre Channel (FC) или iSCSI. Первый используется в специализированных сетях хранения, второй передает команды обращения к дискам через сеть IP. Для файлового доступа распространены SMB и NFS.

У каждого варианта свои требования к оборудованию и программному обеспечению.

Протокол	Что необходимо проверить
Fibre Channel (FC)	Порты СХД, серверные адаптеры, коммутаторы, поддерживаемые скорости и совместимость компонентов
iSCSI	Поддержку протокола на серверах и новой СХД, возможности сетевых адаптеров и действующей сети
SMB	Версии протокола, способы проверки подлинности пользователей и поддержку необходимых функций файлового доступа
NFS	Совместимость версий, способы определения пользователей и механизмы разграничения прав

Например, при переходе с Fibre Channel на iSCSI серверу потребуется подключение к новой СХД через сеть IP. Следует выяснить, поддерживают ли действующие сетевые адаптеры и инфраструктура такое подключение. Возможно, для замены оборудования придется предусмотреть дополнительные компоненты.

Даже если обе системы используют Fibre Channel, их совместимость требует проверки. Значение имеют поддерживаемые сочетания адаптеров, коммутаторов и версий микропрограмм.

Операционные системы и многопутевой доступ

После проверки оборудования необходимо убедиться, что новая СХД поддерживает программную среду действующих серверов.

Производители систем хранения публикуют сведения о совместимости с Windows Server, Linux, VMware ESXi и другими платформами. В документации могут быть указаны конкретные версии операционных систем, драйверов и микропрограмм адаптеров.

Например, сервер со старой версией VMware ESXi может не входить в перечень поддерживаемых конфигураций новой СХД. В такой ситуации нужно выяснить, доступно ли обновление гипервизора и совместимо ли оно с остальным оборудованием.

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

В Windows Server для этого используют MPIO — механизм многопутевого ввода-вывода. Его работа зависит от поддержки конкретной СХД, используемого модуля управления устройствами и настроек выбора путей.

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

Требования кластеров и файловых систем

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

Кластерные диски. Когда несколько серверов совместно используют блочное хранилище, система должна поддерживать механизмы согласованного доступа. Например, отказоустойчивые кластеры Windows Server с общими дисками используют постоянные резервирования SCSI-3. Этот механизм помогает узлам управлять доступом к общему устройству.

Наличие Fibre Channel или iSCSI само по себе еще не подтверждает пригодность массива для такой конфигурации. Необходимо сверить требования используемой кластерной платформы с возможностями новой СХД.

Файловые системы и права доступа. При переходе между файловыми хранилищами разных производителей могут возникнуть различия в управлении разрешениями. Например, Windows использует списки управления доступом NTFS, а системы Linux могут применять разрешения UNIX и списки доступа других форматов.

Если сотрудники и приложения используют общие папки через SMB или NFS, новая СХД должна поддерживать необходимые способы проверки подлинности и разграничения прав. Особое внимание стоит уделить ресурсам, к которым обращаются одновременно системы Windows и Linux.

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

Как зафиксировать ограничения совместимости

После технической проверки для каждого требования нужно определить результат:

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

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

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

Способы миграции между СХД

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

Основные различия между способами:

Способ	Что переносит	Когда стоит рассмотреть
Средства СХД	Тома и их содержимое	Массивы поддерживают совместимую технологию передачи
Сервер	Файлы или содержимое дисков	Нужно перенести общие каталоги или тома между разными хранилищами
Гипервизор	Виртуальные машины и их диски	Данные размещены в поддерживаемом хранилище виртуализации
Приложение	Базы данных и связанные с ними сведения	Программа предоставляет собственные средства переноса

Разберем особенности каждого варианта.

Перенос средствами СХД

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

Например, в системах NetApp под управлением ONTAP используют технологию SnapMirror. Она поддерживает репликацию между совместимыми системами с учетом ограничений производителя.

Когда подходит: при замене оборудования, если старая и новая СХД поддерживают общий механизм передачи.

Что важно учитывать:

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

Главное преимущество такого подхода — передачей управляют системы хранения. Серверы с приложениями не выполняют основное копирование данных.

Копирование через сервер

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

Здесь применяют два варианта:

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

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

Основные ограничения:

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

Перенос средствами гипервизора

В среде виртуализации данные можно перемещать между хранилищами с помощью гипервизора — программы, которая управляет виртуальными машинами.

Например, VMware vSphere поддерживает технологию Storage vMotion. Она позволяет перенести файлы и виртуальные диски работающей машины на другое хранилище при соблюдении требований платформы.

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

Когда подходит: если данные размещены на виртуальных дисках, которыми управляет гипервизор.

Что может ограничивать перенос:

• Версия и возможности платформы. Средства миграции должны поддерживаться используемой конфигурацией VMware.
• Общие диски. Некоторые варианты совместного использования дисков виртуальными машинами имеют ограничения на перенос во время работы.
• Прямое подключение к СХД. Если гостевая операционная система самостоятельно подключается к хранилищу через iSCSI, Storage vMotion не переместит содержимое такого диска как обычный виртуальный диск VMware.

Таким образом, перед выбором данного способа необходимо определить, какие диски находятся под управлением гипервизора.

Миграция средствами приложения

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

Например, Microsoft SQL Server поддерживает:

• Восстановление из резервной копии. Администратор создает резервную копию базы и восстанавливает ее на другом экземпляре SQL Server.
• Доставку журналов транзакций. Система передает резервные копии журналов изменений и применяет их к целевой базе. Это позволяет поддерживать вторую копию с определенным отставанием от основной.

Когда подходит: если вместе с заменой СХД требуется перенести базу данных на другой сервер или экземпляр СУБД.

У данного способа есть особенности:

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

Если сервер и экземпляр базы данных остаются прежними, а меняется только СХД, использование средств приложения может оказаться избыточным.

Можно ли сочетать несколько способов

Да. В корпоративной инфраструктуре разные виды данных часто требуют отдельных инструментов.

Например, при замене одной СХД компания может использовать Storage vMotion для виртуальных машин, Robocopy для общих файловых каталогов и средства СУБД для базы данных, которую одновременно переносят на другой сервер.

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

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

Подготовка плана работ и окна переключения

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

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

Как составить план миграции

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

В план включают следующие сведения:

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

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

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

Как рассчитать время переноса данных

Для предварительной оценки используют формулу:

Время копирования = объем передаваемых данных / средняя скорость передачи

Объем и скорость необходимо привести к одинаковым единицам измерения. Например, если объем задан в мегабайтах, а скорость — в мегабайтах в секунду, результат получится в секундах.

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

На продолжительность влияют несколько факторов:

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

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

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

Как определить окно переключения

Окно переключения — заранее согласованный период, в течение которого специалисты завершают миграцию и переводят приложения на новое хранилище.

При планировании важно различать два понятия:

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

Эти периоды могут отличаться.

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

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

Что важно согласовать заранее:

1. Допустимый простой. Сколько времени конкретное приложение может оставаться недоступным без нарушения требований компании.
2. Период проведения работ. Когда сотрудники меньше всего зависят от системы. Например, перенос базы учета лучше не назначать на время подготовки месячной отчетности.
3. Предельное время переключения. До какого момента команда может продолжать работы и когда потребуется принять решение об их прекращении.

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

Зачем проводить пробную миграцию

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

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

Во время пробного переноса оценивают:

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

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

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

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

Когда можно начинать миграцию

После испытаний остается подтвердить готовность к основным работам.

Перед запуском необходимо убедиться, что:

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

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

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

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

Перенос данных и переключение приложений

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

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

Передача основной копии данных

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

Во время копирования нужно контролировать три показателя:

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

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

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

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

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

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

Если требуется остановка записи:

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

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

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

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

Как переключить приложения на новую СХД

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

Порядок зависит от того, каким образом рабочая система получает доступ к информации.

Тип ресурса	Что меняется при переключении
Блочный том	Сервер прекращает использовать исходный диск и получает доступ к целевому устройству
Общая папка SMB или NFS	Файловый ресурс начинает предоставлять содержимое нового хранилища либо приложение переводят на другой сетевой адрес
Виртуальный диск	Гипервизор изменяет расположение диска средствами поддерживаемой технологии
База данных	СУБД или приложение начинает использовать новое расположение файлов либо целевой экземпляр базы данных

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

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

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

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

Пример переноса файлового сервера на новую СХД

Рассмотрим условную инфраструктуру. Компания использует Windows Server в качестве файлового сервера. Документы сотрудников находятся на старой СХД, подключенной к нему как диск E:.

Новая система хранения уже подключена к тому же серверу и доступна как диск F:. Компания планирует сохранить существующие сетевые адреса общих папок.

Для копирования выбран Robocopy.

Исходные условия:

Параметр	До миграции	После миграции
Расположение документов	E:\Docs	F:\Docs
Сетевой путь	\\FILESRV\Docs	\\FILESRV\Docs
Хранилище	Старая СХД	Новая СХД
Файловый сервер	Windows Server	Тот же Windows Server

1. Первоначальное копирование

Администратор запускает Robocopy для передачи содержимого E:\Docs в F:\Docs.

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

Пользователи пока работают с документами на старом диске.

2. Передача последних изменений

Администратор повторно запускает копирование. Robocopy сравнивает исходные и целевые файлы с учетом выбранных параметров и передает необходимые изменения.

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

3. Переключение общего ресурса

Когда передача завершена, администратор изменяет расположение общей папки Docs: вместо E:\Docs файловый сервер должен предоставлять F:\Docs.

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

Это важное различие: Robocopy при соответствующих настройках переносит разрешения NTFS, но сама программа не переносит настройки общего сетевого ресурса.

4. Возобновление доступа

Администратор подтверждает, что общий ресурс указывает на F:\Docs, после чего разрешает пользователям снова открывать документы.

Сетевой адрес \\FILESRV\Docs остается прежним. В данном примере сотрудникам не требуется менять подключение к общей папке, поскольку имя файлового сервера и название ресурса сохранились.

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

Что должно быть выполнено после переключения

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

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

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

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

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

Как выявить пропущенные файлы и тома

Для начала сравнивают фактический состав нового хранилища с перечнем, подготовленным перед миграцией.

Для файловых ресурсов проверяют:

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

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

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

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

Как проверить сохранность содержимого

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

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

В Windows для такой задачи подойдет команда Get-FileHash в PowerShell. По умолчанию она использует алгоритм SHA-256.

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

1. Вычислить контрольную сумму исходного файла.
2. Получить значение для его копии на новой СХД с помощью того же алгоритма.
3. Сравнить результаты и выяснить причины обнаруженных различий.

Так можно проверить, например, перенесенные архивы, документы или другие файлы, которые должны остаться неизменными.

Когда контрольные суммы особенно полезны:

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

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

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

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

Проверка баз данных и виртуальных машин

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

Базы данных

После миграции администратор проверяет состояние базы средствами соответствующей СУБД.

Например, в Microsoft SQL Server есть команда DBCC CHECKDB. Она позволяет выявлять нарушения физической и логической целостности внутренних структур базы данных, включая таблицы и индексы. Конкретный набор проверок зависит от параметров команды.

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

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

Например, для системы учета ответственный специалист может проверить:

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

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

Виртуальные машины

В среде виртуализации администратор проверяет доступность дисков, состояние операционных систем и работу служб внутри машин.

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

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

Как проверить права доступа и работу пользователей

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

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

Для проверки выбирают учетные записи с разными правами.

Проверяемая операция	Ожидаемый результат
Открытие общей папки	Пользователь видит разрешенные каталоги
Чтение документов	Файлы открываются без ошибок
Создание и изменение файла	Сотрудник с правом записи может сохранить изменения
Обращение к закрытому каталогу	Доступ запрещен пользователю без соответствующих разрешений
Работа корпоративной программы	Основные операции выполняются без ошибок обращения к данным

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

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

Как оформить результаты приемки

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

Удобно использовать таблицу:

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

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

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

Возврат к исходной СХД при сбое

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

Главная сложность возникает после возобновления записи. Новые документы, изменения в базах данных и виртуальных дисках остаются на целевой СХД. Чтобы не потерять их при возврате, необходимо оценить состояние обеих систем и определить, можно ли восстановить актуальную информацию на старом оборудовании.

Когда стоит возвращаться к старой СХД

Решение зависит от характера неисправности, ее влияния на приложения и времени, необходимого для устранения.

Возврат может потребоваться в следующих ситуациях:

• Недоступны рабочие данные. Серверы потеряли соединение с новой СХД, а восстановить доступ в пределах согласованного времени не получается.
• Нарушена работа приложений. Из-за ошибок обращения к хранилищу критичные системы не могут выполнять необходимые операции.
• Недостаточная производительность. Задержки при чтении и записи превышают допустимые для приложений значения и мешают их работе.
• Обнаружена неисправность оборудования. Целевая система работает нестабильно, а устранить проблему без длительной остановки невозможно.

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

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

Как момент сбоя влияет на возможность возврата

Самая важная граница — начало записи на новую СХД. До нее прежняя копия может оставаться актуальной. После появления изменений ситуация усложняется.

Когда возникла проблема	Что учитывать
До переключения приложений	Если исходная СХД исправна и продолжает обслуживать приложения, можно отказаться от перехода
После переключения, до новых записей	Возврат возможен при сохранности исходных данных и восстановлении необходимых подключений
После начала записи на новую СХД	Нужно сохранить и учесть изменения, которых нет в прежней копии
После отказа новой СХД	Возможность возврата зависит от доступности последних изменений и допустимой потери данных

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

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

Как выполнить возврат к прежнему хранилищу

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

1. Прекратить новые записи

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

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

2. Определить, какие изменения нужно сохранить

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

Для разных типов данных применяют свои средства:

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

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

3. Передать необходимые изменения на старую СХД

Если оба хранилища доступны, можно использовать совместимые средства обратной передачи.

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

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

Некоторые системы хранения поддерживают обратную репликацию. Например, NetApp SnapMirror позволяет менять направление синхронизации в поддерживаемых конфигурациях.

4. Восстановить подключения к исходной системе

Когда актуальные данные подготовлены, администратор переводит серверы и приложения на прежнее хранилище.

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

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

5. Возобновить работу приложений

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

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

Что делать, если новую СХД невозможно прочитать

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

В такой ситуации специалисты выясняют, какие источники информации сохранились:

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

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

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

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

Вопросы и ответы