Всем привет! Вижу, что тема старая, но меня также догнала похожая ситуация. Сразу прошу прощения за длинный рассказ, но он того стоит (кстати, история ещё не закончена). В течение года было три случая, когда пользователи жаловались на повреждение файлов, и в каждом из них нам не удавалось выявить закономерность, потому что у повреждённых файлов не изменялись временные метки (даже если файл лежал нетронутым, например, два года, он всё равно оказался повреждённым). Парадокс был в том, что даже несмотря на достаточно хорошую систему бэкапов (3 уровня, теневые копии, оперативные копии на сетевое хранилище, долгосрочные копии на внешние носители), оказалось, что повреждения были и в архивах (многочастные непрерывные архивы 7-ZIP, которые вообще исключают возможность повреждений внутри себя).
Например, в понедельник, 16 декабря 2024, пользователь сообщил, что файл, который он успешно открыл в пятницу, 13 декабря того же года, теперь повреждён, но все временные метки были ещё до даты инцидента (файл был создан в 2023, а изменён в ноябре 2024). Когда мы достали этот файл из архива от 6 декабря 2024, оказалось, что и там файл повреждён. Сначала думали на Microsoft DFS, затем на SAN и хранилище, но проблем там не нашли и обратили внимание, что подобные сбои были только с файлами определённого формата (Autodesk ArtCAM). Иногда, распаковывая архивы на другой машине и вне серверной с её сетью, выяснялось, что файлы из архива начинают открываться. Мы поместили их в нужные общие папки (восстановленные) и я стал сравнивать повреждённые файлы с извлечёнными из архива в HEX-редакторе и обнаружил отличия (на скриншоте в приложении — повреждённый файл слева, исправный справа).
Меня заинтересовало, что это похоже на простое инвертирование битов, но не всегда. Ещё страннее было то, что спустя время всё исправлялось само собой, и файлы чудесным образом начинали открываться и работать как надо (и из архивов, и из теневых копий, и из общей папки, то есть они точно не были просто скопированы из архива). Экспериментально выяснили, что помогает перезагрузка сетевого оборудования (главный 10-гигабитный роутер в серверной — CCR2004, а два подключенных к нему снизу — CRS354 и CRS328, которые связаны оптикой через WDM-волоконные передатчики). Также заметили, что в этот момент снижается отклик и скорость передачи между коммутаторами — проблема локализована как неполадка с оптическим соединением. Сейчас планируем заменить оптические передатчики, но корень проблемы ещё не найден. К сожалению, такая ситуация происходит достаточно редко, чтобы выявить объективную причину. Но точно можно сказать, что проблема именно в части передачи данных по сети и проявляется только с определёнными типами данных. Может, кто-то сможет распознать закономерность на скриншотах в приложении.
Несколько скриншотов для анализа:
