Сбои в файлах при длительном хранении

В который раз натыкаюсь на потерю данных в файле. В фотке. Случаи единичные на многие десятки тысяч фото, но нет-нет, а наткнёшься на фотку, отображаемую лишь до половины, например. Размер тот же, нулей внутри не видно, таймстамп прежний. exiftool возвращает корректные данные. Но если сравнить с бэкапом — md5 файла отличается. Можно бы было винить железо, но это уже третья машина с таким поведением. Было подозрение на xfs, но сейчас случай с ext4. Натыкался на такую потерю данных при переполнении раздела с ext4 при копировании (на уже скопировавшихся файлах), но сейчас копирования нет, на разделе свободно 96Гб из 690Гб. Такие же проблемы иногда всплывают в видеоколлекции. Только там обнаружить сложнее, при просмотре столь короткий сбой в глаза не бросается, а вот при пересчёте хеша торрента, нет-нет, да попадётся раз в несколько месяцев «закачано на 99.8%». За секунды докачивается до 100%, но такое дело есть. Единственное, что объединяет все эти случаи — Gentoo. Но ситуация повторяется регулярно в течении многих лет (не меньше 10), за это время и ядер сколько сменилось, и настройки компиляции... А вот на ntfs/windows многие файлы лежать ещё с середины 1990-х гг., пережив десятки копирований, начиная с винчестеров по 133..270Мб... К сожалению, по той же Ubuntu такой статистики нет, все её инсталляции у меня «временные», основные архивы или в ntfs/windows, или ext4/xfs/gentoo.

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

// Транслировано с juick.com

Просканировал ночью домашний фотоархив с помощью jpeginfo -c (странно, что раньше руки не доходили) и на 74 тыс. фотографий архива обнаружил 657 сбоев. Из них 563 случая обнуления файлов (это может объясняться тем, что архив несколько лет жил на XFS и не самым благоприятным электропитанием, без ИБП) и 94 случая повреждения данных во внешне целом файле. Как раз, тот случай, про который говорю. Архиву около 12 лет. Если считать, что его объём рос примерно линейно и среднее время хранения в нём файла составляет 74000/2*12 = 444 тыс. «файлолет», то один сбой приходится, в среднем, на 4700 «файлолет» хранения.

Если средний размер файла считать за 2Мб, то, в среднем, 1Мб данных повреждается за 9400 лет хранения. В видеоколлекции на 1Тб размером таким образом каждый год должно накапливаться около 100 сбоев. Вот тут встречно проверить точность оценки не могу. На хранящихся файлах сбои так просто не заметить, ну, мелькнёт в процессе воспроизведения сбойный блок, так они иногда и на свежевыкаченных 100% файлах бывают. А при пересчёте хешей раздач сбои (когда 100% закачки превращаются в «99.98%») встречаются не редко, но нет данных для статистики за какой период и т.п.

Кажется, докопался до причин.

Я недавно (25 июля) переносил данные со старого на новый HDD (выводил из LVM 2Тб с дохнущей механикой в пользу нового 4Тб). Но считал, что бэкап, в котором цел ряд файлов, повреждённых сейчас в основной копии, делал уже после этого переноса. Поднял форумные архивы (хорошо, когда сам для себя такие отчёты пишешь ), оказалось, я бэкап через btsync делал аж за месяц до переноса, процесс начался 27 июня и занимал несколько дней.

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

@$$%$^&(*&%^^%^$^% мать!
И видео (почти 2 ТБ), и аудио (более Тб). Но, слава богу не диски. При копировании рабочего файла - проигрывается сразу "квадратично". В общем, полетел SATA контроллер (Sil 3512). Подключил диск на встроенный - всё играет нормально. А то уж совсем кисло сделалось, всё что нажито непосильным торрентованием Поехал в Юлмарт.

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