Проверка передачи файлов по сети:
Иметь файловый сервер MS и два клиента (чтобы возможное локальное кэширование на клиенте не мешало вашим результатам).
На клиентской машине №1 создайте файлы (со случайным содержимым?) и сохраните их на сервере. В то же время вычислите контрольную сумму (скажем, md5sum?) для каждого тестового файла и, возможно, просто добавьте суммы, строку за строкой, в «файл индекса передачи суммы» на том же сервере.
На клиентской машине № 2 загрузите файлы один за другим с сервера и посчитайте контрольную сумму. На самом деле вы можете просто запустить инструмент контрольной суммы, такой как md5sum, для каждого файла в сопоставленном сетевом ресурсе (с машины клиента № 2). И сравните контрольные суммы с тем, что произвела исходная машина.
Это просто основная идея. Вам нужно будет написать несколько сценариев, чтобы автоматизировать проверки и позволить им работать в течение выходных или около того. А может быть, если битрот произойдет не сразу, а будет происходить на дисководах, возможно, такая быстрая проверка ничего не найдет.
Если у вас есть конкретный пример / инцидент с повреждением данных, есть ли способ получить исходный файл и поврежденный файл, которые должны были быть идентичными? В каком формате эти файлы? Является ли это машиночитаемым текстовым файлом (например, XML) или чем-то двоичным? Возможно, содержимое можно было бы сравнить, чтобы точно увидеть, как выглядит повреждение. Характер коррупции может дать дополнительные подсказки относительно того, откуда это могло исходить.
Помимо классического "diff", который работает с текстом ASCII, я помню есть инструменты специально для бинарного сравнения.
Кроме того, сервер хранения выполняет резервное копирование? Детали зависят от схемы резервного копирования, но дело в том, что если старая резервная копия на стороне сервера содержит исправный файл, а текущий файл с сервера поврежден, это, вероятно, сужает вашу проблему. И если экстраполировать эту тему резервного копирования, если у установки есть проблема с повреждением данных и нет надежной схемы резервного копирования, какая еще причина нужна вашей организации для работы над этим?
Даже если у вас больше нет нормального исходного файла: если поврежденный файл в конечном итоге будет отклонен частью программного обеспечения, анализирующего его, было бы неплохо получить более подробный журнал отладки, посмотреть, где парсер останавливается, где файл больше не является «правильным форматом», но я понимаю, что в программном обеспечении с закрытым исходным кодом, работающем с закрытым форматом файла, у вас обычно нет такой возможности.
Люди говорят, что это как раз и есть цель корпоративного оборудования для хранения данных, которое поддерживает «метаданные целостности» по всей «цепочке сигналов» — т. е. современные версии SCSI и производных технологий межсоединений (FC, SAS) и соответствующий класс вращающейся ржавчины, не уверен если есть SSD с такой возможностью. Вместо того, чтобы давать конкретные указатели, я предлагаю вам спросите Google о целостности данных в Linux. Скорее всего, это именно то, что вас укусило, на аппаратном уровне.Что вы знаете о базовой подсистеме хранения на сервере?
И, хотя это мизерный шанс: если у вас вообще проблемы с открытием старый файлы: обновляется ли прикладное программное обеспечение, работающее с файлами? Может ли это быть связано с тем, что обновление приложения нарушает совместимость со старыми данными? Если у вас нет резервных копий всех файлов, не могли бы вы организовать запись где-нибудь контрольной суммы вместе с именем файла, размером и отметкой времени, чтобы увидеть, является ли файл, извлеченный через 6 месяцев, тем же или другим?
Спасает "утомительная процедура ручного заряжания" - что именно?
Какой-то алгоритм восстановления работает с битым файлом?
Или просто извлечь исходный файл из соответствующей старой резервной копии?
В любом случае есть некоторая возможность узнать больше о характере проблемы: либо вы сможете сравнить поврежденный файл с хорошим исходным файлом, либо, возможно, узнать, что на самом деле делает процесс «восстановления» с «поврежденным» файлом. .
