Восстановление на «голое железо» для виртуальных машин в Hyper-V (часть 1)

Введение

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

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

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

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

Некоторая справочная информация

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

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

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

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

Моя стратегия аварийного восстановления

Теперь, когда я рассказал вам немного о своей сети, я хочу поговорить о плане аварийного восстановления, который у меня был до удара молнии. Мой основной механизм для резервного копирования и восстановления данных в моей сети — это сервер, на котором работает System Center Data Protection Manager 2007 (DPM 2007). Если вы не знакомы с DPM 2007, это корпоративное решение Microsoft для резервного копирования. DPM 2007 обеспечивает непрерывную защиту данных посредством резервного копирования с диска на диск и на ленту.

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

Хотя мой сервер DPM 2007 — не единственная линия защиты от потери данных, я должен сказать, что мне очень повезло: мой сервер DPM 2007 и подключенный к нему внешний массив хранения были одними из немногих компонентов в моей сети, которые не были уничтожены ударом молнии.

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

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

Вместо того, чтобы копировать все свои данные на внешний жесткий диск, я нашел ноутбук HP со вторым отсеком для диска. Я установил жесткий диск на 500 Гб. Затем я использовал взлом реестра, чтобы заставить Windows использовать второй диск для автономного хранилища. Конечным результатом является то, что каждый раз, когда я подключаю свой ноутбук к своей сети, Windows синхронизирует мой автономный кеш с моим файловым сервером. При этом я создал всегда актуальную копию своих данных, которую я могу использовать, когда нахожусь в пути. Что еще более важно, эта копия может действовать как автономная реплика, которую я могу использовать для целей аварийного восстановления, если в этом возникнет необходимость.

Частью второго уровня моего плана аварийного восстановления является защита данных, найденных в моем почтовом ящике Exchange. Для этого я настроил Outlook на использование автономного кэширования. Таким образом, если мой Exchange Server когда-нибудь выйдет из строя и я не смогу восстановить свою резервную копию, я смогу скопировать содержимое моего автономного кеша в PST-файл. Когда Exchange Server в конечном итоге будет перестроен, содержимое PST-файла можно будет скопировать обратно в почтовые ящики Exchange. Как я уже сказал, этот подход неудобен для использования в большой сети, но мне он подходит.

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

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

Вывод

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