какой минимальный формат хранения данных
Форматы файлов в больших данных: краткий ликбез
Команда Mail.ru Cloud Solutions предлагает перевод статьи инженера Рахула Бхатии из компании Clairvoyant о том, какие есть форматы файлов в больших данных, какие самые распространенные функции форматов Hadoop и какой формат лучше использовать.
Зачем нужны разные форматы файлов
Серьезное узкое место в производительности приложений с поддержкой HDFS, таких как MapReduce и Spark — время поиска, чтения, а также записи данных. Эти проблемы усугубляются трудностями в управлении большими наборами данных, если у нас не фиксированная, а эволюционирующая схема, или присутствуют некие ограничения на хранение.
Обработка больших данных увеличивает нагрузку на подсистему хранения — Hadoop хранит данные избыточно для достижения отказоустойчивости. Кроме дисков, нагружаются процессор, сеть, система ввода-вывода и так далее. По мере роста объема данных увеличивается и стоимость их обработки и хранения.
Различные форматы файлов в Hadoop придуманы для решения именно этих проблем. Выбор подходящего формата файла может дать некоторые существенные преимущества:
Формат файлов Avro
Для сериализации данных широко используют Avro — это основанный на строках, то есть строковый, формат хранения данных в Hadoop. Он хранит схему в формате JSON, облегчая ее чтение и интерпретацию любой программой. Сами данные лежат в двоичном формате, компактно и эффективно.
Система сериализации Avro нейтральна к языку. Файлы можно обрабатывать разными языками, в настоящее время это C, C++, C#, Java, Python и Ruby.
Ключевой особенностью Avro является надежная поддержка схем данных, которые изменяются с течением времени, то есть эволюционируют. Avro понимает изменения схемы — удаление, добавление или изменение полей.
Avro поддерживает разнообразные структуры данных. Например, можно создать запись, которая содержит массив, перечислимый тип и подзапись.
Этот формат идеально подходит для записи в посадочную (переходную) зону озера данных (озеро данных, или data lake — коллекция инстансов для хранения различных типов данных в дополнение непосредственно к источникам данных).
Так вот, для записи в посадочную зону озера данных такой формат лучше всего подходит по следующим причинам:
Формат файлов Parquet
Parquet — опенсорсный формат файлов для Hadoop, который хранит вложенные структуры данных в плоском столбчатом формате.
По сравнению с традиционным строчным подходом, Parquet более эффективен с точки зрения хранения и производительности.
Это особенно полезно для запросов, которые считывают определенные столбцы из широкой (со многими столбцами) таблицы. Благодаря формату файлов читаются только необходимые столбцы, так что ввод-вывод сводится к минимуму.
Небольшое отступление-пояснение: чтобы лучше понять формат файла Parquet в Hadoop, давайте посмотрим, что такое основанный на столбцах — то есть столбчатый — формат. В таком формате вместе хранятся однотипные значения каждого столбца.
Например, запись включает поля ID, Name и Department. В этом случае все значения столбца ID будут храниться вместе, как и значения столбца Name и так далее. Таблица получит примерно такой вид:
| ID | Name | Department |
| 1 | emp1 | d1 |
| 2 | emp2 | d2 |
| 3 | emp3 | d3 |
Столбчатый формат более эффективен, когда вам нужно запросить из таблицы несколько столбцов. Он прочитает только необходимые столбцы, потому что они находятся по соседству. Таким образом, операции ввода-вывода сводятся к минимуму.
Например, вам нужен только столбец NAME. В строковом формате каждую запись в наборе данных нужно загрузить, разобрать по полям, а затем извлечь данные NAME. Столбчатый формат позволяет перейти непосредственно к столбцу Name, так как все значения для этого столбца хранятся вместе. Не придется сканировать всю запись.
Таким образом, столбчатый формат повышает производительность запросов, поскольку для перехода к требуемым столбцам требуется меньше времени поиска и сокращается количество операций ввода-вывода, ведь происходит чтение только нужных столбцов.
Одна из уникальных особенностей Parquet заключается в том, что в таком формате он может хранить данные с вложенными структурами. Это означает, что в файле Parquet даже вложенные поля можно читать по отдельности без необходимости читать все поля во вложенной структуре. Для хранения вложенных структур Parquet использует алгоритм измельчения и сборки (shredding and assembly).
Чтобы понять формат файла Parquet в Hadoop, необходимо знать следующие термины:
Здесь заголовок просто содержит волшебное число PAR1 (4 байта), которое идентифицирует файл как файл формата Parquet.
В футере записано следующее:
Формат файлов ORC
Оптимизированный строково-столбчатый формат файлов (Optimized Row Columnar, ORC) предлагает очень эффективный способ хранения данных и был разработан, чтобы преодолеть ограничения других форматов. Хранит данные в идеально компактном виде, позволяя пропускать ненужные детали — при этом не требует построения больших, сложных или обслуживаемых вручную индексов.
Преимущества формата ORC:
ORC хранит коллекции строк в одном файле, а внутри коллекции строчные данные хранятся в столбчатом формате.
Файл ORC хранит группы строк, которые называются полосами (stripes) и вспомогательную информацию в футере файла. Postscript в конце файла содержит параметры сжатия и размер сжатого футера.
По умолчанию размер полосы составляет 250 МБ. За счет полос такого большого размера чтение из HDFS выполняется более эффективно: большими непрерывными блоками.
В футере файла записан список полос в файле, количество строк на полосу и тип данных каждого столбца. Там же записано результирующее значение count, min, max и sum по каждому столбцу.
Футер полосы содержит каталог местоположений потока.
Строчные данные используются при сканировании таблиц.
Индексные данные включают минимальные и максимальные значения для каждого столбца и позиции строк в каждом столбце. Индексы ORC используются только для выбора полос и групп строк, а не для ответа на запросы.
Сравнение разных форматов файлов
Avro по сравнению с Parquet
ORC по сравнению с Parquet
Файловые системы накопителей
Содержание
Содержание
Именно файловые системы определяют способ хранения информации в виде привычных нам файлов, а также насколько быстро будет осуществляться доступ к данным и с какими ограничениями столкнутся пользователи.
Существует больше 30 файловых систем (ФС), большая часть которых имеет специфическое применение. Например, ФС под названием XFS создана исключительно для операционной системы IRIX, а DTFS — это файловая система, специализирующаяся на сжатии данных.
Если говорить относительно обычных пользователей ПК на Windows, MacOS и Linux, то для них список можно сократить до нескольких самых распространенных.
FAT32
Файловая система, разработанная компанией Microsoft на замену FAT16. Структурно вся область диска в FAT32 делится на кластеры размером от 512 байт до 32 Кбайт. Представьте себе тетрадь в клеточку. Каждая клетка — это кластер, в который может быть записан файл или его часть. Таким образом, большие файлы состоят из цепочки кластеров, которые совсем не обязательно будут располагаться друг за другом.
Не будем погружаться в технические дебри и расскажем о том, что больше всего интересует обычных пользователей — плюсы и минусы FAT32.
Главное и пока неоспоримое достоинство этой файловой системы — ее универсальность. FAT32 работает практически со всеми операционными системами Windows, а также без проблем распознается linux, MacOS, операционными системами игровых приставок и даже Android (если в смартфоне предусмотрена поддержка OTG).
Именно поэтому флеш-накопители чаще всего форматируют в FAT32, чтобы не иметь проблем с совместимостью на различных устройствах. С завода больше 90% всех флешек поставляется с этой ФС. Параллельно к плюсам относится высокая скорость работы с малыми и средними файлами (десятки/сотни мегабайт) и нетребовательность к объему ОЗУ.
Однако почтенный возраст FAT32 (больше 24 лет, что по меркам IT-индустрии просто огромный срок) накладывает ряд неприятных ограничений.
Несмотря на то, что размер тома с технической точки зрения может доходить до 8 ТиБ (тебибайт), что составляет около 8,7 ТБ, по факту в операционных системах Windows из-за встроенного ограничения вы не сможете создать том больше 32 ГБ. Соответственно, разметить большие жесткие диски, по крайней мере в Windows, в FAT32 не получится. Возникнут проблемы и с флешками на 64 ГБ.
Другое, более существенное ограничение — размер одного файла не может превышать 4 ГБ. Учитывая, что бэкапы, фильмы в высоком разрешении и архивы с различной информацией весят больше этого предела, ограничение доставляет массу неудобств.
exFAT
Одна из самых последних «новинок», созданная в 2008 году как расширенная версия FAT32 (extended FAT). Майкрософт решила взять лучшее и избавиться от самых неприятных недостатков.
exFAT ориентирована сугубо на переносные накопители — флешки, SD-карты и съемные жесткие диски. Размер кластера был увеличен до 32 мегабайт, благодаря чему размер файла теперь достигает целых 16 эксабайт (1 эксабайт = 1 048 576 ТБ). Задел на будущее у exFAT довольно внушительный.
Параллельно разработчики избавились от ограничения на размер тома, ввели поддержку прав доступа и минимизировали количество перезаписей, что особенно актуально для flash-памяти, ячейки памяти которой имеют ограниченное количество циклов записи, после чего выходят из строя.
Ощутимый минус только один — незначительная потеря совместимости. exFAT поддерживает Windows XP SP2 и более новые ОС. Соответственно, Windows 2000, NT и все, что старше, остается «за бортом». Усложнение структуры также привело к большим затратам вычислительной мощности компьютера. Однако на фоне современных процессоров с их потенциалом этим недостатком можно пренебречь.
New Technology File System разработали еще в 1993 году, однако, как и FAT32, используют по сей день. Сходство с FAT проявляется и в том, что, пространство делится на кластеры заданного размера. Однако высокую гибкость NTFS обеспечивает именно структура.
Первые 12% диска выделяются под MFT-зону — специальное служебное пространство, где хранится различная информация для работы всей ФС. Эта зона никогда не фрагментируется. В отличие от FAT используется бинарная структура.
Бинарное дерево располагает имена файлов таким образом, чтобы поиск выполнялся более быстрым способом — путем получения двухзначных ответов на вопросы о положении файла. Соответственно, поисковику не приходится просматривать всю цепочку файлов в каталоге.
NTFS обладает множеством достоинств. Максимальный размер тома на практике — 256 ТБ. Размера файла также хватит с запасом — около 16 ТБ. Помимо этого, за счет функции журналирования NTFS — отказоустойчивая система. Проще говоря, ФС либо выполняет действие до конца, либо откатывает все до состояния, когда действие еще не было совершено. Промежуточных «ошибочных» состояний практически не бывает. Имеется встроенное сжатие, средства разграничения прав объектов и шифрование данных.
К главному минусу NTFS относится низкая совместимость — не поддерживается все, что ниже Windows NT. Это не столь печально, но вот на MacOS и Linux записывать файлы на диски с NTFS не получится — только чтение. Игровые консоли Playstation и Xbox 360 также с этой файловой системой не работают.
Например, в PS4 можно отформатировать внешний жесткий диск, но только в формате самой приставки для обеспечения совместимости.
Таким образом, благодаря своему функционалу и поддержке больших объемов пространства NTFS — это отличный вариант для накопителей HDD и SSD. Несмотря на это, вы вполне можете создать на NTFS и флешку, но скорость ее работы по сравнению с FAT будет ниже.
Сравнительная таблица
Три приведенных файловых системы являются самыми популярными и наиболее совместимыми среди всех. Для удобства приведем основные параметры в общую таблицу.
Оптимальный формат хранения типовых данных
Некоторое время назад мы решили, что следует расширить спектр задач, реализуемых в рамках проектов, связанных с информационной безопасностью, включив в наш фокус сами события, регистрируемые средствами защиты. Ниже речь пойдёт об одной из составляющих нового для нас направления, связанного с технологиями BigData.
Исходная задача, которая стояла перед нашей командой, это анализ данных журналов регистрации и учёта с различных сетевых устройств и устройств систем информационной безопасности. Подобное оборудование генерирует события каждую секунду и в среднем могут выдавать более 1000 строк за 1 минуту своей работы. При этом генерируемые данные не подвергаются изменениям, т.е. данные только дополняются (append), но не изменяются (update).
Таким образом, у нас есть поток событий, подходящий под определение больших данных, которые не изменяются с течением времени, а их объем только увеличивается. Возник вопрос: как наилучшим образом эту информацию хранить с тем, чтобы с ней можно было бы работать в дальнейшем?
Все данные, которые так или иначе поступают и обрабатываются можно разбить по типам:
Данные на основе файловых структур
К подобным форматам относят: SequenceFiles, MapFiles, SetFiles, ArrayFiles и BloomMapFiles. Данные форматы оптимизированы для работы с MapReduce, в том числе через запуск с помощью компонент Pig и Hive.
Наиболее часто используемым из данных форматов является SequenceFiles. В нём данные хранятся в виде пар бинарный ключ – значение и в свою очередь они могут иметь три разных вида:
Каждый SequenceFile содержит заголовок, в котором хранятся метаданные о файле, такие как: используемый кодек сжатия, ключ и значение, sync маркер, пользовательские метаданные.
За пределами экосистемы Hadoop формат SequenceFile поддерживается в Java. Наиболее часто данный формат применяют как контейнер для маленьких файлов, но применительно к HDFS системе подобный вариант крайне ресурсоёмок, поскольку возникает существенный расход оперативной памяти ввиду хранения метаданных по каждому из файлов. Другим негативным эффектом является высокий расход вычислительных ресурсов процессора, поскольку каждый файл требует отдельной задачи, а малый размер файлов ведёт к увеличению их общего количества. Пример SequenceFile с использованием блокового сжатия приведён ниже (Рис. 44).
Форматы сериализации
Сериализация представляет собой процесс преобразования структур данных в поток байт для последующего хранения или передачи по сети. Обратный данному процесс именуется – десериализацией. В Hadoop применяются форматы сериализации такие как: Thrift, Protocol Buffers и Avro. Последний наиболее распространён ввиду того, что создавался для работы в Hadoop.
Заголовок файла содержит метаданные и уникальный sync маркер (аналогично SequenceFire данный маркер используется для разделения блоков в файле, позволяя разделять файлы на части). Помимо заголовка, Avro файл содержит непосредственно блоки данных, которые могут быть сжаты (поддерживаются алгоритмы Snappy и Deflate).
Пример Avro файла приведён на рис. 45.
Avro поддерживает следующие типы данных:
Колоночные форматы
Hadoop поддерживает несколько колоночно-ориентированных форматов данных – RCFile, Hive format, Optimized Row Columnar (ORC) и Parquet.
Чаще всего в системах применяют именно Parquet. Apache Parquet – это бинарный, колоночно-ориентированный (столбцовый) формат хранения данных. Parquet является довольно сложным форматом по сравнению с тем же текстовым файлом с json внутри. Parquet использует архитектуру, основанную на «уровнях определения» (definition levels) и «уровнях повторения» (repetition levels), что позволяет довольно эффективно кодировать данные, а информация о схеме выносится в отдельные метаданные. При этом оптимально хранятся и пустые значения. По сути, Parquet, это просто файлы, а значит с ними легко работать, перемещать, резервировать и реплицировать.
Колончатый вид позволяет значительно ускорить работу аналитика, если ему не нужны все колонки сразу. Например, рассмотрим, как хранится одна и та же таблица в текстовом файле и в файле Parquet.
При строковом хранении данных (txt, csv, Avro и т.д.) в файле наша таблица выглядит следующим образом:
В файле Parquet данные будут располагаться так:
На первый взгляд разница не велика, но суть в том, что когда речь заходит о размерах данных свыше нескольких миллионов строк, то кажущейся несущественной разница в чтении в 1 мс., превращается в часы ожидания. Теперь представьте:
Необходимо постоянно думать о схеме и типах данных, но данные журналов регистрации и учёта, как правило, с одного и того же оборудования генерируются по заданной схеме и с заданным форматом.
Данные, хранящиеся в Parquet, невозможно изменить и как следствие, они не поддерживают транзакции.
Выбор формата
В Hadoop предусмотрено несколько форматов хранения данных для последующей их обработки в системе. Для каждого из типов данных может быть более оптимальным один из возможных форматов хранения. Кроме того, на то, какой из типов данных выбрать существенно влияет то, какую задачу мы предполагаем решать, работая с данными (писать данные и их изменять/читать полную строку данных со всем содержимым/выборочно читать фрагмент данных и т.д.).
Сравнительная таблица ключевых параметров форматов данных представлена ниже (Табл. 2).
Таблица 2. Сравнение форматов файлов данных
Таблица 3.Сравнение форматов Avro и Parquet
Учитывая вышесказанное и то, что наши данные с течением времени не меняются (а значит могут быть «жёстко» описаны) оптимальным форматом хранения данных для нас представляется формат Apache Parquet. С форматом хранения мы определились, возник вопрос – какой инструмент выбрать для того, чтобы эффективно с ним работать?
Выбор формата
Оттолкнувшись от того, что нам требуется скорость и удобство работы с хранимой информацией, желательно при помощи традиционных SQL-запросов, мы решили использовать компонент Impala.
Impala – это механизм SQL-запросов MPP (Massive Parallel Processing) для обработки больших объемов данных, хранящихся в кластере Hadoop. Impala – программное обеспечение с открытым исходным кодом, написанное на C++ и Java. Он обеспечивает высокую производительность и низкую задержку по сравнению с другими механизмами SQL для Hadoop. Другими словами, Impala – это высокопроизводительный механизм SQL, который обеспечивает быстрый способ доступа к данным, хранящимся в распределенной файловой системе Hadoop.
Impala объединяет поддержку SQL и многопользовательскую производительность традиционной аналитической базы данных с масштабируемостью и гибкостью Apache Hadoop, используя стандартные компоненты, такие как HDFS, HBase, Metastore, YARN и Sentry. С помощью Impala пользователи могут общаться с HDFS или HBase с помощью запросов SQL быстрее, по сравнению с другими механизмами SQL, такими как Hive. Impala может читать практически все форматы файлов, такие как Parquet, Avro, RCFile, используемые Hadoop.
Impala использует те же метаданные, синтаксис SQL (Hive SQL), драйвер ODBC и пользовательский интерфейс (HUE), обеспечивая знакомую и унифицированную платформу для пакетных запросов или запросов в реальном времени. В отличие от Apache Hive, Impala не основана на алгоритмах MapReduce. Он реализует распределенную архитектуру на основе процессов-демонов, которые отвечают за все аспекты выполнения запросов, выполняющихся на одних и тех же машинах. Таким образом, это уменьшает задержку использования MapReduce, и это делает Impala быстрее, чем Apache Hive.
Основные преимущества Impala:
Таким образом, мы определили для себя основной формат хранения и запросов к собираемым данным в создаваемой нами системе. Тестовые испытания показали более быструю скорость выполнения запросов к данным, хранимым в нашей системе, относительно тех же событий, хранящихся в SIEM системах на базе ArcSight, ArcSight Logger и ArcSight Vertica, что позволяет нам со сдержанным оптимизмом смотреть на нашу будущую архитектуру.
«Облако», HDD или SSD: где лучше сохранится информация спустя 20−50 лет и как умирают данные
Какого-то единственного правильного решения такой задачи нет, поскольку исходя из личного опыта многие пользователи предлагают разные достижения поставленной цели. После прочтения постов на разных форумах становится понятно одно — хранить важную информацию на неиспользуемых на постоянной основе накопителях нельзя. Дело не только в размагничивании самих дисков или деградации ячеек памяти, но и увеличении энтропии, ведущей к искажению данных, то есть появлению битых файлов.
Кстати, насчет энтропии: это одна из причин, почему космическое оборудование намного слабее того, которым мы пользуемся на Земле. Все дело в плотности микросхем, так как современное «железо» стремится к уменьшению техпроцесса, а чем плотнее компоненты, тем они более уязвимы к космическому излучению и солнечной радиации. Долгосрочное хранение информации на жестких дисках и SSD имеет аналогичные проблемы, поскольку электромагнитные излучения, перепады температур и влажности еще никто не отменял. Так как же правильно хранить важные файлы, как снизить риск их потери и как, собственно, умирают данные — с этим мы и намерены сегодня разобраться.
Деградация ячеек и размагничивание данных на диске
Сначала разберемся с размагничиванием пластин в жестких дисках, ведь там считывание информации зависит от трех главных параметров: точности позиционирования механизма считывающей головки, чувствительности головок и мощности магнитного поля болванок. В нормальных условиях, когда соблюдаются рекомендуемые производителем показатели влажности, температуры в помещении, а также отсутствуют механические удары и вибрация, сильные электромагнитные поля, деградация магнитного поля пластин составляет около 1% в год.
При этом сказать, что через условные 50 лет половина диска станет нечитаемой, будет неправильно. Обычно в таких случаях наличие битых файлов или вовсе их исчезновение будет связано не столько с ухудшением магнитной записи, сколько с деградацией материалов, отвечающих за точность позиционирования и чувствительность считывающих головок. Поэтому переживать за сохранность информации не стоит, поскольку неработающий должным образом такой жесткий диск всегда можно отнести к специалистам, которые без проблем считают и восстановят 100% данных напрямую с пластин. Это касается и вышедших из строя жестких дисков, в которых сломалась электроника, но «блины» не были повреждены механически ни считывающей головкой, ни наличием трещин и сколов. Единственный минус: стоимость услуг по восстановлению файлов может обойтись в копеечку.
Стоит ли так рисковать и оставлять на полке жесткий диск на 5−10−20 лет? На самом деле, нет. Несмотря на то, что многие могут похвастаться, что их жесткие диски успешно были считаны спустя 10−15 лет простоя на пыльной полке, есть много и негативных отзывов, когда после длительного хранения «харды» попросту отказывались раскручивать пластины. Связано это с тем, что жесткие диски предназначены для постоянной работы, поскольку в процессе своей жизнедеятельности они постоянно обновляют магнитный слой пластин и тем самым могут работать без сбоев десятки лет. Поэтому лучшим решением является постоянная перезапись данных с одного носителя на другой раз в год, если это действительно очень важные файлы.
Если планируется перезапись информации с одного «харда» на другой, то для этих целей лучше использовать проверенные временем устройства 3−5 летней давности (можно и больше) без наличия битых секторов! Жесткие диски, особенно современные модели, подвержены «детской смертности» — они до 40 раз имеют больше шансов выйти из строя в первые год-два эксплуатации, чем старшие собратья, отработавшие минимум 3 года.
Деградация ячеек на SSD
Большая часть современных SSD-накопителей используют метод ловушки заряда в ячейки памяти — CTF (Charge Trap Flash). Сами же ячейки на сегодняшний день в зависимости от стоимости твердотельного накопителя могут быть 4-х видов: SLC (хранение 1 бита информации), MLC (2 бита), TLC (3 бита) и QLC с хранением в ячейке 4 бит данных. В зависимости от количества хранимых бит в одной ячейке варьируется и емкость SSD — чем больше, тем лучше. Но у этого свойства есть и обратная сторона медали: чем выше количество бит в одной ячейке, тем больше уровней напряжения требуется для записи информации, а потому материал диэлектрика в ячейках памяти изнашивается быстрее. Важно уточнить, что деградация происходит только при записи данных, а при их считывании нагрузки на диэлектрик практически нет.
Значит ли это, что SSD можно единожды записать и хранить его долгие годы вне компьютера, а после удачно считать с него важную информацию? Можно, но ограниченное время. Например, компания DELL в документации к производимым твердотельным накопителям указывает, что ее SSD способны хранить информацию без подключения к питанию минимум 10 лет. При этом бренд отмечает, что если flash-память уже значительно изношена, то без питания данные могут храниться на накопителях до 3 месяцев для MLC и до 6 месяцев для SLC-ячеек.
Вечного архива не существует
Подводя итог о долгосрочном хранении данных на жестких дисках и SSD — ни первые, ни вторые не проектируются производителями для многолетнего архивирования информации. Для этих целей у компаний есть специальные оптические диски «архивного уровня», как например, DWD + RW или Blu-Ray диски, срок службы которых может достигать до 30 лет и даже больше. Что касается безмятежного и безопасного хранения данных на срок до 100 лет, то таких решений на сегодняшний день еще не найдено.
Стоит ли хранить данные в «облаке»?
Если отбросить устоявшиеся мифы о том, что данные пользователей, хранящиеся в «облаке» с легкостью могут украсть хакеры, или исчезнуть в результате стихийного бедствия, то облачные хранилища действительно надежны по состоянию на 2021 год. Крупные корпорации, которым принадлежат огромные сервера в разных странах, куда серьезнее относятся к безопасности и сохранности данных, нежели простые пользователи. Поэтому если и делать выбор между локальным хранением информации на HDD/SSD или предоставить эту услугу «облаку», то в плане надежности второй вариант предпочтительнее. К слову, он и удобнее, так как доступ к файлам будет всегда и везде — достаточно иметь под рукой смартфон и выход в Интернет. С другой стороны, такое удобство и безопасность в финансовом плане обойдется дороже.
Значит ли это, что данные в «облаке» никогда не исчезнут? Несмотря на то, что дата-центры имеют подстраховку в виде резервных копий, иногда и они безвозвратно теряют данные. Случается это крайне редко и теряется лишь малая часть информации, но факт остается фактом. Например, в 2015 году очень не повезло дата-центру компании Google, расположенному в Бельгии. В него 4 раза подряд ударил разряд молнии, и несмотря на все попытки восстановить все данные, безвозвратно было потеряно около 0,000001% информации. За последние 6 лет подобных происшествий больше не случалось несмотря на неоднократные неприятные инциденты, связанные с серверами (например, в марте 2021 года полностью сгорел страсбургский OVH SBG2, но ни один важный файл потерян не был).
Удалить с «облака» не так уж просто
Когда пользователь что-то удаляет с облачного хранилища, это не значит, что стертые файлы исчезают бесследно. Наглядным примером служит история, случившаяся в 2017 году, когда облачный сервис Dropbox из-за бага восстановил для части пользователей удаленные несколько лет назад данные.
Как умирают файлы на дисках
Что на жестких дисках, что на SSD информация умирает плюс-минус одинаково: обычно видеоролики «рассыпаются» на крупные пиксели различных цветов, разъезжаются на полосы или картинка застывает/видеозапись обрывается. Что касается фотографий, то они начинают демонстрировать артефакты (снова пиксели, полосы, часть картинки может быть залита одним или несколькими цветами), а музыкальные файлы начинают «булькать», издавать резкие звуки, обрываться на воспроизведении в любой момент. Прочие документы могут и вовсе не открываться.
При этом стоит понимать, что файлы сами по себе не могут деградировать. Если они открываются, то с вероятностью 99,9% они содержат ровно тот же код, что и при записи. Почему тогда они становятся «битыми»? Здесь проблема кроется в основном в некорректности считывания и последующей записи. Для HDD, как мы уже говорили, это потеря чувствительности и сбой позиционирования считывающих головок при полной сохранности данных на самих болванках. Для SSD ситуация сложнее, ведь там могут «барахлить» и контроллер памяти, и сама NAND-память. К слову, именно поэтому с SSD восстановить информацию сложнее, а порой и невозможно, в отличие от жестких дисков.
Как лучше хранить данные: локально или онлайн?
Какой вывод можно сделать насчет долгосрочного архивирования важной информации? Лучшим вариантом станет хранение файлов на жестких дисках, проверенных временем (3−5 лет без BAD-секторов) с периодической перезаписью данных раз в год на резервный HDD. При этом еще лучше иметь бэкап в «облаке», чтобы на 100% быть уверенным, что важные данные никогда и никуда не потеряются в течение как минимум нескольких десятков лет. Увы, но обойтись одним единственным решением сейчас невозможно, поскольку соответствующих технологий еще не разработано.