Потеря данных

Потеря данных — это ошибочная ситуация в информационных системах при которой информация уничтожается из-за сбоев (например, поломки шпиндельных двигателей или аварии головок жёстких дисков) или небрежности (например, неправильного обращения, неосторожного обращения или хранения в неподходящих условиях) при хранении, передаче или обработке. Информационные системы внедряют оборудование и процессы резервного копирования и аварийного восстановления для предотвращения потери данных или восстановления утраченных данных[1]. Потеря данных также может произойти, если физический носитель, содержащий данные, потерян или украден.

Потеря данных отличается от недоступности данных, которая может возникнуть из-за сбоя сети. Хотя оба явления имеют практически одинаковые последствия для пользователей, недоступность данных является временной, а потеря данных может быть необратимой. Потеря данных также отличается от утечки данных, инцидента, когда данные попадают в чужие руки, хотя термин «потеря данных» использовался и в таких инцидентах[2].

Типы

  • Процедурная
  • Намеренное действие
    • Преднамеренное удаление файла или программы
  • Непреднамеренное действие
    • Случайное удаление файла или программы
    • Неправильное размещение физического носителя
    • Ошибки администрирования
    • Невозможность читать неизвестный формат файла
  • Неисправность
    • Неисправность питания, что приводит к тому, что данные из энергозависимой памяти не сохраняются в постоянную память.
    • Неисправность оборудования, такая как авария головки жёсткого диска.
    • Падение или зависание программы, что приводит к тому, что данные не сохраняются в постоянную память.
    • Ошибки в программном обеспечении или плохая юзабилити, например, отсутствие подтверждения команды удаления файла.
    • Неудача бизнеса (банкротство поставщика), когда данные хранятся у поставщика программного обеспечения, использующего модель программное обеспечение как услуга и не предусмотрено escrow[3].
    • Повреждение данных, такие как повреждение файловой системы или повреждение базы данных.
  • Бедствие
  • Преступление

Исследования показывают, что аппаратные сбои и человеческий фактор являются двумя наиболее частыми причинами потери данных, на которые приходится примерно три четверти всех случаев[4]. Другой причиной потери данных являются стихийные бедствия, которые представляют собой больший риск в зависимости от местоположения оборудования. Хотя вероятность потери данных из-за стихийного бедствия невелика, единственный способ подготовиться к такому событию — хранить резервные копии данных в отдельном физическом месте. Таким образом, лучшие планы резервного копирования всегда включают хранение по крайней мере одной копии вне основного местоположения[5].

Даже если оборудование надёжно и работает как часы, от ошибок СУБД и прикладного ПО никто не застрахован, и они регулярно находятся и исправляются. А ещё есть человеческий фактор — действия пользователей и администраторов СУБД, которые тоже рано или поздно, но неизбежно ошибаются. Так что данные, которые вы храните в базе, рано или поздно будут испорчены или потеряны, это вопрос только времени, когда именно это событие произойдёт и в каком масштабе[6].

Цена

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

  • Затраты на продолжение работы без данных
  • Затраты на восстановление данных
  • Затраты на уведомление пользователей в случае компрометации

Предотвращение

Частота потери данных и её последствия могут быть значительно снижены благодаря принятию надлежащих мер предосторожности. Необходимые меры могут варьироваться в зависимости от типа потери данных. Например, несколько электрических цепей с источниками бесперебойного электропитания и генератор защищают только от сбоев электропитания, хотя использование источника бесперебойного питания может защитить накопитель от внезапных скачков напряжения. Аналогично, использование журналируемой файловой системы и RAID-массивов защищает только от определённых типов программных и аппаратных сбоев[7].

Для жёстких дисков, являющихся физическим носителем информации, минимизация вибраций и перемещений поможет защитить внутренние компоненты от повреждений, так же как и поддержание подходящей температуры накопителя[8].

Регулярное резервное копирование данных является важным инструментом при восстановлении после потери данных, но оно не предотвращает ошибки пользователя или сбои системы. Поэтому план резервного копирования данных должен быть разработан и выполняться совместно с планом аварийного восстановления для снижения рисков[9].

Логические повреждения могут быть никак не связаны с физическими, и наоборот, физические повреждения не всегда влекут за собой логические повреждения в данных. Но любые физические повреждения опасны, так как могут в любой момент привести к некорректной работе СУБД, что может привести к потере данных, причём не только уже повреждённых, но и затронуть любые другие данные или служебную информацию базы, а при неудачном стечении обстоятельств привести к полной потере данных. Следует всегда устранять физические повреждения данных при первых признаках их появления. После устранения физических повреждений всегда следует делать проверку в прикладной системе на логические повреждения[6].

Восстановление данных

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

Повреждения файловой системы часто могут быть устранены пользователем или системным администратором. Например, удаленный файл обычно не сразу перезаписывается на диске, а чаще просто удаляется его запись из индекса файловой системы. В таком случае удаление можно легко отменить.

Успешное восстановление данных после их потери обычно требует наличия эффективной стратегии резервного копирования. Без такой стратегии восстановление сводится к переустановке программ и повторному созданию данных. Даже при наличии эффективной стратегии резервного копирования, восстановление системы до точного состояния, в котором она находилась до потери данных, крайне затруднительно. Необходим компромисс между детализацией восстановления и его стоимостью. Кроме того, факт потери данных может быть обнаружен не сразу. Эффективная стратегия резервного копирования должна также учитывать стоимость поддержания возможности восстановления потерянных данных в течение длительного времени.

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

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

Первоначальные шаги при потере данных

В случае потери данных, успешное восстановление требует, чтобы удалённые данные не были перезаписаны. Поэтому следует избегать операций записи на затронутое устройство хранения. Это включает в себя отказ от запуска системы, к которой подключено повреждённое устройство, поскольку многие операционные системы создают временные файлы при загрузке, которые могут перезаписать области потерянных данных, делая их невосстановимыми. Просмотр веб-страниц имеет аналогичный эффект, потенциально перезаписывая потерянные файлы временными HTML-файлами и файлами изображений, создаваемыми при просмотре веб-страницы. Также следует избегать файловых операций, таких как копирование, редактирование или удаление.

При обнаружении потери данных часто лучше всего выключить компьютер и извлечь проблемный диск из устройства. Подключите этот диск к другому компьютеру с устройством блокировки записи и попытайтесь восстановить потерянные данные. Если возможно, создайте образ диска, чтобы получить вторичную копию данных. Эту копию можно использовать для тестирования и попыток восстановления, исключая риск повреждения исходных данных.

При обнаружении повреждения данных необходимо

  • Диагностика и анализ
    • восстановить картину инцидента (что случилось)
    • найти корневую причину (почему случилось)
    • найти все повреждения (что повредилось)
  • Восстановление данных
    • план восстановления
    • выполнение плана

Именно так — сперва диагностируем и анализируем, а только потом начинаем восстанавливать. До конца диагностики ничего не надо исправлять, иначе есть все шансы угробить данные окончательно. Увлёкшись починкой первой попавшейся ошибки, мы рискуем не заметить более важную проблему. Также из-за преждевременных действий мы можем потерять информацию, которая помогла бы нам восстановить картину инцидента, и установить корневую причину. А то и просто можем потерять все данные, если попытаемся внести изменения в повреждённые структуры базы[6].

См. также

  • Несанкционированный доступ к данным = Утечка данных
  • Усечение данных

Примечания

  1. Constantine, 2008.
  2. Data Spill Management Guide. asd.gov.au (24 декабря 2014). — «A data spill is sometimes referred to as unintentional information disclosure or a data leak.» Дата обращения: 23 января 2015. Архивировано из оригинала 23 января 2015 года.
  3. Что такое escrow можно прочитать в статье
    bkonst. Пользуемся escrow, чтобы не было мучительно больно (14 июня 2008). Дата обращения: 11 ноября 2025.
  4. The cost of lost data - Graziadio Business Report
  5. Leopando, Jonathan. World Backup Day: The 3-2-1 Rule. TrendLabs Security Intelligence Blog. Trend Micro (2 апреля 2013). Дата обращения: 29 апреля 2015.
  6. 1 2 3 Бредня, Евгений. Восстановление повреждённых данных в PostgreSQL. Хабр. Дата обращения: 11 ноября 2025.
  7. Preventing data loss in a perilous digital age. TechRadar (англ.). Дата обращения: 26 октября 2018.
  8. Connor, Chris. Data Loss Prevention: 10 Tips to Prevent Hard Drive Failure. Data Storage Digest (2 ноября 2013). Дата обращения: 29 апреля 2015. Архивировано из оригинала 20 сентября 2023 года.
  9. Leonard, Prisley. Backup Software, Professional Backup Solution can prevent data loss. minitool.com (14 июня 2017). Дата обращения: 25 октября 2018.

Литература

  • Photopoulos Constantine. Managing catastrophic loss of sensitive data : a guide for IT and security professionals. — Rockland, Mass.: Syngress, 2008. — ISBN 9781597492393. — OCLC 228148168.