?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

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


Feb. 7th, 2018 03:08 pm Архивация - проблемы и решения

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

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

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

Архивация это презервания информации на длительный срок, больше года. Ряд проблем, которые возникают на таком отрезке, принципиально другой. Например, на отрезке в несколько лет возникает проблема 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%)

26 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:birdwatcher
Date:February 7th, 2018 11:23 pm (UTC)
(Link)
Мне эта тема очень близка, и я пришел к выводу, что компьютерного решения эта проблема не имеет. На отрзках порядка сотни лет тексты лучше всего хранятся напечтаннами на качественной бумаге, фотографии - снятыми на качественную плёнку. Заодно и дешевле всего.
From:morfizm
Date:February 7th, 2018 11:33 pm (UTC)
(Link)
Мне кажется, она имеет компьютерное решение. Она не имеет разового компьютерного решения. Т.е. раз в 5-10 лет надо делать какие-то шаги, чтобы причесать и преобразовать в новый формат уже имеющуюся коллекцию. Возможно, придётся это делать с потерями. Тогда задача обретает такой смысл: как это делать с минимальными затратами и минимальными потерями.

Ваш вариант очень сильно ограничивает объём инфы, который можно сохранить. Это только тексты, только небольшое их количество, только такие тексты, которые по формату удобны для печати.

Кроме того, вы не учитываете стоимость хранения. Место в квартире стоит денег. Если вы арендуете, это % от аренды. Вам приходится ходить на работу, чтобы поддерживать эти расходы. Если вы домовладелец, значит, вы ещё большие деньги выплатили раньше. Плюс вынуждены платить ongoing property tax, utility bills, платить за уборку или делать её своими руками. Любые физические вещи, хранящиеся в вашей квартире, можно рассматривать как asset, который вы обслуживаете - деньгами, работой.

Поэтому принципиально от вопроса обслуживания невозможно уйти. Так или иначе придётся платить в процессе.
From:birdwatcher
Date:February 7th, 2018 11:49 pm (UTC)
(Link)
Ну это не абсолютно бесплатно, но требования минимальные. Нужно, чтобы сверху не текла вода и не было частых заморзков и оттаиваний. Но если я уже и так живу в квартире, то это автоматически выполнено. Конечно, компьютеру тоже нужно, чтобы на него не текла вода. Теперь представляете, если я возьму ваш корпус от компьютера, выкину из него всю начинку и набью альбомами с фотографиями? Такого хранилища хватит на всю жизнь.
From:morfizm
Date:February 8th, 2018 12:43 am (UTC)
(Link)
Честно говоря, нет, я не очень представляю себе это.
Вот у меня 60 тысяч фотографий.

Я могу себе представить себе, что в системный блок влезет 20 альбомов по 100 фотографий. Это 2000.

Хранить все - это 30 системных блоков. Это уже заметно так, несколько квадратных метров до потолка. А как потом в этом искать?

Допустим, я хочу уменьшить количество фоток до 2000. Для этого мне нужно, как минимум, внимательно посмотреть на все фотки. Одно лишь это обойдётся мне в $6000 (пусть моё время ценится в $60/час; это $1/мин, 10 фотографий/мин, $0.1 за фотографию).

Вы предлагаете фотографии хранить на плёнке. Т.е. мне их переснять на плёнку? И потом показывать гостям на проекторе?

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

Ещё интереснее. Вот я сохраняю понравившиеся мне ютубовские ролики. Мне их переснимать на видеоплёнку? Сколько будет стоить сохранение одного ролика? Сколько будет стоить конвертация существующего? Как потом этим пользоваться? Вот пришёл ко мне в гости друг, мы выпили коньячку, и я хочу быстро найти по ключевым словам пару смешных роликов и включить, показать. Я быстренько перебираю пару кубометров плёнок, вставляю в проигрыватель, перематываю (!), показываю... так? :)
From:birdwatcher
Date:February 8th, 2018 12:56 am (UTC)
(Link)
Нет, 60 тысяч фотографий так не сохранишь, и ютуб не заархивируешь. Но 60 тысяч фотографий это 1667 36-кадровых пленок. Если снимать по пленке каждую неделю, зимой и летом, и если 100% кадров окажутся удачными, это 32 года съемок. Более реалистичным результатом считается три удачных кадра с пленки. Тогда выходит 384 года.
Такая же арифметика с письмами.
Т.е. если вы разрабатываете методологию для архивирования ютуба, то это круто, но для рядового пользователя отчасти избыточно.
From:morfizm
Date:February 8th, 2018 01:04 am (UTC)
(Link)
Ваше решение сводится к использованию таких инструментов, с помощью которых создание контента значительно (на порядки) ограничено по скорости, таким образом решаются все остальные проблемы - т.к. контента мало.

Если так, то можно ещё проще решить. Вообще не генерить никакой контент, не запоминать ничего в memories. Ultimately бесплатное решение всех проблем архивации - сделать так, чтобы множество архивируемых объектов было пустым.

Впрочем фотография - хороший пример. Снимать и хранить всё подряд требует меньше скилла, чем делать тщательно выверенные, удачные фотографии, в небольшом количестве. Другими словами, у рядового пользователя с куда большей вероятностью будет проблема "как мне manage'ить 60 тыс фотографий", чем у нерядового. Аналогично с ютубом. Что-то понравилось, я сохранил. Я не могу знать заранее, что из этого было по-настоящему достойно хранения. Это можно легко узнать after the fact, по статистике просмотров из архива. Но если я хочу ограничить заранее, мне нужно иметь скилл: иметь хороший вкус, быть хорошим видеокритиком, внимательнее анализировать, иметь и поддерживать какую-то систему критериев. Это работа, по-моему, даже бОльшая, чем работа по хранению. И всё равно будут false negatives (т.е. несохранённые клипы, о несохранении которых я потом пожалею.)
From:birdwatcher
Date:February 8th, 2018 01:07 am (UTC)
(Link)
ну где-то так, да
From:birdwatcher
Date:February 8th, 2018 03:03 pm (UTC)
(Link)
From:natpy
Date:February 8th, 2018 12:49 am (UTC)
(Link)
А что разве архивирование с избыточной информацией для восстановления не позволяет избежать битрота?
From:morfizm
Date:February 8th, 2018 12:59 am (UTC)
(Link)
Если под архивированием вы имеете в виду упаковку в архив, типа, rar -rr, то да, это даёт частичную защиту. Не 100%, но весьма неплохую. (100% защиты там будет, кажется, только для одиночного последовательного повреждения длиной не выше, чем recovery record).

Но я про другое, я про всю экосистему. Извлекать или добавлять файлы по одному, через rar интерфейс или командную строку - чрезвычайно неудобная вещь. Кроме того, нередко нужно посмотреть сразу несколько файлов, или файлы могут быть related (один не рабтоает без другого). Это значит, нужно распаковывать весь архив. Если нужно сделать изменение и обратно запаковать, где гарантия, что bit rot не случился в процессе распаковки-запаковки?

Отдельные файлы, лежащие в директориях (а не в rar архивах) - удобная штука. Если бы rar умел выплёвывать recovery record в виде отдельного файла (без создания архива), и потом её проверять и обновлять, то получилось бы примерно то, о чём я написал.
From:natpy
Date:February 8th, 2018 01:12 am (UTC)
(Link)
кажется рар умеет выделять рекавери информацию в отдельный том, где то я на такую инфу натыкался. В общем и целом описаная проблема конечно имеет место быть. вопрос только в области применимости. Мне вот лично эта задача не близка. я не представляю для чего мне может понадобиться хранить длительное время реально большие объемы информации, кроме разве что фотографий
From:morfizm
Date:February 8th, 2018 01:39 am (UTC)
(Link)
Я примерно по этой причине выложил идею в public, а не во friends-only.
Т.к. это мало кому интересно, то важен более широкий охват.
From:morfizm
Date:February 8th, 2018 03:46 am (UTC)
(Link)
> кажется рар умеет выделять рекавери информацию в отдельный том, где то я на такую инфу натыкался.

Не нашёл. Нашёл, что он умеет создавать recovery volumes. Это немного другое, там recovery record равен размеру volume. Т.е. если я хочу 1% recovery record, мне нужно заархивировать файл, разбив его на 100 volumes и rar выплюнет 101-й .rev файл.

Кроме того, не понятно, могу ли я не хранить оставшиеся 100 файлов, а потом заархивировать заново, но .rev файл взять из старого запуска. Даже если это работает, документация не гарантирует такого use case. Заявленный use case это у тебя много дисков, на которые ты разбиваешь архив, и ты хочешь защититься от того, что ровно один из них сломается.
From:sigman78
Date:February 8th, 2018 03:58 pm (UTC)
(Link)
есть такая штука как Parchive / PAR, которую можно натравить на любой архив
From:freeborn
Date:February 8th, 2018 08:53 pm (UTC)
(Link)
Да что тут предлагать… А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять всё да и слить в облачное хранилище, пусть у них в регионально реплицированном сторидже с ленточным бакапом лежит %)
From:morfizm
Date:February 8th, 2018 11:40 pm (UTC)
(Link)
А пользоваться архивом как?
Скачивать всё на локальный диск, ждать, пока проиндексируется поиском, искать-пользоваться, и снова удалять? :)
From:freeborn
Date:February 9th, 2018 02:12 am (UTC)
(Link)
всякие гуглодрайвы обычно дают искать и пользоваться онлайн
From:morfizm
Date:February 9th, 2018 02:14 am (UTC)
(Link)
С какой скоростью?
From:freeborn
Date:February 9th, 2018 02:18 am (UTC)
(Link)
со скоростью интернета, вестимо.
какой сценарий использования предполагается, сентиментально посмотреть на несколько 10 летней давности фоток, или тренировка ML на терабайте панорам?
From:morfizm
Date:February 9th, 2018 05:22 am (UTC)
(Link)
Да что угодно. Вот возьмём, например, простой бытовой сценарий. Для подачи на гринкард по браку нужны доказательства совместной жизни. Полезны также совместные фотографии, осбенно в компании общих друзей и знакомых. Вот, соответственно, юс-кейс:
1. Из 30 тыс фотографий отобрать те, которых есть я и есть моя супруга (предполагаем, что они уже каким-то образом потэганы, но нужен intersection двух тэгов), а также отобрать по периоду времени.
2. Быстро просмотреть около 1000 фоток, отобрать из них те, на которых есть другие люди (осталось 50).
3. Из этих 50 выбрать 10 лучших.
4. Скопировать их в папку с документами по гринкард процессу.
5. 2 из 10 фоток подредактировать перед печатью - изменить яркость-контраст и сделать кроп.
6. Распечатать (цветной принтер дома есть).

У меня на всё это уйдёт пара минут (ну, скажем, строго до 5 минут от момента "начал делать" до момента, когда первая фотография будет уже вылазить из принтера). Причём вне зависимости от причуд моего провайдера и от availability гугл-драйва.
Сколько времени уйдёт у вас с планшетом и гугл-драйвом?


Edited at 2018-02-09 05:28 am (UTC)
From:freeborn
Date:February 9th, 2018 05:39 am (UTC)
(Link)
Ну минут 10 в Google photos, теги по лицам оно само расставляет, поиск там есть, и редактор
Но если комкаст не упадёт конечно, тогда придётся по lte

From:morfizm
Date:February 9th, 2018 05:55 am (UTC)
(Link)
Все шаги? И печать? Кстати, шаг 4 это копирование из Google photos в Google drive. Чтобы отредакитировать пару фоток копию перед печатью, их нужно перенести обратно в Google photos, а потом обратно, или прямо из драйва можно?
From:freeborn
Date:February 9th, 2018 02:25 am (UTC)
(Link)
да, я забыл пояснить - моё мнение сильно biased, потому как я верю в скорую смерть домашних компьютеров и толстых терминалов, и во всеобщие облачные замки в будующем.
я даже выкинул десктоп на помойку, слил свои файлы и фотки в облака и пользуюсь дома в основном таблетами, в крайнем случае ноутбуком.

так что возможно я не сильно репрезентативен (хотя надеюсь и не одинок)
%)

From:morfizm
Date:February 9th, 2018 05:27 am (UTC)
(Link)
Вы не одинок, я знаю других людей, у которых так же :)

Моё мнение тоже несколько biased, но в другую сторону. Я считаю, что клаудсервисы это немеренная тормозня, bad availability, lock in proprietary database, and bad intetrop: lack of integration with other apps and storage services. Причём если всё так отвратительно с навороченным компом и гигабитным интернетом, то через вайфай и планшет всё ещё хуже, и в обозримом будущем (5-10 лет) никаких качественных изменений не светит. В лучшем случае гигабит будет у всех, а не только в некоторых районах. 10 гигабитный интернет будет вряд ли. С software будет ещё хуже. А люди, которым "хватает" это, на самом деле, люди, которые просто отказываются от кучи удобных юс-кейсов, ограничивая свою жизнь теми простыми функциями, которые таки работают более-менее сносно.

Т.е. я такой technology-пессимист :)
В скорую смерть домашних компьютеров я тоже верю, только "скоро = лет 30-50", а не 5, и не сегодня, и не вчера.
From:fizzik
Date:February 9th, 2018 04:01 am (UTC)
(Link)
Небольшое замечание по PDF.
PDF - это на самом деле целое семейство форматов, и то что файл любого из этих форматов имеет расширение *.pdf и открывается AcrobatReader'ом - не должно вводить в заблуждение.
Для долгосрочного архивного хранения специально предназначен один из форматов семейства - PDF/A. Для документов этого формата гарантируется, что все, что нужно для его отображения, хранится внутри документа. "В общем случае" для PDF это не так. Как и какой-нибудь DOC, документ PDF может ссылаться на шрифт просто по его имени, и для отображения использовать шриф с таким именем из системы, на которой вьюер запущен. (Это как один из примеров, почему PDF-документ со временем тоже может "сломаться")
From:morfizm
Date:February 9th, 2018 05:31 am (UTC)
(Link)
О, это очень ценная инфа, спасибо!