реклама  

2006-11-27 00:01:45

Миф четвертый. Ежедневный бэкап

Многие хостинг-провайдеры обещают «ежедневный бэкап» и заверяют нас в том, что на всех серверах установлены RAID-массивы, которые гарантируют сохранность информации. Непонятно только одно: почему после аварий в дата-центрах данные оказываются безвозвратно утеряны? А ведь таких случаев много.

Хостинг-провайдеры особенно любят фразу «ежедневный бэкап». Они считают, что эта фраза является исчерпывающей сама по себе и не требует никаких пояснений. На сайтах хостеров редко встретишь подробное описание самой процедуры восстановления данных.

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

Гарантируя «ежедневный бэкап», хостер обещает каждый день делать копии вашей информации. Тут возникает целый ряд вопросов.

1. Сколько дней хранится копия? Один день или больше?

2. Где именно хранится копия? На том же сервере или на отдельном?

3. В каком случае вам разрешено восстановить данные?

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

Давайте посмотрим, что скрывается за мифом о ежедневном бэкапе.

Как долго хранится копия

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

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

Нужно заметить, что у зарубежных хостинг-провайдеров услуга резервного копирования почти всегда является платной. В этом случае у клиента в панели управления часто присутствует пункт «Резервное копирование», так что он может в любой момент сделать копирование «за свой счет», то есть самостоятельно и, часто, на свой локальный компьютер. Осуществлять эту процедуру можно как угодно часто, а восстанавливать сайт клиент потом будет тоже самостоятельно.

В некоторых ситуациях самостоятельный бэкап надежнее автоматического, который делает (или обещает делать) хостинг-провайдер. Однако при этом возникает вопрос — куда скачивать информацию? При больших объемах скачивать на свой домашний компьютер может оказаться очень дорого и долго. «Складировать» на тот же диск опасно. При физическом повреждении диска вы потеряете не только сайт, но и его бэкап. Видимо, разумнее всего «сливать» бэкап на сервер по соседству. И, несмотря на то, что расходы на хостинг при этом могут удвоиться, чувствовать вы себя будете намного спокойнее.

Если вы надеетесь на автоматический бэкап хостера, то обязательно узнайте у него все подробности. В нормальной системе резервного копирования хранятся бэкап-копии как минимум за последние семь дней, а клиент получает право восстановить систему из бэкапа за любой день, на его выбор. Бывает, что за отдельную плату срок хранения архивов можно продлить (каждая «дополнительная» неделя стоит около $10 в месяц).

 

Где именно хранится копия

Здесь возможны варианты. Говоря о бэкапе, компания может подразумевать всего лишь то, что в сервере установлено несколько жестких дисков, объединенных в RAID-массив.

В принципе, наличие RAID-массива является большим плюсом, потому что надежность хранения информации при этом может возрасти на порядок. Как известно, большинство типов RAID-систем (Redundant Array of Independent Disks, то есть «избыточный массив независимых дисков») предусматривают дублирование информации на нескольких жестких дисках. Если вдруг какой-то диск выходит из строя, то его меняют без перезагрузки сервера («горячая замена»), а информация на лету восстанавливается из копии. При этом используются самые обычные жесткие диски, которые объединяются в кластер с помощью специального RAID-контроллера.

Однако, нужно заметить, что массивы RAID бывают разных типов (RAID 0, 1, 2, 3, 4 и 5), все они отличаются друг от друга по уровню надежности и другим характеристикам. В частности, стандарт RAID 0 не предусматривает избыточного копирования информации вообще. Несколько жестких дисков используются только для повышения производительности. То есть использование RAID-массивов само по себе не гарантирует сохранность информации.

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

Кроме того, даже самые надежные RAID-массивы никоим образом не могут выполнять функцию резервного копирования. Они помогают только при физической порче одного из винчестеров, но никак не в случае взломов или случайного повреждения данных самим клиентом. Если клиент или служба поддержки замечают взлом или повреждение данных позже обычного времени архивации, то в зеркале RAID им будет доступна уже поврежденная или взломанная версия.

Да и от логических сбоев в файловой системе RAID-массив также не спасает. В случае если файловая система даст сбой, то наиболее вероятно, что придется восстанавливать полностью всю систему.

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

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

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

 

Вариант для самостоятельного бэкапа

Не так давно известная интернет-компания Amazon запустила платформу удаленного хранения файлов Amazon S3 (Simple Storage Service). Данный сервис позволяет закачивать информацию в дата-центры Amazon и хранить ее там сколь угодно долго. При этом цены на размещение информации в разы дешевле стоимости хранения данных у хостеров. В месяц за хранение каждого гигабайта данных нужно будет заплатить по 15 центов, а за трафик — по 20 центов за гигабайт. В большинстве дата-центров и на большинстве хостинг-площадок обычная цена хранения резервных данных составляет не менее $1 за гигабайт в месяц, то есть почти в семь раз дороже.

 

В каком случае вам дадут восстановить данные

 

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

Справедливости ради скажем, что во многих случаях ситуацию можно разрешить, если позвонить в компанию и вежливо попросить системных администраторов о помощи. Иногда они идут навстречу клиентам и соглашаются осуществить восстановление бесплатно. В остальных случаях обычно можно сделать бэкап за небольшую плату ($25-50 за час работы системного администратора).

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

Shit happens

Несмотря на то, что почти каждый хостинг-провайдер уверяет нас в «ежедневном бэкапе» информации, очень многие попадали в неприятные истории.

Пожалуй, самый крупный скандал с потерей данных случился летом нынешнего года с участием российского хостинг-провайдера Valuehost . 30 июня 2006 г. в результате сбоя в дата-центре были полностью или частично удалены около 500 сайтов. Как стало известно потом, сбой заключался в отказе одного из жестких дисков на одном-единственном сервере.

В случае с Valuehost правда вышла наружу. Оказывалось, что на серверах не было контролеров RAID, а резервное копирование или вообще не осуществлялось, или по каким-то причинам прошло неудачно. Итог известен.

Что характерно, компания Valuehost не понесла абсолютно никакой ответственности. В договоре на хостинг было особо отмечено, что хостинг-провайдер не несет никакой ответственности за сохранность данных. Это стандартный пункт для многих договоров на услуги хостинга. Выглядит он примерно так:

«5.3. Исполнитель предоставляет Услугу «как есть», т.е. не несет никакой ответственности за любой прямой и косвенный ущерб, вызванный технологическими причинами объективного и субъективного характера.»

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

 

Анатолий Ализар

Материал подготовлен при содействии хостинг-провайдера «Экстмедиа»



комментариев (2) отправить

Информер www.bybanner.com - новости белорусского интернета на вашем сайте!

Добавить комментарий

Имя

Ваш комментарий не должен превышать 1000 знаков




Новости интернета

Новости компаний

Комментарии

Аналитика

Колонки авторов

Виола Сташкевич

Виола Сташкевич



Чего не хватает публичной жизни Байнета?
научных конференций
различных спартакиад или соревнований
развлечений и отдыха всей «IT-тусовки»
выставок и презентаций


Подписка