Различия

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

Ссылка на это сравнение

articles:backup-economy [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== backup-economy ======
 +<​sub>​{{backup-economy.odt|Original file}}</​sub>​
 +
 +====== экономика резервирования данных ======
 +
 +крис касперски,​ no-emal
 +
 +**подходы к резервированную данных довольно различны:​ на одних предприятиях существует жестко выработанная политика,​ которой все сотрудники должны следовать неукоснительно,​ на других же резервирование осуществляется стихийно — в случайное время, случайными людьми,​ на первый же попавшийся носитель. многие авторы,​ углубясь в техническую сторону проблемы,​ совершенно забывают об ****[****про****] ****экономическую составляющую,​ и в некоторых случаях затраты на _плановое_ резервирование превышают _возможные_ (и, зачастую,​ маловероятные) убытки от потери данных!**
 +
 +===== введение =====
 +
 +Необходимость резервирования данных обычно осознается лишь при их полной или частичной потери. Лихорадочные попытки восстановления крупиц информации (и внушительные суммы, выплаченные специалистам по восстановлению) "​открывают глаза"​ и способствуют принятию целого комплекса мер, направленных на защиту данных,​ но увы… резервирование намного более сложная штука, чем это кажется поначалу. Начнем с того, что ручное резервирование требует времени (которое,​ как известно,​ — деньги),​ а автоматическое — приобретения дополнительных программно-аппаратных средств и, естественно,​ носителей информации. Дешевым носителям свойство "​умирать"​ сразу же после записи данных (ходят слухи, что китайцы уже наладили выпуск специальных моделей CD/DVD-R дисков — Write-Only). Дорогие носители окупают себя только при выборочном резервировании,​ когда сохраняются только самые ценные данные,​ но даже в этом случае,​ требуются солидные вложения и нет никакой гарантии,​ что восстановление данных пройдет как "​задумано"​.
 +
 +Занимаясь восстановлением данных,​ автор этой статьинаслышался достаточно историй,​ как "​еще вчера все работало и вдруг — бах! Резервной копии нет: она "​посыпалась"​ или она безнадежно устарела"​. Вот и выходит,​ что люди ухлопали кучу денег, средств,​ времени на резервирование и в конечном счете все равно были вынуждены обращаться к специалисту по восстановлению. Почему?​ Давайте,​ попробуем разобраться!
 +
 +===== >>>​ врезка основные причины потери данных =====
 +
 +Различные компании приводят различную статистику причин потери данных,​ но в целом, отказы жестких дисков занимают порядка ~13% и порядка ~50% приходится на отказы операционной системы. Доля вирусов колеблется от 2% до 22% процентов. Ничего себе разрывчик в оценках,​ больше чем на порядок! Просто потрясающая точность,​ вызывающая сомнения в ее достоверности и рождающая вопрос — а можно ли ей вообще доверять?​!
 +
 +Ответ отрицательный. Даже если статистика взята не с потолка и отсутствует какая бы то ни было подтасовка фактов или фальсификация данных,​ результат замыкается сам на себя и в общем случае не имеет никакого смысла.
 +
 +Рассмотрим фирму, занимающуюся восстановлением данных и обсуживающую крупные компании,​ администраторы которых с мелкими разрушениями файловой системы справляются самостоятельно и обращаются за помощью только в случае серьезных аппаратных отказов. Естественно,​ в статистике,​ собранной данной фирмой,​ аппаратные отказы будут доминировать над всеми остальными видами потери данных. А вот если фирма обслуживает SOHO-сектор,​ не способный даже поднять упавшую систему,​ аппаратные отказы отойдут на самый последний план, занимая доли процента,​ вытесненные ошибками оператора.
 +
 +Хорошо,​ пойдем другим путем — путем сбора опросов. Как часто вы теряете данные и от чего? Кажется,​ железной объективности тут не избежать,​ но… весь фокус в том, что при смене технологии производства жестких дисков (переход на гидродинамические подшипники или перпендикулярную запись),​ процент отказов резко возрастает и зачастую все винчестеры,​ выпущенные фирмой,​ умирают в течении нескольких лет. Подобных "​проколов"​ в техпроцессе не сумел избежать ни один производитель,​ ни IBM, ни Maxtor, ни Quantum, ни другой брэнд. Следовательно,​ статистика сбоев HDD, очень сильно зависит от момента времени,​ в течении которых она собиралась.
 +
 +Ниже приводится ряд диаграмм,​ составленных различными фирмами. Решайте сами, кому (не)доверять.
 +
 +
 +
 +{{backup-economy_Image_0.png?​514}}
 +
 +Рисунок 1 статистика потерь данных по данным компании Ontrack (http://​www.ontrack.co.uk)
 +
 +{{backup-economy_Image_1.png?​532}}
 +
 +Рисунок 2 статистика потерь данных по данным компании NewGen (http://​www.newgen.ca/​content/​causes_of_data_loss.taf)
 +
 +{{backup-economy_Image_2.png?​466}}
 +
 +Рисунок 3 статистика потерь данных по данным компании asm-development
 +
 +{{backup-economy_Image_3.png?​553}}
 +
 +Рисунок 4 статистика потерь данных по данным компании Databarracks (http://​www.databarracks.com/​arxcis/​images/​data-loss-pie-chart.gif)
 +
 +{{backup-economy_Image_4.png?​392}}
 +
 +Рисунок 5 статистика потерь данных по данным компании HP (http://​h41111.www4.hp.com/​ubp/​img/​pie_chart.gif)
 +
 +{{backup-economy_Image_5.png?​553}}
 +
 +Рисунок 6 статистика потерь данных по данным компании Meetingready (http://​www.meetingready.com/​images/​causesofdataloss_000.gif)
 +
 +===== RAID или не RAID =====
 +
 +Тех, кто верит в магическую силу аббревиатуры RAID, поспешу разочаровать:​ для резервирования данных RAID'​ы не предназначены. RAID уровня 0 увеличивает производительность дискового ввода/​вывода,​ а RAID'​ы более высоких уровней страхуют от выхода жесткого диска из строя, в большинстве случаев позволяя менять его на лету без остановки сервера,​ что очень удобно.
 +
 +Жесткие диски — довольно надежные устройства и если только нам не попадется дефектная модель,​ с грубыми конструктивными недоработками или технологическими нарушениями,​ риск потери данных по причине выхода винчестера из строя достаточно не велик и приблизительно составляет ~13% от всех остальных причин разрушений данных,​ причем,​ существует множество фирм, занимающихся аппаратным восстановлением жестких дисков и в подавляющем большинстве случаев,​ данные все-таки удается спасти. Одной из такой фирмой является знаменитая ACE-LAB (бывшее КБ), разработавшая свой собственный аппаратно-программный комплекс PC-3000, использующийся во всем мире!
 +
 +===== >>>​ врезка основные свойства RAID'​ов =====
 +
 +  - наличие RAID-массива еще не отменяет необходимости резервирования данных;​
 +  - RAID-массив экономически оправдывает себя только на серверах (рабочих станциях),​ работающих в "​орбитальном"​ режиме,​ то есть без остановки;​
 +  - дешевые RAID-контроллеры содержат много ошибок и зачастую сами становятся причиной потери данных;​
 +  - восстанавливать информацию с RAID'​а намного сложнее,​ чем с обычного диска и, соответственно,​ намного дороже;​
 +===== хранилища:​ централизованные и распределенные =====
 +
 +Некоторые администраторы предпочитают хранить все данные на серверах,​ чтобы их было удобнее резервировать. Однако,​ древняя поговорка гласит:​ не клади все яйца в одну корзину и это справедливо не только для яиц (кстати,​ китайцы говорили:​ прежде,​ чем класть яйца в корзину,​ убедись в том, что ты построил действительно надежную корзину),​ но и для серверов.
 +
 +Данные,​ сосредоточенные в одном месте, легко резервировать,​ но легко и… атаковать. Сумеете ли вы обеспечить надежную защиту сервера?​! А как на счет выхода из строя процессора,​ материнской платы или другого компонента?​ Сколько времени уйдет на ремонт (особенно,​ если смена оборудования потребует переустановки операционной системы),​ в течении которого _все_ сотрудники фирмы будут вынуждены курить или раскладывать пасьянс,​ поскольку необходимые им данные недоступны. Так же следует учесть пропускную способность локальных сетей и мощность самого сервера,​ которые далеко не безграничны и при одновременном обращении ко многим файлам все начнет жутко тормозить. Одно дело — когда пользователи лениво работают в Word/Excel, периодически сохраняясь,​ и совсем другое — если несколько из них запустят поиск документов по содержимому,​ вынуждая сервер открывать все файлы один за другим,​ со всеми вытекающими отсюда последствиями…
 +
 +Централизованное хранение данных на сервере требует:​
 +
 +  - достаточно мощного сервера,​ рассчитанного на пиковую загрузку;​
 +  - наличия резервного "​зеркального"​ сервера,​ на случай выхода из строя основного;​
 +  - мощной защиты,​ способной предотвратить вторжение хакеров как извне, так и изнутри;​
 +Другими словами,​ централизованное хранение экономически выгодно только в крупных организациях,​ имеющих по меньшей мере несколько сотен компьютером. В противном случае,​ лучше резервироваться на местах.
 +
 +Ох… а вот с резервированием на местах имеются большие проблемы. Причем,​ не технические,​ а организационные. Пользователи – они же такие непослушные,​ можно даже сказать невменяемые. Хранение документов в Корзине — обычное дело и только наивный может надеяться,​ что путем инструктажа ситуацию можно исправить.Намного проще предоставить это дело автоматике. Подойдет любая программа резервирования,​ даже Microsoft Backup, входящая в штатный комплект поставки Windows NT/​2000/​XP и оснащенная встроенным планировщиком. Остается только выбрать перспективный (как в техническом,​ так и в экономическом смысле) носитель информации.
 +
 +===== носители данных XXI века =====
 +
 +Вот основные (можно даже сказать фундаментальные) свойства носителей,​ определяющие их отбор:
 +
 +  - удельная стоимость одного гигабайта информации;​
 +  - надежность (число циклов чтения/​записи,​ устойчивость к физическим воздействиям);​
 +  - производительность (скорость чтения/​записи,​ возможность произвольного доступа);​
 +  - объем одного носителя;​
 +Если с удельной стоимостью,​ надежностью и производительностью никаких вопросов не возникает,​ то последний пункт встречает резкое непонимание,​ граничащее с критикой. Но вот попробуйте зарезервировать 750 ГБ жесткий диск на 700 МБ CD-R/RW диски и вы все сразу поймете. Вопрос даже не в том "​сколько это будет стоить",​ а "​где разместить _такое_ количество дисков"​ и "​как не запутаться в этом хозяйстве"?​ Причем,​ чем больше носителей мы используем,​ тем выше вероятность того, что один из них окажется бракованным и… тогда все оставшиеся окажутся бесполезным,​ особенно если резервирование осуществляется не на файловом,​ а не секторном уровне и в дефектный носитель попали сектора,​ хранящие критические структуры файловой системы.
 +
 +У DVD-R/RW дисков надежность та же самая (вопреки распространенным слухам),​ а вот с удельной стоимостью и объемом дела обстоят намного лучше, но… к сожалению,​ зарезервировать данные в автоматическом режиме не удастся и нам потребуется оператор,​ вынимающий из привода одни диски и вставляющий другие. А так же "​библиотекарь",​ отвечающий за сохранность архива и прилагающий максимум усилий,​ чтобы не возникало путаницы между копиями разной степени свежести.
 +
 +Стримеры обладают сопоставимой с жесткими дисками емкостью и высочайшей надежностью,​ но при этом безнадежно отстают в скорости и резервирование занимает слишком много времени и, так же как и в случае с CD/​DVD-R/​RW,​не поддается полной автоматизации,​ требуя человека,​ меняющего ленты. Другой существенный недостаток стримеров — проблемы с произвольным доступом.
 +
 +Внешние жесткие диски с Ethernet-портом (фактически,​ представляющие собой файловые сервера в миниатюре) — самые перспективные кандидаты на роль носителей для резервирования. Просто устанавливаем их в стойку,​ подключаем к хабу и заставляем резервирующую программу с заданной периодичностью резервировать данные по сети, складывая их в кольцевой буфер, без отрыва сотрудников от производства.
 +
 +Зачем нужен кольцевой буфер?​! А вот зачем — дело в том, что факт разрушения данных часто обнаруживается не сразу, а лишь спустя некоторое время. Если мы будем иметь только одну резервную копию, то в ней окажутся записаны разрушенные данные,​ что не есть хорошо (можно даже сказать,​ что это катастрофа!).
 +
 +Другой немаловажный момент — резервируясь на секторном уровне,​ мы теряем возможность вытащить из архива какой-то конкретный файл (ошибочно удаленный с рабочего компьютера оператором или погрызенный вирусом). Внешние жесткие диски представляют собой великолепное хранилище данных,​ снижающее накладные расходы на резервирование в несколько раз и позволяющее полностью автоматизировать процесс.
 +
 +Правда,​ здесь есть одно "​но"​. Коль скоро резервные данные доступы по сети, они могут быть уничтожены хакером,​ вирусом или зловредным работником. Следовательно,​ от стримеров (CD/​DVD-R/​RW) никуда не уйти и хотя бы раз в месяц (а лучше еженедельно) выполнять полное ручное резервирование всех данных.
 +
 +Кстати,​ вы уже обратили внимание,​ что в статистике причин потери данных фигурируют стихийные бедствия?​ А еще существуют такие неприятные явления как прорывы труб отопления,​ пожары и т. д. Резервная копия, хранящаяся _рядом_ с основным компьютером во всех этих случаях абсолютно бесполезна и действительно ценные данные рекомендуется сохранять на стримере и раз в месяц (год, неделю) сдавать ленту на хранение в банк. Более дорогой (но и значительно более надежный вариант) — завести себе аккаунт где-нибудь на другом конце земного шара (желательно в сейсмически неактивном районе),​ и передавать данные по Интернету.
 +
 +===== заключение =====
 +
 +Обсудив возможные методы резервирования (и сопутствующие им проблемы) остается только сопоставить стоимость резервирования со стоимостью данных помноженную на вероятность их потери (обычно обозначаемую латинскими буквами rf — risk factor). Вот о последнем коэффициенте большинство из нам почему-то забывает и вкладывает в резервирование гораздо большие суммы, чем оно того требует.
 +
 +===== >>>​ врезка мнения экспертов =====
 +
 +==== Петров Иван Сидорович\\ администратор не очень крупной организации (1000 человек) ====
 +
 +Резервируется только база данных и документы пользователей раз в неделю. В качестве носителей используется DVD, на которые записываются данные,​ сжатые WinRAR'​ом. Резервирование ЗарПлаты осуществляется ежедневно во время расчета — встроенными средствами. 2) Крупных аварий еще небыло (тьфу-тьфу),​ хотя терять данные — приходилось,​ но благодаря правильно выбранной политике резервирования ущерб вышел больше моральный (долгое время занял поиск копий).
 +
 +{{backup-economy_Image_6.jpg?​552}}
 +
 +Рисунок 7 Петров Иван Сидорович
 +
 +==== Panagiotis Xenitidis\\ администратор крупного немецкого банка ====
 +
 +Резервируются документы,​ почта (на IMAP серверах),​ базы данных и настройки серверов. Ежемесячно — full, еженедельно — differential,​ ежедневно — incremental. Основной носитель — дисковые массивы,​ full дублируется на ленту. ПО –Bacula. Серьезных инцидентов не было. Вылет HDD не частая и не пугающая ситуация — RAID спасает. По расчетам в случае крупной аварии восстановление не займет более одного рабочего дня, что для нашей организации приемлемо. Терять данные — случалось,​ когда пользователь держал данные не на сервере,​ а на рабочей станции. Вердикт — не следовал предписаниям,​ сам виноват — сам расхлебывай.
 +
 +{{backup-economy_Image_7.jpg?​552}}
 +
 +Рисунок 8 Panagiotis Xenitidis
 +
 +==== Михайлов К. А. ====
 +
 +Ведущий консультант консалтинговой компании "​Анатолий Кудинов и партнеры"​
 +
 +Политики резервирования в компании нету никакой... Хакерских атак отродясь не было, а если были и кто-то что-то спер — ну и фиг с ним (сервер никто не захватывал)! Никто на сервер ничего ценного не выкладывает — разве что книжки выкаченные из Осла, или фильмы. Все ходят с ноутбуками и каждый живет своей жизнью. Лично я раз в месяц скидываю на жесткий диск домашнего компьютера,​ а раз месяца в 3-4 — на CD. На восстановление ничего не уходит. Данные не терял. Но это все не показательно! ​ Хотя вру... Убили русскую версию сайта (я не знаю кто, не интересовался),​ осталась одна английская - тока все по фигу, и по-моему,​ восстанавливать русскую никто не собирается :-)
 +
 +{{backup-economy_Image_8.jpg?​552}}
 +
 +Рисунок 9 Михайлов К. А.
 +
 +===== >>>​ врезка тридцать второй день года\\ ​ (записки парасистемного программиста)\\ Е. В. Лишак (фрагмент) =====
 +
 +***** DATE=84.032 CLOCK=07.59.30
 +
 +Потолок подернулся розовым,​ перекосился и наехал на стену. Воздух свернулся в полупрозрачные сгустки. Сердце сжалось в кулак, стул заскрипел подо мной от ярости,​ хотя я уже стоял. Зубы вот-вот сотрут друг друга в порошок. Сейчас я на него брошусь. Бездельник,​ всю ночь спал, наверное. Теперь пришел раскаиваться,​ как кот, уронивший вазу с телевизора. Он спал, а нам теперь все расхлебывать. И не только нам.
 +
 +***** DATE=84.032 CLOCK=07.59.32
 +
 +Лицо у меня бриджевое. Ни один мускул не дрогнул. Это хорошо. Значит,​ он ничего не заметил. Я не прав. Он не бездельник и не спал, а сообразить было трудно. Я бы тоже сообразил только потом. Что же это со мной делается?​ Я же только из отпуска. Пора возобновлять ежедневные ​ аутогенные тренировки. Чуть не разодрал в клочья живого человека. А за что?
 +
 +Сначала засбоил один дисковод. Засбоил — ну и что ж, бывает. Пакет дисков из него вытащили и поставили в другой такой же дисковод. Может, там прочтется. А в этот дисковод поставили другой пакет. Еще несколько сбоев на разных дисководах,​ еще несколько перестановок. Систему какую-то в этих сбоях, общую закономерность,​ уловили только потом, когда были испорчены данные на четырех пакетах. Как у нас говорят,​ испорчены четыре дисковых тома.
 +
 +Это было ночью. Утром дежурный электронщик сказал об этом мне. Он так никогда и не узнает,​ что чуть не поплатился за это жизнью. Потому что спасать эти тома предстояло мне. Точнее — нам, работающим на ВЦ системным программистам. Но нам не пристало убивать вестников несчастья. Некогда. Нужно спасать тома. И неприятности эти — наш хлеб. Без них нам было бы скучно. Да нас вообще бы и не было тогда на ВЦ. Даже сам не понимаю,​ почему я так взвинтился. Дежурный электронщик тут не причем. Тут есть другие причины. Ему, дежурному электронщику,​ хорошо. Он извинился только передо мной. А мне теперь извиняться перед десятком других,​ можно ​ сказать посторонних,​ людей.
 +
 +***** DATE=84.032 CLOCK=08.05.00
 +
 +Прежде всего нужно предупредить начальство. И осторожно. Не дай бог,​что-нибудь с сердцем. Для него — это ЧП. Срыв плана. Затем — пользователи.Берусь за телефон.
 +
 +— Андрей ​ Федорович?​ Ваш том... Возврат к копии трехдневнойдавности... Извините.
 +
 +— Наташа?​ Твой том... Возможен возврат... Пробуем спасти...
 +
 +Постепенно картина проясняется. Остался только один ​ пользователь,​которого возврат к копии абсолютно не устраивает. Не устраивает — и все.Его предупреждали,​ что он не избавлен от случайностей. Его том два раза внеделю вечерний дежурный системщик прилежно и добросовестно копировал навсякий случай. И вот теперь,​ когда этот случай произошел — его неустраивает. Зачем же мы столько машинного времени ухлопали на копирование?​Он,​ видите ли за эти три дня столько успел всего понаделать,​ столько успелпоназаписать данных на свой том, что теперь уже и не помнит,​ что именно. Иэто нигде, ни при помощи программ,​ ни вручную не зафиксировано.
 +
 +Возврат к копии — для него катастрофа. А виновато,​ конечно же, ВЦ.Ведь это его устройство управления дисками сломалось.Может быть, это очень сложно,​ работать таким образом,​ чтобы всегдазнать,​ что когда сделано,​ и всегда быть готовым к восстановительнымработам?​ Да, сложно,​ если для этого не используются специальныепрограммные средства.
 +
 +Самые мощные из них — это системы управления базамиданных. Те самые, которые используются для создания так называемых "​банковданных"​. Эти системы автоматически ведут дневники изменений и имеютсредства восстановления. На тех ВЦ, где системщики хорошо осознают своюроль и место в вычислительном процессе,​ они довольно много времени тратятна то, чтобы снабдить своих пользователей соответствующими ​ программными средствами защиты данных.
 +
 +***** DATE=84.032 CLOCK=09.22.15
 +
 +В машинном зале аварийно-восстановительные работы в самом разгаре.Три из четырех томов удалось восстановить без потерь своими средствами,​ необращаясь к пользователям. А вот с томом "​TEGRAL"​ дела обстоят хуже."​TEGRAL"​ — это имя тома. Как название книги. А в книге этой около десятитысяч страниц. И у нее тоже есть оглавление. Опись всего содержимого. Сбойв оглавлении — и с томом ничего не сделать. Тридцать миллионов байтов —как корова языком слизала. А ведь он, том этот, почти весь целый.
 +
 + ​Энтропия слепа, но терпелива. Рано или поздно,​ обстреливая нашипозиции по квадратам,​ она нанесет удар по штабу, по центру связи. И тогдапервая линия обороны уничтожена. И приходится отходить на запасныепозиции. Иными словами,​ доставать из магнитотеки пакет дисков с копиейтома.
 +
 +Десять тысяч страниц информации в машинном виде. Один-два раза внеделю дежурный системщик делает копию каждой такой книги, а несколькоколлективов пользователей ВЦ с той или иной интенсивностью содержимое этихкниг изменяют. В такой книге могут быть программы на фортране,​ алголе ​ иликоболе,​ спецификации изделий большого завода и вообще все, что угодно.
 +
 +А в оглавлении потеряно-то всего несколько десятков байтовинформации. Будто какой-то злодей вырвал несколько страниц оглавления,​украл одну, а остальные перепутал местами. Почти все тридцать миллионовбайтов целы. Маленькая пуля, попавшая в сердце большого слона. Ареаниматоры мы плохие. Потому что наша операционная система (ОС) необладает программами восстановления оглавления. Мы готовы буквально побуковкам-байтикам собрать весь том, но не можем. ОС с таким томом работатьне желает. Можно, конечно,​ и вручную,​ но это — работа на неделю. А возвратк копии и приведение ее в состояние на момент сбоя — несколько часов. Еслипользователь умеет это делать. Да и недели никто не даст — ритмпроизводства.
 +
 +