От факапа до бэкапа: истории ИТ-компаний, потерявших данные


     
    Большинство компаний понимают важность создания бэкапов. Но вот беда — представление о том, что должна собой представлять стратегия резервирования данных, имеет не так много компаний. В результате они теряют информацию, клиентов, а значит, и деньги. Еще в 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
    38.50
    Company
    Share post

    Comments 20

      0
      Всё это от большого ума и отношения.
      В нашей конторке бэкапы делаются каждый день уже 5 лет.
      Понадобилось толлько 2 раза, да и н для восстановления, а для просмотра истории изменений.
      Если сделано с умом — бэкапы и не нужны.
        +2
        Если сделано с умом… А делают с умом, зачастую, только после того как «обожглись». Поэтому все-таки нужны.
          +1
          Не я заранее сделал. Пэтому ожогов нет.
            +3
            Бэкапы для слабаков!
              +1
              И тормоза!
                +1
                И фары!
                Да, да, тормоза и фары придумали трусы!
            0

            Одно дело забекапить конторку, другое дело — забекапить 500 петабайт. В конторках как раз часто всё сделано по уму и с 5кратной надёжностью — если админ журналы читает. Когда у меня объём сберегаемых данных перевалил за 6Тб, бюджет сказал "нужно больше золота", и пришлось тоже ухудшать качество бекапов.

              0
              Это есть такая проблема. Но изворотливость ума никуда не делась. Года 4 назад надо было в одном видео проекте 3 дня бэкапы хранить — сделал из домашних компьютеров VPN и RSync пузырил c 2-мя дубликатами. Один раз пришлось восстанавливать — не быстро, но ролики клоунов из театра Дуровой (это реальные люди http://teatrium.ru/theater/creative-team/troup) не потерялись. Так что всё зависит от прослойки между клавиатурой и стулом.
                0
                Ох… 6Тб — это еще немного. Вот когда только продуктив который надо бэкапить с частотой 15 минут, выходит за 35-40Тб, вот тогда и начинается самое интересное.
              +1
              Свежее: поломалася новый HP 3Par у налоговой в Австралии.
              Корраптнутые данные успели залиться в реплику.
              Регулярные снепшоты массива видимо настроить «не успели еще пока». Или «места жалко», ведь есть реплика и ленты =)))
              Результат — потеря 1PB.
              http://www.itnews.com.au/news/hpe-storage-crash-killed-ato-online-services-444490
              http://www.storagenewsletter.com/rubriques/systems-raid-nas-san/failure-of-hpe-3par-storeserve-san-2/
                +4
                К примеру, один из крупнейших в мире банков, Barclays, был пару лет назад оштрафован на несколько миллионов долларов США. Причина — частичная утеря деловой переписки за 10 (!) лет. Компания потеряла данные из-за несовершенства системы хранения данных. Технический сбой – и письма утеряны.

                Не самый удачный пример, там данные, с высокой вероятностью, потерялись не из-за плохого бэкапа, а из-за того, что штраф за то, что было в переписке, оказался бы выше штрафа за ее утрату.
                  0
                  В 2007 написал свою программу dirsync — легкая и простая (ну и для меня удобная — сам написал). Бэкаплю критичные данные раз в сутки, некритичные — 2 раза в неделю. Неоднократно восстанавливался. Не понимаю, как без бэкапов можно жить. Тем более на продакшене.
                    0
                    С месяц тому с классического rsync бекапа перешел на borg — пока только положительные впечатления.
                    + верфикация архивов
                    + дедубликация
                      0
                      спасибо, очень интересное решение, с которым я впервые познакомился!
                      0
                      Всё-таки «утечка данных» и «потеря данных» — кейсы совершенно разные, местами даже взаимоисключающие, (примерно как пожарники и охрана в вопросе решёток и дверей).
                        0
                        Очень распространён факап, когда спустя пару лет после настройки и отладки бэкапа после падения системы выясняется что уже 2 года как в бэкапы льётся бессмысленная чушь. Попадал лично и видел у коллег.
                          +2
                          Админы делятся на
                          1. Тех кто еще не делает бэкапы
                          2. Тех кто УЖЕ делает бэкапы
                          3. Тех кто УЖЕ проверяет бэкапы на валидность

                          Вот только у третьего пункта можно говорить, что бэкапы существуют.
                          Я так недавно принимал нового клиента. Полез проверять бэкапы настроенные прежними аутсорсерами, а там не бэкапы, а полная белибердень нечитаемая. Попросил информацию когда последний раз бэкапы проверялись, получил от прежнего аутсорсера ответ: «Никогда, нам не нужно проверять бэкапы настроенные сотрудниками, они у нас идеальны».
                            0
                            «3. Тех кто УЖЕ проверяет бэкапы на валидность», — не знал, что без этого можно жить. Кто же эти админы, которые не проверяют бэкапы? У Oracle, например, есть стандартные средства rman-ские для проверки резервных копий после выполнения бэкапа. Всегда логи их выполнения анализирую.
                              0
                              Ну я выше привел пример из буквально недавнего своего опыта. Достаточно крупная российская фирма берущая на аутсорс чужие сервера не проверяла вообще настроенные бэкапы, а на вопрос о проверке заявила, что им в этом нет необходимости, потому что у них все всегда идеально.
                              При этом косяк там был прекрасный, они не проверяли реальное место на подмонтированной для сохранения бэкапа внешней точке даваемой хостером, хостер дает 100 гигов, но при монтировании в системе оно видится, как 1 террабайт, фигачили на это место при помощи dd lvmный снапшот, а потом уже делали gzip, что бы его пожать. В результате они на реальные 100 гигов якобы записывали 320 гигов, а потом жали то, что системе казалось файлом. Я этот прикол с местом выдаваемым Хецнером под бэкап очень хорошо знаю, что ты можешь писать туда свыше своих 100 гигов, эти данные уходят в космос, хотя система у тебя считает, что она туда что-то записала.

                              Ну вот как-то так.
                          0
                          Коллеги, раз тут собрались обсуждать бекапы — задам вопрос немного не в тему поста: где можно почитать про аналитику резервного копирования? Какими отчетами пользуются в отрасли, какие зависимости отслеживают. Есть такое что-то?

                          Only users with full accounts can post comments. Log in, please.