Очень много архивных данных
За выходные накопилось очень много что написать, но честно говоря я решил немного отдохнуть и отдых этот - это приведение в порядок личных архивов. Вернее они хоть и личные, но более менее рассортированные большие и малые датасеты, архивы веб-сайтов, изображений, медиа, данных замороженных или не стартовавших проектов, действительно личных файлов и много всего другого.
Но, есть время накапливать данные на любых носителях, а есть время приводить всё в порядок, складывать в NAS, резервировать критичное с защищённом облаке и так далее. Уверен что я не единственный кто занимается подобной уборкой когда есть свободное время.
Что из этого стоит записать на будущее:
1. Всячески избегать большого числа множества схожих, но очень малых файлов. Их архивация - это долго, больно и неправильно. Лучше ещё на этапе их получения/извлечения сразу складывать их в контейнеры вроде архивных файлов (zip, tar), баз данных (sqlite, duckdb) или монтируемых файловых систем вроде veracrypt. Потому что при всех рисках битых секторов, архивация множества мелких файлов очень медленный процесс.
2. Все чувствительные файлы всегда хранить в зашифрованных контейнерах (всё тот же veracrypt поможет). На случай повреждения таких файлов, держать несколько их копий. Вся работа с чувствительными данными также всегда должна быть внутри зашифрованных контейнеров.
3. Правило 3-2-1 для резервных копий очень простое и придумали его не дураки. Придерживаясь его можно избежать наиболее неприятных ситуаций с потерей данных.
4. Файлы веб-архивов неэффективны для сжатия. По умолчанию инструменты работы с WARC файлами поддерживают только если файлы не сжаты или сжаты gzip, а сами файлы вне зависимости от типа хранятся вперемешку. WARC устарел как контейнер, но хранение множества мелких файлов гораздо хуже и сопряжено с потерей метаданных.
5. Документация - это главный технический долг в отношении данных и архивов. Особенно когда восстанавливаешь архивы 20 и более летней давности. Иногда остаётся код с помощью которых данные были получены, иногда первичные данные, иногда даже описание из первоисточника, но полная прослеживаемость есть далеко не всегда.
6. Длинные не-латинизированные имена файлов - это зло. При копировании из NTFS в файловые системы Linux слишком часто возникают ошибки из-за длинных названий файлов на кириллице. Решается это переименованием или помещением файла в контейнер, но тем не менее
Впрочем, все выводы кажутся очевидными и касаются не только личных архивов. А многое требует осмысления как архивными данными работать, какие интерфейсы должны быть доступны. И документация, технический долг документации на данные безбрежен. Трудоёмкость её написания зачастую выше трудоёмкость сбора самих данных, но тут какого-то простого решения не наблюдается.
#datahoarding #thoughts #backups #data
За выходные накопилось очень много что написать, но честно говоря я решил немного отдохнуть и отдых этот - это приведение в порядок личных архивов. Вернее они хоть и личные, но более менее рассортированные большие и малые датасеты, архивы веб-сайтов, изображений, медиа, данных замороженных или не стартовавших проектов, действительно личных файлов и много всего другого.
Но, есть время накапливать данные на любых носителях, а есть время приводить всё в порядок, складывать в NAS, резервировать критичное с защищённом облаке и так далее. Уверен что я не единственный кто занимается подобной уборкой когда есть свободное время.
Что из этого стоит записать на будущее:
1. Всячески избегать большого числа множества схожих, но очень малых файлов. Их архивация - это долго, больно и неправильно. Лучше ещё на этапе их получения/извлечения сразу складывать их в контейнеры вроде архивных файлов (zip, tar), баз данных (sqlite, duckdb) или монтируемых файловых систем вроде veracrypt. Потому что при всех рисках битых секторов, архивация множества мелких файлов очень медленный процесс.
2. Все чувствительные файлы всегда хранить в зашифрованных контейнерах (всё тот же veracrypt поможет). На случай повреждения таких файлов, держать несколько их копий. Вся работа с чувствительными данными также всегда должна быть внутри зашифрованных контейнеров.
3. Правило 3-2-1 для резервных копий очень простое и придумали его не дураки. Придерживаясь его можно избежать наиболее неприятных ситуаций с потерей данных.
4. Файлы веб-архивов неэффективны для сжатия. По умолчанию инструменты работы с WARC файлами поддерживают только если файлы не сжаты или сжаты gzip, а сами файлы вне зависимости от типа хранятся вперемешку. WARC устарел как контейнер, но хранение множества мелких файлов гораздо хуже и сопряжено с потерей метаданных.
5. Документация - это главный технический долг в отношении данных и архивов. Особенно когда восстанавливаешь архивы 20 и более летней давности. Иногда остаётся код с помощью которых данные были получены, иногда первичные данные, иногда даже описание из первоисточника, но полная прослеживаемость есть далеко не всегда.
6. Длинные не-латинизированные имена файлов - это зло. При копировании из NTFS в файловые системы Linux слишком часто возникают ошибки из-за длинных названий файлов на кириллице. Решается это переименованием или помещением файла в контейнер, но тем не менее
Впрочем, все выводы кажутся очевидными и касаются не только личных архивов. А многое требует осмысления как архивными данными работать, какие интерфейсы должны быть доступны. И документация, технический долг документации на данные безбрежен. Трудоёмкость её написания зачастую выше трудоёмкость сбора самих данных, но тут какого-то простого решения не наблюдается.
#datahoarding #thoughts #backups #data