morfizm (morfizm) wrote,
morfizm
morfizm

Categories:

Архивация - проблемы и решения

Есть одна идея. Я над ней начал думать ещё много лет назад, но только сейчас начали оформляться более реалистичные идеи по поводу того, как воплотить её инкрементально, с минимальной потребностью в саппорте, и чтобы была достаточная польза.

Общая тема - архивация файлов. Многие путают архивацию с бэкапом, но это совсем не то же самое.

Бэкап это защита от потерь сегодняшней информации сегодня. Это может быть защита от сбоев оборудования, защита от вирусов, защита от дурака (обычно: от себя, от своих же неосторожных действий). Реализуется через избыточность: дубликаты файлов или избыточное кодирование, а также через регулярные процессы по поддержанию этой избыточности, например, периодическое копирование.

Архивация это презервания информации на длительный срок, больше года. Ряд проблем, которые возникают на таком отрезке, принципиально другой. Например, на отрезке в несколько лет возникает проблема bit rot: порча данных, которые никто не трогает, из-за случайных bit flip'ов. Она усугубляется при копировании (а ведь раз в несколько лет у людей происходит апгрейд компа или сервера, перенос информации), потому что bit rot возникает не только на магнитном носителе, а в регистрах процессора, в оперативной памяти, на шине материнской платы, в сетевой карте, во время передачи данных по сети.

Ещё - при копировании часто портятся метаданные - например, сбрасывается "дата создания файла" на текущую, или к "дате последней модификации" добавляется или убавляется один час из-за глюков с реализацией временных зон и летнего времени в операционной системе и в файловой системе. У директорий тоже портятся метаданные. Иногда при копировании файлов, какие-то файлы незаметно теряются, потому что их не получилось открыть из-за нарушения лимитов по длине пути к файлу. Порятся имена файлов из-за кодировок.

Более глубокая проблема на отрезке в 5-20 лет это то, что приложения перестают открывать файлы старого формата. Более простые, универсальные и свободные (непроприетартные) форматы надёжнее, чем сложные и коммерческие. Форматы с более полной информацией лучше, чем сжатые - чтобы была возможность последующей конвертации. Скажем, BMP лучше, чем PNG и GIF (проще). Они, в свою очередь лучше, чем JPEG (потому что lossless). OGG лучше, чем MP3 (потому что OGG открыт, а MP3 proprietary!). OpenDocument лучше, чем DOCX (по той же причине). При этом PDF для архивных документов некоторым образом ещё лучше. Хоть он не сохраняет внутреннюю структуру документа, и не позволяет редактировать, зато он лучше сохраняет расположение элементов и шрифты, куда выше шанс, что этот документ можно будет открыть, увидеть и распечатать в том же виде, каким он был при создании. Со временем системные шрифты и кодовые страницы меняются, и документы, зависящие от них (DOC, HTML/MHT, etc) открываются с кракозябрами. Исходники программ будут бессмысленны, если не сохранить текущие версии 3rd-party библиотек, инсталлятор компилятора, а также инсталлятор операционной систему, на которой он запускался, чтобы его можно было запустить в виртуальной машине.

Эту более глубокую проблему я пока решать не хочу, но вот проблему файлов "побитых" от долгосрочного хранения и копирования туда-сюда, решить можно. Проблема bit rot'а решена в некоторых файловых системах вроде ZFS или Btrfs, имеющих контрольные суммы и self-healing. Но это не спасает, потому что за *годы* файлы перемещаются не только внутри сервера, но и между компьютерами.

Конкретная идея, которая могла бы решить эту проблему - это хранить дополнительную защищающую информацию рядом с файлами.
Вариант для каждого файла создавать дополнительный - слишком большой overhead, удвоенное количество файлов замедлит работу и будет мешаться перед глазами.
Вариант иметь центральную базу данных - зависимость от одного компьютера это слишком большой риск потерь: файлы скопировались на компьютер, где этой базы нет, и там нет возможности проверить их целостность. А писать сложную распределённую систему синхронизации этих баз выглядит чем-то чрезмерно сложным, требующим сложной поддержки и настройки.

Мне кажется, хорошим компромиссом был бы вариант в каждой директории создавать служебный файл, вроде виндозного "Thumbs.db", в котором хранить метаданные про файлы в этой директории. Это может быть копия атрибутов, timestamp'ов и имени файла, контрольные суммы, или даже массив с error-correcting кодом, вроде Reed-Solomon, позволяющим восстанавливаться после bit rot'а или небольших data corruptions на уровне отдельных кластеров файла (такое тоже нередко происходит).

Базовые операции можно имплементировать через тул для командной строки (собрать инфу, сверить инфу, обновить инфу, починить файлы согласно инфе). Сверх этого можно придумать сервисное приложение, который эти операции будет делать по расписанию, а также GUI, чтобы спрашивать у пользователя подтверждение - например, действительно ли он менял вот эти файлы или это corruption, или что делать в случае конфликтов. Тот факт, что маленькие базы данных раскиданы по файловой системе и лежат вместе с файлами, позволит решить вопрос с децентрализованностью подхода: это должно быть нестрашно, если сервисное приложение работает на разных компьютерах, они все видят одну и ту же базу. В качестве дополнительного наворота - можно читать лог файловой системы, чтобы уменьшить false positive rates (например, если согласно логу в файл произведена запись, это значит, что это нормально, что его байты изменились - нужно не сообщать пользователю о проблемах, а просто обновить базу), а также отслеживать перемещения файлов.

Мне интересно, насколько полезен был бы такой тул вам лично?

Да, полезен
1(20.0%)
Да, полезен, но я уже пользуюсь существующими тулами, которые делают то же самое (напишу в комментах)
0(0.0%)
Нет, не полезен
2(40.0%)
Затрудняюсь ответить или "всё равно"
2(40.0%)
Tags: 1, ideas, polls questions and social games, software
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 26 comments