За прошедшие выходные здесь, в Вирджинии, были сильные штормы, и, конечно же, кризис в Японии - напоминание о том, что все может пойти плохо в мгновение ока! Вопрос, который я задаю себе: "Что, если торнадо ударит по моему центру обработки данных, я готов?"
У меня есть отличные системы резервного копирования «в моей стойке», в том числе резервные копии на магнитной ленте. Поскольку дата-центр не находится близко, перемещение лент за пределы площадки невозможно. Я бы хотел найти или создать систему, которая по расписанию может создавать резервные копии важных элементов, таких как веб-сайты, базы данных, и копировать их удаленно, то есть мой домашний сервер. У меня есть FIOS со службой 35 Мбит, поэтому у меня есть широкополосный доступ, мне нужна "система" для этого. Я программист, поэтому я могу создать что-то, что информация FTP недоступна по расписанию, но мне любопытно, есть ли что-то, что могло бы удовлетворить эту потребность в удаленном резервном копировании сейчас? Мои SQL-серверы копируются в массивы хранения, я мог бы отключить эти резервные копии или даже запланировать здесь свой SQL-сервер для синхронизации с производственными серверами по расписанию. Я использую Windows Server 2008 R2 и SQL Server 2008 R2.
Что вы все порекомендуете для стратегии за пределами площадки в условиях кризиса, например, стихийного бедствия, которое разрушило наш центр обработки данных? Вы готовы? Я надеюсь, что другие зададут себе этот вопрос и извлекут уроки из этих стихийных бедствий, которые мы наблюдаем слишком часто.
Ваши варианты должны быть продиктованы соглашениями об уровне обслуживания с клиентами и ограничены вашим бюджетом.
Как минимум, у вас должны быть резервные копии всех важных данных за пределами офиса. То есть сегодня любые данные, которые вы не можете воссоздать с нуля, нужно хранить в другом месте. Автономное резервное копирование лучше: онлайн-резервное копирование или репликация могут помочь при ударе торнадо, но что произойдет, если рассерженный сотрудник сбросит базу данных или разрушит файловую систему?
Исходя из базового уровня автономного резервного копирования, вы можете начать изучение вариантов, которые ускорят восстановление в обмен на более высокую стоимость. Здесь есть огромное количество вариантов, начиная от одного хоста для оперативного резервного копирования, который вы описываете, и заканчивая полностью реплицированными средами с синхронной репликацией данных, работающей активным (-активным) + для почти нулевого времени простоя.
Вы обнаружите, что восстановление с нуля будет намного проще, если вы будете максимально аккуратно отделить данные от инфраструктуры. Например, восстановление с нуля будет намного, намного быстрее, если вы будете развертывать его с помощью таких систем, как puppet или chef, а не вручную. Повторение всей работы, которую вы вложили в создание своих систем, будет намного быстрее, если вы сможете максимально автоматизировать. Разделение данных также сокращает объем данных, которые необходимо создавать для резервного копирования: не выделяйте гигабайты ОС, если вам действительно нужно всего несколько мегабайт системных конфигураций и данных приложения.
Эти варианты могут быть довольно дорогими, поэтому вам необходимо определить, сколько ваша компания готова потратить на восстановление после сбоев и сколько времени простоя могут выдержать ваши клиенты. Исключите варианты, которые слишком дороги или слишком медленны для ваших клиентов.
Выбрав решение для аварийного восстановления, обязательно попробуйте его на практике. Я бы рекомендовал хотя бы раз в год или всякий раз, когда ваша архитектура меняется, в зависимости от того, что происходит чаще.
Business Continuity идет намного дальше, чем просто обеспечение доступа к читаемым резервным копиям. Но, ограничивая объем ответа только этим, в конечном итоге он будет жизнеспособным только там, где концы с концами пропускная способность от центра обработки данных к хранилищу резервных копий достаточно велика, чтобы обрабатывать объем изменений данных.
Когда вы говорите о центре обработки данных, то для большинства людей это гигабайты данных в неделю.
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) Тест, Тест, ТЕСТ! Проверьте каждый дюйм своего плана, насколько сможете. Если вы можете потратить выходные на период обслуживания, отключите восходящий канал и / или питание здания и проверьте время реакции и эффективность вашей команды. План аварийного восстановления, который никогда не тестировался, - это просто принятие желаемого за действительное.