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

Так уж бывает, что и винчестеры не вечные, и RAID массивы не надежны.

Да-да, вроде не так давно у бигмира умер два винчестера в RAID массиве 10го уровня, да так, что данные статистики их счетчиков восстановить было весьма проблематично.

Да и платы RAID контроллеров тоже не вечные, и в один прекрасный день могут сказать адью. А IT-технологии развиваются семимильными шагами, и уже через пару лет найти популярное и проверенное «сегодня» железо может оказаться огромной проблемой. Да и не всегда при переносе жестких дисков с одного RAID контроллера на полностью аналогичный, собрать обратно данные на RAID массиве может оказаться не возможным. Новая плата контроллера, той-же самой модели, с той-же версией прошивки, отличающаяся лишь серийным номером, может банально не увидеть на жестких дисках массив, собранный другим контроллером.

Или такая ситуация, недавно сам с ней столкнулся: большой и «взрослый» сервер. Две хот-свап корзины на дюжину SAS HDD. На десяти SAS жестких дисках был собран RAID-массив. 11й диск стоял как резервный (spare) диск, который в обычном режиме работы пребывает в состоянии stand by, на случай выхода из строя одного из задействованных в массиве дисков. В таком случае он автоматически становится на замену вышедшего из строя жесткого диска.

RAID-массив работал и прекрасно выполнял свои функции, но лишь до той поры, пока один из включенных в него дисков не вышел из строя, окончательно и бесповоротно. Хороший и умный контроллер отреагировав на такую ситуацию, заменил в массиве ушедший в край вечнохолодных процессоров винчестер на резервный и занялся пересборкой (rebuild) массива. Но, во время этой, довольно продолжительной по времени, процедуры, оставшиеся винчестеры отреагировали на возросшую до предела нагрузку, И дружно, гуськом, отправились вслед за первым в страну вечнохолодных процессоров. Ребилд завершен не был.

И как тут без бакапов?

Но мы вроде собирались поговорить об удаленных бакапах?

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

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

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

Но, хотелось бы оговорится, что даже удаленный бакапа не дает 100% уверенности. Просто вероятность каких либо проблем в двух различных, территориально разнесенных датацентрах одновременно ничтожно мала, на порядки ниже проблем в одном единственном датацентре. И это относится не только к датацентрам, и вообще ко всех IT-архитектуре.

Стоимость жестких дисков уже давно стала ниже стоимости той информации, которая на них хранится, И что лучше, потерять базу клиентов, базу взаиморасчетов с клиентами, бухгалтерскую или технологическую документацию, домашний семейный фотоархив или потратить немного денег и усилий на организацию удаленного бакапа?А ведь не зря говорят о том, что «кто владеет информацией, тот владеет миром».