Я нахожусь в процессе вывода из эксплуатации старого сервера 2003 года, который действует как файловый сервер, и просто пытаюсь выполнить пробный запуск миграции репозитория файлов на новый сервер Windows Storage Server 2012. Я использую robocopy для копирования файлов и в настоящее время просто выполняю несколько тестовых прогонов, чтобы узнать, сколько времени потребуется, прежде чем мы внесем окончательное изменение.
В первый раз, когда я запустил robocopy, я предоставил следующие переключатели: Параметры: . / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 100000 / W: 30 Он работал нормально (хотя я бы не рекомендовал переключатели / r и / w, так как это займет целую вечность!) во второй раз я запустил его со следующими переключателями (целевой каталог уже содержал копию исходного назначения с первого раза, / MIR обеспечит его обновление): Параметры: . / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 0 / W: 0
Это привело к зависанию сервера примерно через 5 минут после запуска задания. Он полностью завис, и мне пришлось вручную выключить и снова включить его, чтобы перезапустить. Журналы не дают мне четких указаний на то, что пошло не так - я думал, что / mt: 128 вызвал проблемы, но я поставил этот переключатель в первый раз, и это было нормально.
Во второй раз я меняю пару переключателей на / r: 0 и / w: 0, хотя я и представить себе не мог, что они могут вызвать его зависание.
И, наконец, тот факт, что я выбрал / MIR проблематичным, поскольку место назначения уже было скопировано из источника однажды раньше - я бы так не подумал, хотя, как я думал, единственным потенциальным недостатком зеркалирования было то, что оно удаляло файлы в место назначения, которого больше нет в источнике. Если кто-то может пролить свет на то, что пошло не так, он гарантирует, что в следующий раз, когда я попробую, ничего не пойдет не так.
EDIT: переключатели, о которых я упоминал выше, взяты из файла журнала robocopy, и в некотором смысле они являются интерпретацией указанных мной переключателей, а именно: / MIR / COPY: DATSOU / MT: 128 / R / W
2-е изменение: рассматриваемый сервер имеет двойную сетевую карту, объединенную с использованием встроенной в Windows Server объединения сетевых адаптеров. Я считаю, что это важная информация, которой я не поделился, когда первоначально разместил вопрос. Хотел бы разобраться в этом. Рассматриваемая сетевая карта - это гигабитное сетевое соединение Intel (R) 82574L. Команда NIC - это «Драйвер мультиплексора сетевого адаптера Microsoft».
Мне кажется, что Robocopy A) содержит ошибки и B) каким-то образом подключается к ядру, что может сделать всю систему невероятно нестабильной, когда она выходит из строя. Мы видели, что это происходило довольно часто (особенно с опцией MT) при синхронизации по достаточно высокоскоростным каналам WAN (20 Мбит / с - 100 Мбит / с). Так что я почти уверен, что проблема с объемом трафика связана не с драйвером сетевой карты - мы делаем вещи в производственной среде, которые злоупотребляют ими гораздо хуже, чем это, и мы видим это даже при подключении к локальной сети 10 Гбит / с на Cisco UCS / VMWare 5.5, когда все исправлено и Robocopy v6.3.9600.17415 от 28.10.2014.
Мне бы хотелось, чтобы кто-нибудь убедительно доказал, что мы все делаем что-то глупое, но похоже, что Microsoft просто выпускает какой-то невероятно опасный код.
Похоже, это проблема с драйвером сетевой карты. Чтобы узнать, не является ли это ошибкой в вашей настройке с двойным ником, установите параметр IPG примерно на 20 миллисекунд и удалите параметр / MT: 128 (поскольку / IPG и / MT несовместимы). Используя вашу строку «переключатели, которые я указал» в вашем исходном сообщении, это будет выглядеть так.
/MIR /COPYALL /R /W /IPG:20 /Z
/ IPG: 20 (межпакетный интервал) значительно замедлит передачу, но обеспечивает стабильность.
/ Z (перезапускаемый режим) важен для копий по сети в случае сбоев в сети (вызванных неисправными картами, драйверами или фактическими сетевыми проблемами), потому что он позволяет копии продолжить с того места, где она остановилась.
Если это завершится успешно, у вас проблема с сетевым драйвером. Проблема будет в том, что какой бы драйвер вы ни использовали, он не может обрабатывать пропускную способность / IPG: 0.
Последним гвоздем в крышку гроба для драйвера сетевой карты, являющегося основной причиной зависания вашего сервера, будет замена карты и повторный запуск команды, которая вызвала ее зависание. Кроме того, вы, вероятно, также можете отключить одно из подключений, чтобы мультиплексирование не происходило, и запустить команду, которая вызвала ошибку.
Предложение пришло от cb42 на technet.
... и скалы ss64 (просто скажи!) http://ss64.com/nt/robocopy.html
Почему вы используете /S с участием /E? Вроде бы наоборот. И /E + /Purge равно /Mirror. И я считаю, что / MT: 128 - это слишком много, вы должны его уменьшить. Пытаться:
/S /MIRROR /COPYALL /MT:64 /R:10 /W:60