18.12.2025 10:24
В современных системах хранения есть проблема частичного повреждения данных при длительном хранении.
В современных системах хранения есть проблема частичного повреждения данных при длительном хранении. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. Называют это Bit Rot или битовым гниением.
На работе я никогда не сталкивался с этим, потому что никогда не приходилось работать с данными, которые хранятся много лет и потом используются. Обычно все всё хранят на всякий случай, но потом данные 10+ лет мало кому нужны. Но даже если и нужны, то изменения нескольких бит не всегда приводят к каким-то фатальным последствиям, так что проблем можно и не заметить, кроме каких-то частных случаев с неизменяемыми архивами.
Дома замечал на очень старых фотках (15+ лет), что некоторые с искажениями или часть изображения не грузится. Не могу сказать на 100%, что это проблема с bitrot, но похоже.
Бороться с этим можно разными способами:
◽️Использование файловых систем с автоматическим контролем данных: ZFS, Btrfs, ReiserFS, Ceph. Хранилища на их основе должны быть собраны с избыточностью. То есть каждый файл должен храниться как минимум в двух или более копиях, чтобы было откуда восстанавливать повреждённый.
◽️Использование механизма Linux DM-integrity или аналогов. С его помощью можно любое блочное устройство превратить в устройство с контролем целостности. А поверх развернуть любую файловую систему. Если на устройстве с DM-integrity использовать Mdadm или LVM с избыточностью, то они тоже будут пытаться автоматически восстанавливать повреждённые файлы.
◽️Условно ручная периодическая проверка хэшей файлов с помощью тех или иных инструментов и восстановление повреждённых из других копий. Сами файлы могут храниться где угодно.
Нет однозначного решения, что лучше применять. Всё зависит от конкретной ситуации. Например, очень большие системы обычно используют именно третий вариант и просто хранят данные на обычных файловых системах и дисках, даже без рейд массивов, в нескольких копиях. А вся информация о файлах хранится в базе данных. Повреждённый файл заменяется из копии.
Для личных архивов холодных данных тоже на мой взгляд третий вариант проще и надёжнее. Даже если использовать ZFS, то должно быть несколько копий данных. А они уже сами по себе защищают вас от bitrot, главное узнать об этом вовремя. Достаточно иметь 2-3 копии в разных местах и периодически (не очень часто) проверять хэши фалов. Сделать это можно, к примеру, с помощью скрипта bitrot.
Скрипт рекурсивно сканирует директорию, из которой запущен, проверяет хэши SHA1 файлов, записывает результаты в SQLite базу, которую кладёт сюда же в директорию. Если хэш изменится, а дата изменения файла - нет, значит файл повреждён. Утилита об этом сообщит. Будет показан текущий хэш, прошлый и дата, когда он был сделан. Нужно будет повреждённый файл восстановить из бэкапа (который так же проверяется).
Покажу, как это работает. Копируем себе скрипт bitrot.py из репозитория, кладём в директорию с данными и запускаем:
# ./bitrot.py
Изменим один из файлов, сохранив его метку времени, чтобы потом восстановить:
# MTIME=$(stat -c %y file.bin)
Редактируем файл, если он текстовый, либо снимаем дамп хекс редактором и заливаем обратно. Примерно так:
# xxd file.bin > file.hex
Меняем файл file.hex текстовым редактором, заливаем обратно изменённый дамп:
# xxd -r file.hex file.bin
Восстанавливаем метку времени:
# touch -d "$MTIME" file.bin
Снова запускаем bitrot.py:
# ./bitrot.py
Checking bitrot.db integrity... ok.
error: SHA1 mismatch for ./file.bin: expected 615063b57508bf491223b5, got 95061866745edc76c75aebbe4. Last good hash checked on 2025-12-15 20:29:19+0000.
Видим расхождение в хэшах при неизменной mtime, что говорит о повреждении файла. Его надо восстановить.
В проде для архивов хорошо бы иметь ZFS с избыточностью, но это не отменяет подобную проверку, так как в самой ZFS тоже могут быть ошибки, либо где-то ещё. Старые данные всё равно желательно периодически сверять тем или иным способом.
#backup
На работе я никогда не сталкивался с этим, потому что никогда не приходилось работать с данными, которые хранятся много лет и потом используются. Обычно все всё хранят на всякий случай, но потом данные 10+ лет мало кому нужны. Но даже если и нужны, то изменения нескольких бит не всегда приводят к каким-то фатальным последствиям, так что проблем можно и не заметить, кроме каких-то частных случаев с неизменяемыми архивами.
Дома замечал на очень старых фотках (15+ лет), что некоторые с искажениями или часть изображения не грузится. Не могу сказать на 100%, что это проблема с bitrot, но похоже.
Бороться с этим можно разными способами:
◽️Использование файловых систем с автоматическим контролем данных: ZFS, Btrfs, ReiserFS, Ceph. Хранилища на их основе должны быть собраны с избыточностью. То есть каждый файл должен храниться как минимум в двух или более копиях, чтобы было откуда восстанавливать повреждённый.
◽️Использование механизма Linux DM-integrity или аналогов. С его помощью можно любое блочное устройство превратить в устройство с контролем целостности. А поверх развернуть любую файловую систему. Если на устройстве с DM-integrity использовать Mdadm или LVM с избыточностью, то они тоже будут пытаться автоматически восстанавливать повреждённые файлы.
◽️Условно ручная периодическая проверка хэшей файлов с помощью тех или иных инструментов и восстановление повреждённых из других копий. Сами файлы могут храниться где угодно.
Нет однозначного решения, что лучше применять. Всё зависит от конкретной ситуации. Например, очень большие системы обычно используют именно третий вариант и просто хранят данные на обычных файловых системах и дисках, даже без рейд массивов, в нескольких копиях. А вся информация о файлах хранится в базе данных. Повреждённый файл заменяется из копии.
Для личных архивов холодных данных тоже на мой взгляд третий вариант проще и надёжнее. Даже если использовать ZFS, то должно быть несколько копий данных. А они уже сами по себе защищают вас от bitrot, главное узнать об этом вовремя. Достаточно иметь 2-3 копии в разных местах и периодически (не очень часто) проверять хэши фалов. Сделать это можно, к примеру, с помощью скрипта bitrot.
Скрипт рекурсивно сканирует директорию, из которой запущен, проверяет хэши SHA1 файлов, записывает результаты в SQLite базу, которую кладёт сюда же в директорию. Если хэш изменится, а дата изменения файла - нет, значит файл повреждён. Утилита об этом сообщит. Будет показан текущий хэш, прошлый и дата, когда он был сделан. Нужно будет повреждённый файл восстановить из бэкапа (который так же проверяется).
Покажу, как это работает. Копируем себе скрипт bitrot.py из репозитория, кладём в директорию с данными и запускаем:
# ./bitrot.py
Изменим один из файлов, сохранив его метку времени, чтобы потом восстановить:
# MTIME=$(stat -c %y file.bin)
Редактируем файл, если он текстовый, либо снимаем дамп хекс редактором и заливаем обратно. Примерно так:
# xxd file.bin > file.hex
Меняем файл file.hex текстовым редактором, заливаем обратно изменённый дамп:
# xxd -r file.hex file.bin
Восстанавливаем метку времени:
# touch -d "$MTIME" file.bin
Снова запускаем bitrot.py:
# ./bitrot.py
Checking bitrot.db integrity... ok.
error: SHA1 mismatch for ./file.bin: expected 615063b57508bf491223b5, got 95061866745edc76c75aebbe4. Last good hash checked on 2025-12-15 20:29:19+0000.
Видим расхождение в хэшах при неизменной mtime, что говорит о повреждении файла. Его надо восстановить.
В проде для архивов хорошо бы иметь ZFS с избыточностью, но это не отменяет подобную проверку, так как в самой ZFS тоже могут быть ошибки, либо где-то ещё. Старые данные всё равно желательно периодически сверять тем или иным способом.
#backup