В комментариях к моему недавнему посту про положение Банка России №397-П , касающееся требований к сохранности данных, кто-то сказал, что, дескать, ничего нового – бэкапы и так все делают, так что и говорить вроде как не о чем. “Ага,- подумал я. -Конечно”. Но спорить не стал. А недавно подвернулся под руку отчет компании Kroll Ontrack , специализирующейся на восстановлении данных. Т.е. то самое место, куда приходят с последней надеждой восстановить погибшие данные.
К сожалению, в отчете не приводится демографических данных респондентов, но я склонен предположить, что большая часть приходится на частных пользователей и SMB. Впрочем, на моей памяти услугами Ontrack в России пользовался достаточно крупный enterprise-клиент. Все, что мы знаем про предоставленную статистику, это то, что в 1/3 случаев речь шла про потерю личных данных, а в 2/3 – служебных. В любом случае, отчет заслуживает внимания.
Тезис №1, основной. 60% респондентов, столкнувшихся с потерей своих данных, имели решения по резервному копированию. Но их резервные копии были или безнадежно устаревшими, или неполными. Это – тема для рефлексии всем, кто считает, что у них эффективно работает решение по резервному копированию.
В качестве носителей для резервных копий 60% используют внешние диски, 15% – ленту, и только 15% – облачные сервисы. Здесь видим заметное пространство для роста провайдерам облачных сервисов резервного копирования.
Вполне закономерен перечень проблем, приводящих к тому, что решения по резервному копированию не оправдывают ожиданий своих хозяев. Здесь есть как моменты, применимые только к резервному копированию данных с рабочих станций, так и абсолютно универсальные “грабли”.
- Внешний диск подключается эпизодически, резервное копирование не автоматизировано, а выполняется вручную;
- В момент резервного копирования по расписанию компьютер выключен, и настройки не предусматривают резервного копирования в другое время;
- Сбой ПО резервного копирования;
- Нехватка пространства на резервных носителях;
- Профиль резервного копирования включает в себя неполный набор данных;
- Потеря данных, изменившихся с момента последнего планового резервного копирования.
Итак, имеем достаточно наглядное подтверждение того, что просто “организовать” резервное копирование недостаточно – необходимо понимать, где находятся ваши данные, каковы ваши требования по частоте резервного копирования (RPO), доступен ли в момент копирования носитель, на который делается копия (и, кстати, не погибнет ли он вместе с исходными данными в случае чего), и т.п. Не побоюсь показаться занудным, но классификация данных и регламент резервного копирования и восстановления данных – небольшая цена за то, чтобы вы могли быть спокойны за сохранность своих данных.
