Вопрос: Что, если торнадо прошел через ВАШ центр обработки данных?


В прошлый уик-энд у нас были сильные штормы здесь, в Вирджинии, и, конечно же, кризис в Японии - это напоминание о том, что все может стать плохим! Вопрос, который я задаю себе: «Что, если торнадо ударит по моему центру обработки данных, я готов?»

У меня отличные системы резервного копирования «в моей стойке», включая резервное копирование на магнитной ленте. Поскольку центр обработки данных не является близким, движущиеся ленты с сайта невозможен. То, что я хотел бы найти или создать, - это система, которая по расписанию может резервировать важные элементы, такие как веб-сайты, базы данных, и копировать их удаленно, то есть мой сервер дома. У меня есть FIOS с 35-мегабитным сервисом, поэтому у меня широкополосная связь, мне нужна «система» для этого. Я программист, поэтому я мог бы создать что-то, что сообщает FTP о расписании, но мне любопытно, есть ли что-то, что могло бы заполнить эту удаленную резервную копию сейчас? Мои SQL-серверы резервные копии хранятся в массивах хранилищ, я могу привести эти резервные копии или даже запланировать мой SQL-сервер здесь, чтобы синхронизировать с рабочими серверами по расписанию. Я использую Windows Server 2008 R2 и SQL Server 2008 R2.

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


8
2018-04-20 11:34


Источник




Ответы:


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

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

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

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

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

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


6
2018-04-20 12:34





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

Когда вы говорите о центре данных, то для большинства людей это Gigaytes данных в неделю.

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

Но если вы должны скопировать все данные в резервное местоположение или даже на удаленное хранилище, тогда

1) не используют FTP - это просто неправильный способ сделать это по многим причинам

2) для общих файлов используйте что-то вроде rsync, которое оптимизировано для этой цели

3) для баз данных, посмотрите на инструменты, доступные специально для вашей СУБД - структура файлов может изменяться в массовом порядке без существенного изменения данных. NB это подразумевает реестр MSWindows и данные MSAD.


2
2018-04-20 12:36





У нас есть VPN из нашего офиса в наш удаленный центр данных. В удаленном центре данных у нас есть сервер, на котором установлен сетевой ресурс, который мы настраиваем в качестве места назначения в нашем программном обеспечении для резервного копирования (мы запускаем Symantec BackupExec), т. Е. \ OFFSITEDATACENTER \ OFFSITESTORAGE

Затем мы делаем - полная резервная копия в выходные в этом месте
- инкрементный каждый вечер

Как и наши обычные резервные копии «на месте»

Мы также запускаем VMWare VDR, чтобы каждую неделю снимать изображения наших основных серверов, которые помещаются на диск 2 ТБ SATA, зашифрованный с помощью FreeOTFE, который я принимаю домой каждую неделю.


1
2018-04-20 11:41





У нас есть несколько отдельных активных / активных или активных / полуактивных центров обработки данных с> 50 милями между ними, различными поставщиками энергии, безопасностью, разнонаправленными 10GBps-сетями между ними, а также мы отправляем наши резервные диски между ними. Это для нас.


1
2018-04-20 11:54





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

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

2) Как следствие № 1, убедитесь, что ожидания реалистично определены и закодированы в политике где-то. Достижение поставленной цели по достижению времени восстановления важно, поскольку вы можете проводить неограниченное время, а создание средств «еще лучше».

3) Приоритет ваших систем. План восстановления должен строиться вокруг окончательного списка важности каждой системы. Не пропустите очевидные вещи, как, например, получение DNS и AD до остальных серверов Windows.

4) Если это не offsite и off-network, это просто копия. Это согласуется с другой важной вещью: RAID не является планом резервного копирования.

5) Испытание, испытание, ТЕСТ! Испытайте каждый дюйм своего плана, который вы можете. Если вы можете получить уик-энд в течение периода обслуживания, отключите восходящую линию и / или мощность здания и проверьте время реакции и эффективность вашей команды. План аварийного восстановления, который никогда не тестировался, - это просто принятие желаемого за действительное.


0
2018-04-20 13:24