OpenQuality.ru

Качество программного обеспечения

Качество программного обеспечения: в главных ролях

Лента  Радар  Блог  Опыт  
Разум  Видео  Заметки  Эпизоды


 

Когда backup не впрок. Истории успехов и провалов

Филипп Торчинский | 02.12.2010

Филипп Торчинский работает в компании Oracle. Признанный эксперт в администрировании Unix-систем, автор книг «UNIX. Практическое пособие администратора» и «Операционная система Solaris».

I. Регулярное резервное копирование – штука для всех полезная

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

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

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

Мои коллеги из компании «Софтджойс» в Петербурге уже много лет подряд трудятся ежедневно не покладая рук над восстановлением дисков и флэшек – и поток их клиентов не иссякает. Между тем, их услуги стоят от 5000 до 30000 рублей в самых простых случаях, а цена еще одного резервного диска или флэшки обычно не превышает 3000 рублей. Это если не считать время и нервы, которые страдают из-за аварий.

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

Пожалуйста, обратите внимание на заголовок этого раздела – РЕГУЛЯРНОЕ резервное копирование – это штука для ВСЕХ полезная. Здесь умышленно выделены слова «регулярное» и «всех». И если со «всеми» всем все понятно, то о регулярности надо себя заставлять помнить. Если вы один раз в неделю не почистили зубы, зубы останутся целы. Если вы один раз в неделю не сделали резервную копию, может статься, что именно в этот раз вы создали (а затем потеряли!) документ, на который потратили много времени и сил. Вы должны решить, как часто (например, раз в день, или каждый раз, когда вы завершили новый важный документ) вы делаете резервные копии, и придерживаться этого правила неукоснительно. Считайте, что это также важно, как предохранение при случайном сексе с незнакомыми или страховка ОСАГО для автомобиля. Если эти аллегории вас не убедили, придумайте себе свое сравнение, такое, чтобы отказ от резервного копирования казался вам самым страшным, что может настигнуть вас на этом свете.

II. Как сделать полезную штуку беcполезной

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

1. несогласованность документов между собой. Так как резервное копирование проводилось пофайлово, могло так случиться, что вначале записывалась старая версия одного файла, а затем новая версия другого. В этом нет ничего плохого, кроме того, что если файлы были связаны между собой и изменялись одновременно (например, график и документ, в который он вставлен), в резервной копии оказывались файлы, несогласованные между собой. Ценность такой копии заметно ниже, чем ценность точной копии всех файлов, сделанной одновременно. Средства сделать точную мгновенную копию есть, но они либо стоят немалых денег, либо требуют хорошей организации копирования, либо вынуждают использовать более современные операционные системы. О них пойдет разговор чуть ниже.

2. отсутствие контроля за выполнением копирования. Автоматическое копирование не всегда спасает (например, оно может не пройти из-за нехватки места на сервере, или прекратиться из-за сбоя сети, или не завершиться вовремя из-за слишком большого количества данных или низкой скорости записи, или сервер окажется перегружен работой и процесс записи «подвиснет»). Словом, такое копирование, даже если оно делается специализированным программным обеспечением требует либо внимательного ручного контроля, либо очень тщательно настроенного и проверенного автоматического контроля, а лучше – и того, и другого.

3. отсутствие контроля за тем, что записывается на магнитную ленту. Центральный офис был расположен далеко от основных рабочих мест, ответственный сотрудник не появлялся там по нескольку дней, а при появлении новых важных данных они не были внесены в список того, что надо записывать на ленту. В результате никто не был осведомлен о том, что копирование могло по нескольку дней не выполняться вовсе, да и данные на ленту записывались не все. Часть лент вообще не использовалась, так как была испорчена, и никто не позаботился о закупке новых, что приводило к преждевременному стиранию сравнительно свежих копий. Решение об изменении схемы резервного копирования (перезаписывать кассеты чаще, а неисправные просто выбросить) было принято исполнителем самостоятельно, он никому об этом не рассказал.

Из этого опыта пришлось вынести три правила:
1) нет контроля – считайте, нет копирования
2) нет контроля надежности резервной копии – считайте, нет копии
3) исполнитель резервного копирования должен быть надежным, обученным и ответственным

III. Оценивайте риски трезво

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

Используйте быстрые и надежные носители. Если вы копируете данные на флэшки, помните, что флэшки могут сильно отличаться по скорости записи, покупайте более дорогие, но быстрые экземпляры. Для важных данных используйте две разные флэшки. Перестаньте доверять рекламе: количество циклов перезаписи, которые выдерживает флэшка, на практике – не десятки тысяч циклов, а всего лишь сотни циклов. Храните флэшки там, где они не могут перегреться. Флэшки нельзя гнуть, швырять или наступать на них, несмотря на то, что ронять их обычно можно без вреда. После года использования переставайте доверять флэшке: она может работать еще долго, но уверенности, что с нее точно можно будет прочесть данные, уже быть не должно. Не жалейте денег на новые резервные носители – диски и флэшки, терять данные и время – всегда дороже!

Храните данные в резервных копиях в таком формате, который вы везде сможете прочесть. Так, файловую систему ZFS не поймет никто, кроме Solaris, Mac OS X и FreeBSD, а более свежие ее версии – только Solaris 11 Express. Диск в формате NTFS прочтется в Linux, но только если в данном экземпляре Linux установлена поддержка этой возможности. Наиболее универсальный формат – FAT32, но не все версии Windows умеют форматировать большие диски в FAT32 так, чтобы они везде прочлись, может понадобиться специальная программа. Я одну такую однажды купил в Интернете, но забыл название. Впрочем, сойдет любая – Google расскажет о многих.

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

Если вы занимаетесь веб-разработкой, делайте копии каждого веб-сайта, за который вы отвечаете, ежедневно. Помните, что важно сохранять не только содержание сайта, но и информацию о том, какое программное обеспечение используется для его отображения – версию веб-сервера, интерпретатора php, perl, базы данных mysql или postgresql и прочего. Если ваш проект связан с установленной на сервере виртуальной машиной Java, знайте точно ее версию. Сотрудники хостинговой компании или ваши коллеги-сисадмины могут без предупреждения изменить версию, и вы должны быть готовы потребовать «вернуть, как было». Для этого надо знать, «как было».

Если у вас есть веб-сайт, который кто-то разработал для вас, не надейтесь, что этот «кто-то» сделал резервную копию и запомнил версии установленного на сервере ПО. Сделайте это сами. Запишите версии в блокнот и сообщите всем вокруг, куда вы этот блокнот кладете.

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

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

Делайте достаточное количество резервных копий, и помните, где вы их храните.

IV. Простые решения

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

Это – очень дешевое решение. Оно требует только немного времени и внимания – всего от одного человека.

Если вы можете использовать в качестве хранилища данных компьютер с системой Solaris 10, OpenSolaris или Solaris 11 Express, надо использовать встроенные средства резервного копирования. Файловая система ZFS, на которую по умолчанию устанавливается OpenSolaris и Solaris 11 Express, и которую можно использовать и в Solaris 10, позволяет сделать снимок всей файловой системы за мгновение:

zfs snapshot <имя-файловой-системы>@<имя-снимка>

Например,

zfs snapshot rpool/home/filip@2010-11-16

После этого сделанный снимок можно передать по сети или записать на внешний диск командой

zfs send

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

Для хранения самых важных документов можно использовать сервис компании Amazon, s3.amazon.com. Сейчас хранение первых пяти гигабайт файлов там бесплатное, каждый следующий гигабайт обойдется в несколько центов в месяц. Для хранения важных документов и фотографий – годится. Фильмы, конечно, туда не закачаешь: и долго, и недешево обойдется. Однако «важные» здесь не значит «конфиденциальные». Передача по сети и размещение на чужих компьютерах, находящихся не под вашим управлением, любых конфиденциальных данных – дело крайне рискованное и неразумное. Для таких данных можно использовать флэшку с встроенным модулем шифрации, требующую аутентификации по отпечатку пальца. Такие давно есть.

V. Когда резервное копирование не помогает

Если вы случайно нажали кнопку «выйти без записи» после того, как целый день редактировали важный документ, и до того вы этот документ не записывали на диск – вам не повезло. От невезения резервное копирование не помогает.

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

Комментарии (9)

Некоторые из описанных проблем решаются применением правильных практик SCM – software configuration management, а именно применением систем контроля версий.

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

Это же можно отнести и к документообороту вообще. Например, если решение основано на применении MS Sharepoint – то там вполне нормально ведется история изменения документов. А значит, бэкап базы документов также решает упомянутые проблемы 1 и 2.

Касаемо сохранности самих бэкапов – верно подмечено использование того же Амазоновского облака. Эту тему можно расширить и дальше – сейчас много доступных облачных сервисов, которые гарантируют сохранность данных самой своей структурой. Малые организации могут просто купить место хоть на том же dropbox – и забыть о проблеме.

Aquary | 03.12.2010 | 2:31 дп. Ответить #

Aquary, спасибо! Очень ценные дополнения.

Тема резервного копирования данных тесно переплетается с удобством самой структуры хранения. Две крайние ситуации: 1) данные хранятся в виде разнородных обособленных файлов; 2) данные хранятся в иерархической структуре, позволяющей работать с данными наиболее эффективно (когда-то на эту тему была статья: http://blog.openquality.ru/knowledge-storing/ ). Получается, что каждая структура хранения определяет способ ее резервного копирования. В этом контексте вариант с SCM очень интересен.

Кормчий | 03.12.2010 | 6:20 дп. Ответить #

Согласен, структура ставит рамки, которые уже направляют движение по бэкапу данных.

Кстати, в первой ситуации – если структуры нет – появляется хороший повод, чтобы структура таки появилась. После чего задача о бэкапе сводится к типовой :)

Aquary | 03.12.2010 | 7:02 дп. Ответить #

+ 1 :)

Кормчий | 03.12.2010 | 7:32 дп. Ответить #

Не все источники бесперебойного питания адекватно реагируют на перепады напряжения.
Для того, чтобы бороться с этой напастью, полезно применять стабилизаторы, подключенные _до_ ИБП, т. е. розетка –>стабилизатор–>ИБП–>оборудование.

Стоят стабилизаторы мало, а жизнь делают заметно лучше (и для ИБП в частности).

Хочется ещё добавить, что мне свойственно рассматривать резервное хранение данных как один из IT бизнес-процессов — все из которых должны быть прилично организованы ;-)

Александр Николаев | 23.12.2010 | 6:56 дп. Ответить #

Александр, спасибо за интересный и полезный комментарий!

Кормчий | 23.12.2010 | 8:41 дп. Ответить #

Хочу дополнить из личного опыта.

Не все стабилизаторы спасают от перепадов напряжения. Лично сидел за компьютером, который был подключен по описанной вами схеме. В момент скачка напряжения «сгорело» все, включая монитор (!!!) и, конечно, винчестеры. Из-за кажущейся надежности и плохого, нерегулярного интернета резервная копия базы данных на внешний сервер делалась раз в месяц (инкреметный бекап на второй винт на том же компьютере – ежечасно).

Результат:
– потерянные данные за три недели работы небольшого магазина
- еще два дня чистых потерь времени десятка сотрудников на инвентаризацию
- деньги на новый компьютер и нормальный интернет для внешних бекапов.

Так что в моем понимании бизнес-процесс бекапа © теперь включает регулярное частое резервирование на удаленный сервер и с него – на внешний накопитель.

Михаил | 02.10.2011 | 10:08 дп. Ответить #

Михаил, спасибо за ценный комментарий! За одного битого двух небитых дают!

Кормчий | 02.10.2011 | 10:47 дп. Ответить #

[...] В случае локальной версии пользователь сам заботился о резервном копировании и восстановлении. Теперь об [...]

OpenQuality.ru | Качество программного обеспечения | 21.02.2011 | 11:52 дп. Ответить #

Оставьте комментарий

Required.

(будет спрятан за семью замками)

(будет открыт, если это не спам)

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