Что делать, если торнадо прошел через ваш дата-центр?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А также наши обычные "локальные" резервные копии

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

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

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

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

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

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

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

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