Большинство компаний понимают важность создания бэкапов. Но вот беда — представление о том, что должна собой представлять стратегия резервирования данных, имеет не так много компаний. В результате они теряют информацию, клиентов, а значит, и деньги. Еще в 2014 году эксперты информировали о том, что бизнес теряет около $1.7 триллиона долларов в год из-за безвозвратных потерь ценнейших данных, которые почему-то не резервировались. Сейчас этот показатель вырос, поскольку часовой вынужденный простой дата-центра обходится оператору в $50 000 — $80 000. Два года назад часовой простой влек за собой убытки в $40 000 — $60 000.
Каждый год эта сумма растет, поскольку ценность данных постепенно увеличивается. Да и не только в информации дело — ведь и обычный простой оборудования из-за разного рода проблем больно бьет по кошельку как самой компании, которой принадлежит инфраструктура, так и ее клиентов.
Только в первом полугодии 2016 года было утеряно или похищено в результате осуществления кибератак злоумышленниками 554 миллиона записей. Наиболее распространенная цель взлома — похищение личных данных пользователей. В США наиболее атакуемой сферой оказалось здравоохранение. При этом правительственные органы в первом полугодии 2016 года потеряли максимальное количество данных (речь идет об утерянных или похищенных данных).
При этом за весь 2015 год было утеряно или похищено в результате осуществления кибератак 707,5 миллионов записей. Это, правда, меньше, чем в 2014 году, когда аналогичный показатель составил 1,02 млрд записей.
Среди причин утери данных — неподготовленность компаний к критическим событиям (сбои в подаче электроэнергии, физический ущерб оборудованию, взлом и кража данных, природные катаклизмы). Если не позаботиться о резервных копиях заранее — потом будет мучительно больно, об этом слышали многие. Но, как говорится, «мыши плакали, кололись, но продолжали есть кактус». Давайте посмотрим, какие бывают неожиданные случаи, которые внезапно приводили к частичной или полной остановке работы телекоммуникационных компаний и их подразделений. Здесь не везде речь идет о потере данных и резервном копировании, но эти ситуации заставляют задуматься над тем, насколько быстро хорошо отлаженный процесс/работа компании может превратиться в хаос. Несмотря на планирование, неожиданные ситуации могут возникать, и обязательно возникнут, рано или поздно.
Невесёлая история игрушек
Одна из самых нашумевших ранее историй — это утеря сотрудниками Pixar большого массива данных по ToyStory 2. Тогда кто-то из сотрудников случайно стер с сервера БД с сотнями важных элементов анимации персонажей, исходников самих персонажей и т.п. После того как компания решила восстановить данные из бэкапа, оказалось, что резервное копирование не работало уже более месяца.
Возникла угроза того, что целый месяц работы (а то и больше) ушел в никуда. Но затем оказалось, что один из руководителей проекта регулярно отправлял все данные на свой домашний ПК, с тем, чтобы иметь возможность работать над проектом и дома. Только благодаря этому (причем, надо заметить, это было нарушением корпоративных правил) данные удалось восстановить.
Если бы данных не оказалось на домашнем сервере, то сроки реализации проекта могли затянуться, и компания оказалась бы в очень неприятной ситуации.
ДТП с участием дата-центра
Если говорить о внезапных событиях, которые приводили к потерям и убыткам данных, то здесь нельзя не вспомнить случай из 2007 года. Тогда компания Rackspace (которая не была еще такой авторитетной, как годы спустя) столкнулась с неожиданностью. В ее дата-центр врезался внедорожник. Водитель этого автомобиля страдал диабетом. Во время поездки он потерял сознание, нога нажала на педаль газа, и машина, вылетев за пределы дорожного полотна, на всей скорости врезалась в объект, в котором располагался центр энергетической инфраструктуры дата-центра компании.
Сразу заработала вспомогательная система энергоснабжения, но возникла проблема — не запустилась основная система охлаждения. Из-за этого оборудование быстро перегрелось, так что сотрудники компании приняли решение выключить все, чтобы сервера и другое оборудование не вышли из строя.
В итоге дата-центр простоял без дела около пяти часов, в течение которого ничего не работало. Эти пять часов обошлись компании в $3,5 млн. Немало.
… и ещё несколько печальных ИТ-историй
Сбой в системе сложно предсказать, что логично. Случаются сбои даже в самых надежных системах, где задействована мощная инфраструктура. Но вот частоту сбоев можно снизить, и значительно, использовав резервирование систем. В надежной инфраструктуре избыточной может (и должна, по идее) быть любая ее часть, включая питание, охлаждение и т.п. Высококачественные дата-центры используют схемы N+1 и N+2 для обеспечения высокой системы надежности. Требования к надежности инфраструктуры дата-центров растут, поскольку растет и цена вынужденного простоя. Тем не менее, проблемы все еще случаются.
Например, в том же 2013 году перестал работать один из крупнейших хостинг-провайдеров мира. В дата-центре компании, расположенном в штате Юта, США, возникли проблемы в результате аппаратного сбоя при проведении профилактических работ на сервере. И это повлекло за собой ряд отключений оборудования по всему дата-центру. В результате огромное количество веб-сервисов и сайтов на время прекратили функционировать. Этот сбой обошелся в немалую сумму.
А сразу после выхода на рынок игровой консоли Xbox One возросла (и очень значительно) нагрузка на сервера компании. Из-за этого начал сбоить и облачный сервис Windows Azure. В течение целого дня наблюдались проблемы с работой Xbox Live — данные иногда не сохранялись, иногда не загружались, мультиплеер в играх не работал.
В 2015 году пострадала известнейшая компания Vtech, которая производит игрушки и электронные устройства для детей. Тогда кто-то взломал сервера компании, и 4,8 млн записей из базы данных клиентов были похищены. Кроме того, были похищены и данные о 200 000 детей (их имена указывались родителями при регистрации).
Как оказалось, компания не слишком тщательно следовала принципам информационной безопасности. Слабые пароли, слабое шифрование, малое количество бэкапов — все это привело к большим проблемам. Vtech в какой-то степени потеряла доверие клиентов и инвесторов, недовольных халатностью сотрудников.
Уже в этом году стало известно о еще одном случае безответственной работы. В утере данных виновным оказался руководитель небольшой хостинг-компании, которая обслуживала около 1500 клиентов. Марко Марсала (Marco Marsala) в один из загруженных работой вечеров запустил команду rm -rf {foo}/{bar} на всех серверах, причем переменные {foo}/{bar} заданы не были (по ошибке). В итоге удалились все данные со всех серверов.
По неудачному стечению обстоятельств, к серверам были подмонтированы накопители с бэкапами. Все эти данные тоже были стерты. Пострадавший владелец компании спросил у других пользователей, можно ли после запуска команды rm -rf {foo}/{bar} восстановить информацию. Понятно, что ничего хорошего другие пользователи ему не сообщили. В итоге невнимательность привела к тому, что бизнес пришлось закрыть (об этом сообщил все тот же Марсала). Так что делать бэкапы мало, их еще нужно и хранить в надежном месте. В комментариях пользователи указали, что «Если у вас только один бэкап — у вас нет бэкапа», что, собственно, является правдой в большинстве случаев.
И проблемы бывают не только у небольших компаний. К примеру, один из крупнейших в мире банков, Barclays, был пару лет назад оштрафован на несколько миллионов долларов США. Причина — частичная утеря деловой переписки за 10 (!) лет. Компания потеряла данные из-за несовершенства системы хранения данных. Технический сбой – и письма утеряны.
И ладно бы, если бы только банки теряли письма — ведь финансовые компании, хотя и должны иметь совершенную телекоммуникационную инфраструктуру, не являются все же создателями сервисов электронной почты, как, например, Google. Да-да, эта компания тоже далеко не идеальна в плане хранения информации пользователей. В 2011 году Gmail, почтовый сервис от Google, заставил поволноваться тысячи своих пользователей.
Некоторые из них, зайдя в свой аккаунт, не увидели ни писем, ни контактов. Тогда было затронуто, по словам Google, «всего 0,08%» от общего числа пользователей сервиса. Но на тот момент Gmail-ом пользовались 193 миллиона человек, и даже сотые доли процента от этого числа — это население небольшого города. Один из клиентов сервиса тогда жаловался на утерю 17 000 писем — это была вся его деятельность за все время.
Большинство данных компании удалось вернуть, поскольку у Google резервирование данных поставлено во главе угла всей работы компании. Но часть пользователей все же осталась с проблемными аккаунтами, плюс пострадала репутация Gmail.
Причины утери данных и бэкапов в компаниях
Среди наиболее частых причин, которые приводят к потере данных и резервных копий данных, мы выделяем пять основных моментов. Это отказ носителя, человеческий фактор, программная ошибка, аппаратная ошибка и проблемы с сетевым оборудованием.
Отказ носителя
Это одна из наиболее распространенных причин утери данных. Чаще всего эта проблема происходит в том случае, если не ведется наблюдение носителей, а также нерегулярно осуществляется проверка состояния такого оборудования. Невыполнение инструкций производителя, неаккуратное обращение с носителями — все это может стать причиной сбоя.
Человеческий фактор
Это вторая по распространенности причина сбоя систем резервирования данных, в результате чего информация либо вообще не бэкапится, либо стираются сами бэкапы. Для того, чтобы избежать подобных проблем, штат сотрудников должен быть квалифицированным, нужны четкие инструкции и планы, которые должны выполняться.
Программный сбой
Это тоже одна из наиболее распространенных проблем. Обновление ПО, замена одной программы другой, добавление программного модуля в систему бэкапа — причин сбоя множество. И чем сложнее такая система, тем выше вероятность сбоя.
Аппаратный сбой
Аналогично предыдущей проблеме, оборудование может отказать при замене какого-то аппаратного модуля, по причине физического устаревания аппаратных систем или же без всякой видимой причины.
Отказ сети
Неверно сформированный скрипт, отказ сетевого оборудования, какие-то проблемы с совместимостью протоколов или десятки других причин могут повлиять на ход резервного копирования данных.
Частные лица ничем не лучше компаний (а может, даже и хуже) в отношении создания резервных копий данных. Еще в 2015 году компания Backblaze провела опрос пользователей, в ходе которого обнаружилось, что даже ежегодно полностью копируют свои данные лишь 39% пользователей. Каждый день это делает только 8% респондентов.
В качестве вывода
Собственная телекоммуникационная инфраструктура компании — это сложно, дорого и долго. Конечно, бывают случаи, когда без своего ЦОДа просто не обойтись. Но в подавляющем большинстве случаев компании проще воспользоваться уже готовой инфраструктурой, включая системы резервного копирования, чем разворачивать собственную систему.
В любом случае, для каких бы целей вам не понадобились значительные вычислительные мощности, у нас есть услуга "Виртуального ЦОДа". Инфраструктура как сервис (IaaS) — не новое направление, однако мы выгодно отличаемся целостным подходом, начиная от специфически ИТ-шных проблем, вроде переноса корпоративных ресурсов в «Виртуальный ЦОД», до юридических, таких как консультация по актуальному законодательству РФ в сфере защиты данных (VDC.152).
Один из положительных моментов — отсутствие необходимости у компании, использующей IaaS, необходимости развивать и расширять собственную телекоммуникационную структуру. Все это делает оператор сервиса. И да, глубина хранения бэкапа (а они создаются каждый день) составляет 14 дней. В большинстве случаев этого достаточно для восстановления любых данных, потерянных в ходе каких-либо сбоев. Вы можете не делать бэкап — его сделаем мы, компания Safedata. На всякий случай заметим, что резервное копирование — платная услуга, ее нужно подключать.
Что же, успешных всем бэкапов, товарищи читатели.
Автор: SAFEDATA
