+7 (499) 502-80-23
Географически распределенное резервное копирование
28.03.2010
Этот пост навеен недавней трагедией, случившейся с одним из крупнейших украинских дата-центров Hosting.ua.
Цитата
Вчера, 27 марта, в 9 часов вечера в дата-центре украинского хостинг-провайдера Hosting.ua по адресу Одесса, ул. Дальницкая, 46 начался пожар. ...Пока что неизвестен объем аварии, но тысячи сайтов, размещавшихся на серверах компании, не работают. Пока что точный объем урона не известен, и скорее всего, на выяснение всех подробностей уйдет не менее недели. Стало также известно, что кроме прямых клиентов Hosting.ua, пострадали и клиенты более мелких провайдеров, чьи сервера размещались на площадке этой компании.
От представителей Hosting.ua не поступало каких-либо комментариев в течение суток, после чего они (полуофициально) сообщили, что попытаются восстановить информацию в течение 7(!) дней, и только той, для которой сохранились резервные копии. Рунет стонет точно также, как и укрнет, потому что Hosting.ua работал на российском рынке не менее успешно, чем на украинском. Ситуация бывалым айтишникам знакома: клиенты не делали резервных копий, [справедливо] считая это обязанностью хостера. А хостер, хоть и подвел, (внимание!) ни в чем не виноват, так как по договору пожар является форс-мажором. Я решил рассказать, как делается резервное копирование в IT-IN в целом и для поддерживаемых сайтов в частности. Правило №1. Резервное копирование должно быть географически распределенным. С точки зрения здравомыслящего человека резервные копии не должны храниться рядом с рабочими. Они не должны находится не только на одном и том же сервере, но и в одной стойке, на одном этаже, в одном здании и, по-хорошему, даже в одном городе. Тем не менее, большая часть российских хостеров поступает именно так - хранит резервные копии в "своем" дата-центре. Особо умелые ухитряются даже продавать место под резервные копии своим клиентам. Мы храним резервные копии как минимум за 500 км от рабочих серверов. И обязательно в другом дата-центре, не аффилированном с основным. Это позволит Вашим данным пережить почти любую природную (наводнения, пожары, землетрясения) и почти любую техногенную (взрывы, выбросы ядовитых веществ) катастрофу. Они не переживут ядерной войны или столкновения Земли с гигантской кометой, но мы такой цели и не ставим. Для других услуг мы также всегда используем географически распределенное копирование, например, в ИТ-аутсорсинге. Так раскиданы наши серверы по миру: Правило №2. Глубина хранения резервных копий должна быть не меньше недели. Ошибки и потери выявляются не сразу. Иногда информация (скажем, файл) удалена, но этого никто не замечает пару дней. Возникает необходимость восстановления файлов не из последней резервной копии и даже не из предпоследней. Для всех тарифных планов поддержки сайтов гарантированная глубина хранения резервных копий - 13 дней. Мы делаем все возможное, чтобы по факту хранить копии как можно больше. Реальная глубина на сегодня - около 60 дней. Копии за весь месяц видны, как на ладони: Правило №3. Правильность создания резервных копий должна регулярно проверяться, а персонал должен быть обучен и "всегда готов". Нет никакого смысла в резервных копиях, если они испорчены. В них нет смысла, если они неполные. Нет смысла, если их никто не может восстановить. Резервное копирование - лишь половина процесса обеспечения сохранности данных. Вторая половина - восстановление. В IT-IN целостность резервных копий проверяется лично мной как руководителем не реже раза в месяц. Инженеры точно знают, что им делать, если случилась беда. Если вы уже являетесь подписчиком поддержки сайтов, это несложно проверить: удалите любой файл на своем сайте, поставьте заявку и включите секундомер. Чтобы уж точно знать, что резервная копия создалась без ошибок, ранним утром на почту инженерам приходит соответствующиее уведомление от всех серверов: Правило №4. Делать резервное копирование дважды, но по-разному. Это правило несколько сложнее в понимании для неподготовленного читателя, но суть сводится к следующему. Резервных копии должно быть две, они должны быть сделаны разными способами и, опять-таки, храниться подальше друг от друга. Во-первых, это дает нам резервную копию даже в том случае, если одна из них не создалась, была повреждена или недоступна из-за проблем в дата-центре. Во-вторых, такой подход дает нам возможность более эффективно отрабатывать различные сценарии восстановления. Ведь восстановление в случае случайного удаления файла в корне отличается от восстановления в случае краха операционной системы на сервере. Поэтому для поддерживаемых сайтов мы храним одну резервную копию в виде файлов и дампов баз данных, а вторую - в виде полного образа виртуальной машины. В случае серьезной аварии восстанавливаем виртуальную машину целиком, в случае мелких неполадок - только нужные файлы и базы данных. Автоматические ежедневные и еженедельные копии одного из виртуальных серверов: Правило №5. Мало резервировать данные, надо еще и резервировать ресурсы. В случае аварии данные сами по себе не нужны, если их некуда восстановить. В случае поломки сервера должен быть другой. В случае отказа магистральной сети, должно быть место в другом дата-центре. Поэтому мы организовали всю работу с сайтами на поддержке таким образом, чтобы их можно было восстановить хоть в дата-центре на другом континенте за несколько часов.

К списку новостей

Array
(
    [ID] => 25046
    [IBLOCK_ID] => 23
    [NAME] => Географически распределенное резервное копирование
    [IBLOCK_SECTION_ID] => 
    [IBLOCK] => Array
        (
            [ID] => 23
            [~ID] => 23
            [TIMESTAMP_X] => 13.10.2016 15:03:57
            [~TIMESTAMP_X] => 13.10.2016 15:03:57
            [IBLOCK_TYPE_ID] => itin
            [~IBLOCK_TYPE_ID] => itin
            [LID] => s1
            [~LID] => s1
            [CODE] => news
            [~CODE] => news
            [NAME] => Новости
            [~NAME] => Новости
            [ACTIVE] => Y
            [~ACTIVE] => Y
            [SORT] => 500
            [~SORT] => 500
            [LIST_PAGE_URL] => /blog/news/
            [~LIST_PAGE_URL] => /blog/news/
            [DETAIL_PAGE_URL] => #SITE_DIR#/blog/news/#ELEMENT_ID#/
            [~DETAIL_PAGE_URL] => #SITE_DIR#/blog/news/#ELEMENT_ID#/
            [SECTION_PAGE_URL] => #SITE_DIR#/blog/news/
            [~SECTION_PAGE_URL] => #SITE_DIR#/blog/news/
            [PICTURE] => 
            [~PICTURE] => 
            [DESCRIPTION] => 
            [~DESCRIPTION] => 
            [DESCRIPTION_TYPE] => text
            [~DESCRIPTION_TYPE] => text
            [RSS_TTL] => 24
            [~RSS_TTL] => 24
            [RSS_ACTIVE] => Y
            [~RSS_ACTIVE] => Y
            [RSS_FILE_ACTIVE] => N
            [~RSS_FILE_ACTIVE] => N
            [RSS_FILE_LIMIT] => 
            [~RSS_FILE_LIMIT] => 
            [RSS_FILE_DAYS] => 
            [~RSS_FILE_DAYS] => 
            [RSS_YANDEX_ACTIVE] => N
            [~RSS_YANDEX_ACTIVE] => N
            [XML_ID] => 26
            [~XML_ID] => 26
            [TMP_ID] => 
            [~TMP_ID] => 
            [INDEX_ELEMENT] => Y
            [~INDEX_ELEMENT] => Y
            [INDEX_SECTION] => Y
            [~INDEX_SECTION] => Y
            [WORKFLOW] => N
            [~WORKFLOW] => N
            [BIZPROC] => N
            [~BIZPROC] => N
            [SECTION_CHOOSER] => L
            [~SECTION_CHOOSER] => L
            [VERSION] => 1
            [~VERSION] => 1
            [LAST_CONV_ELEMENT] => 0
            [~LAST_CONV_ELEMENT] => 0
            [EDIT_FILE_BEFORE] => 
            [~EDIT_FILE_BEFORE] => 
            [EDIT_FILE_AFTER] => 
            [~EDIT_FILE_AFTER] => 
            [SECTIONS_NAME] => Разделы
            [~SECTIONS_NAME] => Разделы
            [SECTION_NAME] => Раздел
            [~SECTION_NAME] => Раздел
            [ELEMENTS_NAME] => Элементы
            [~ELEMENTS_NAME] => Элементы
            [ELEMENT_NAME] => Элемент
            [~ELEMENT_NAME] => Элемент
            [LIST_MODE] => 
            [~LIST_MODE] => 
            [SOCNET_GROUP_ID] => 
            [~SOCNET_GROUP_ID] => 
            [RIGHTS_MODE] => S
            [~RIGHTS_MODE] => S
            [SECTION_PROPERTY] => N
            [~SECTION_PROPERTY] => N
            [PROPERTY_INDEX] => 
            [~PROPERTY_INDEX] => 
            [CANONICAL_PAGE_URL] => 
            [~CANONICAL_PAGE_URL] => 
            [EXTERNAL_ID] => 26
            [~EXTERNAL_ID] => 26
            [LANG_DIR] => /
            [~LANG_DIR] => /
            [SERVER_NAME] => it-in.ru
            [~SERVER_NAME] => it-in.ru
        )

    [LIST_PAGE_URL] => /blog/news/
    [~LIST_PAGE_URL] => /blog/news/
    [SECTION_URL] => 
    [SECTION] => Array
        (
            [PATH] => Array
                (
                )

        )

    [IPROPERTY_VALUES] => Array
        (
        )

    [TIMESTAMP_X] => 20.11.2015 23:59:33
)