Мы находимся в процессе настройки нового сервера для миграции старых.
По сути, у нас будет Windows Server (2003 или 2008) с 6+ виртуальными серверами (разработка Windows и Linux, приложения, базы данных и пара тестовых рабочих станций) на RAID 5.
Также нам нужно централизовать данные (файлы и репозитории SVN), поэтому понадобится файловый сервер. Поскольку у нас нет никакого опыта администрирования и мы никогда не делали резервное копирование,есть ли у вас опыт виртуализации файловых серверов? Лучше всего запускать их на физическом сервере? Любые советы по запуску этого будут приветствоваться.
Что касается нашей стратегии резервного копирования, то на данный момент она выглядит следующим образом:
Примечание: резервное копирование на ленту на данный момент для нас не вариант из-за финансовых ограничений.
- Выполняйте полное резервное копирование еженедельно на отдельный резервный сервер на RAID 5 (см.Должен ли резервный сервер использовать RAID?) и на внешний накопитель (что-то вроде ленточного накопителя для бедных)
- Дифференциальное ежедневное резервное копирование
- Планируем ежемесячное резервное копирование онлайн-сервисов
Вы считаете этот подход разумным? Я уверен, что есть много аспектов, которые нужно нести, и которые мы, несомненно, упускаем.
Наконец, одна мысль, которая нас беспокоит, это как сделать резервную копию машин virtualbox. Один простой способ - просто сделать резервную копию всего (как рекомендовано в одном из вопросов, я не могу найти, какой именно...).
Что вы посоветуете по поводу данных, содержащихся в этих vboxes? Следует ли также делать резервную копию ("на всякий случай..."), или безопасно делать резервную копию виртуальных образов напрямую?
Если это послужит дополнительной информацией, мы планируем использовать BackupExec.
Спасибо, что уделили время прочтению этой статьи.
----- ОБНОВЛЕНИЕ 04.08.2009 -----
По состоянию здоровья я не смог продолжить этот вопрос. Спасибо тем, кто ответил на мой вопрос, это было большой помощью.
Вот запасной план, который мы набросали теперь, когда у нас есть больше информации: поскольку мы небольшая компания (из Южной Америки), на данный момент мы не можем позволить себе ленточный накопитель.
Я теперь понимаю, что bacukp не является bacukp, если он не находится за пределами офиса и не в сети, но мы пытаемся найти лучшую стратегию для наших финансовых ограничений:
Окно потери данных: 1 день/8 часов. Время восстановления: 1 день/8 часов. Что нужно резервировать: все (данные и установки сервера)
- Ежедневно: ежедневно делайте резервное копирование diff на физический сервер резервного копирования, возможно, с помощью BackupExec. Кто-то предложил использовать один из этих внешних концентраторов хранения с поддержкой sata. Другой предложил загрузить его в службу хранения, пока мы можем получить ленту. У нас нет возможности вывести их за пределы сайта прямо сейчас (так что окно потери данных «поддельное»)
- Еженедельно: создавайте полную резервную копию на внешнем диске емкостью 1 ТБ.
- Ежемесячно/ежегодно: то же самое, что и еженедельно. У нас есть проблема, где хранить эти резервные копии
Мы хотим, чтобы все было просто, но я думаю, что мы усложняем все эти ежедневные стратегии по преодолению утечек данных из резервных копий, находящихся вне офиса.
решение1
Мой стандартный совет по резервному копированию:
Весь смысл резервного копирования — в возможности восстановления.Если вы не уверены полностью, что сможете вернуть свои данные, ваши резервные копиибесполезный. Все, что вы реализуете в своем решении для резервного копирования, должно исходить из точки зрения «как мне восстановить данные из этого?»
Лента не так уж и дорога, и у нее есть преимущество в том, что она намного долговечнее диска. Меньше подвижных частей, нет постоянного тока, проходящего через нее, все это хорошо. Если она спасет вашу задницу один раз, то она уже окупилась в моей книге.
Помимо вопроса «сколько данных вы можете позволить себе потерять», вам также необходимо учесть вопрос «сколько времени вы можете позволить себе быть в состоянии простоя в случае сценария DR?» 3-дневное время восстановления — это 3 дня потерянного бизнеса. Вы должны считать время восстановления в часах и на пальцах одной руки.
Однако вы можете очень быстро вляпаться в глупые деньги, если позволите себе стать слишком параноидальным по этому поводу, поэтому вам следует подумать о том, чтобы разделить свои серверы на 2 или 3 лота. Те, которые вам абсолютно необходимо вернуть СЕЙЧАС, чтобы продолжить основные бизнес-функции, и те, которые вы можете отложить до тех пор, пока основные не вернутся. Вложите крупные инвестиции в первый лот, убедитесь, что у вас есть полностью документированные процедуры восстановления (для ОС, для приложений и для данных), которые может выполнить слепая прокаженная обезьяна с одной рукой, связанной за спиной. Распечатайте и переплетите копию и храните ее в несгораемом сейфе.- вам конец, если у вас есть только электронная копия, которая потеряется или будет уничтожена. Но не думайте, что это означает, что вы можете расслабиться со второй партией, просто вы можете отложить их возврат или потратить на это немного больше времени (например, записав их на более медленный носитель).
Конкретные примеры: ваш основной файловый сервер, конечно, попадает в первую партию. Ваш сервер HR попадает во вторую партию. Это важно для HR-специалистов, но будут ли ваши основные бизнес-функции в порядке в течение пары дней без HR-системы? Да, я думаю, что будут.
Сделайте свое решение по резервному копированию простым и скучным.Слишком часто я видел, как люди внедряли причудливые или сложные решения для резервного копирования, которые в итоге оказывались слишком сложными, кропотливыми и ненадежными. Резервное копирование скучно, потому что резервное копированиедолженбыть скучными. Чем они проще, тем легче их будет восстановить. Вам нужен подход "я Og, Og нажму кнопку, Og получу данные обратно". Сохраните там элемент ежедневного руководства. Это помогает установить тренировку, которая может избежать ситуаций, когда кто-то забывает сменить ленту или повернуть жесткий диск в бассейне. Вы можете уволить ответственного человека, если это произойдет, но знаете что? Вы все еще находитесь в положении, когда вы потеряли месяц данных.
решение2
Главный вопрос: какой объем данных вы готовы потерять? Один месяц? Один день? 6 часов? 5 минут?
Чем меньше период потери данных, тем дороже обходится эта процедура.
решение3
Ник,
Я настоятельно рекомендую вам ознакомиться с книгой «Резервное копирование и восстановление» издательства O'Reilly.
http://oreilly.com/catalog/9780596102463
Вам объяснят такие термины, как «единая точка отказа», а также общую стратегию резервного копирования ваших критически важных систем.
Это хорошая книга для книжной полки любого человека.
решение4
Я бы предложил запустить файловый сервер на физическом ящике, так как он, скорее всего, будет довольно интенсивным по вводу/выводу. Также было бы неплохо иметь возможность горячей замены неисправного диска, не выключая все виртуальные машины. Хотя это зависит от вашей конкретной настройки.
Ваш график резервного копирования звучит разумно, но зависит от того, сколько вы можете позволить себе потерять. Похоже, что большинство ваших резервных копий (кроме ежемесячного) находятся на месте, что означает, что вы потеряете максимум месяц, если здание сгорит или будет взломано.
Если вы возьмете внешний диск домой, вам придется держать его дома, пока не наступит срок резервного копирования, иначе это не будет действительно резервным копированием за пределами офиса, не так ли? Если вы будете дисциплинированы, вы потеряете максимум неделю. Лучше было бы чередовать набор из трех внешних жестких дисков, так что у вас всегда будет самый старый на месте, а самый новый — за пределами офиса.
Не забывайте периодически тестировать и документировать свои резервные копии; Вам нужно спокойствие, что каждая из ваших систем резервного копирования может восстановиться правильно. Вам понадобится документация, чтобы один из ваших коллег мог восстановить данные. Вам также понадобится документация о том, как перестроить весь сервер. Если один из них выйдет из строя, у вас будет слишком много мыслей, чтобы помнить каждую деталь.
Не по теме: Так уж получилось, что я ищу похожую инфраструктуру для нашей небольшой компании. Схожий уровень опыта, хотя у нас уже есть резервные копии. Я поделюсь с вами нашим текущим проектом, чтобы дать вам альтернативную точку зрения, а не судить вашу:
Мы планируем три сервера: два хоста виртуализации и один сервер хранения. Сервер хранения, скорее всего, будет работатьOpenfiler. Он будет подключен через (возможно, двойной) гигабитный Ethernet к двум хостам, оба с хорошими процессорами и большим объемом памяти, но с едва ли каким-либо хранилищем (возможно, только небольшими SSD). Эти хосты будут работать под управлением CitrixXenсервер(или может быть VMWareESXi) наоголенный метал, потому что это намного эффективнее, чем запуск программного обеспечения виртуализации внутри другой операционной системы, которая в основном не делает многого (например, посмотрите на разницу в производительности между VMWare Server и VMWare ESXi). Xenserver кажется наиболее интересным, поскольку он предоставляет корпоративные функции бесплатно, в то время как ESXi может оказаться дорогим, если вам нужно больше, чем просто базовые возможности. Хосты Xenserver не будут иметь собственного хранилища, но будут использовать хранилище на уровне блоков черезiSCSIс сервера Openfiler каквиртуальные жесткие диски. Openfiler может делать снимки, RAID и т. д. Xenserver может делать Live-миграции виртуальных машин с одного сервера на другой, поэтому мы можем проводить обслуживание на одном сервере, не отключая гостевые виртуальные машины. Получите гигабитный коммутатор с поддержкой VLAN, чтобы вы могли отделить трафик хранилища от трафика виртуальных машин. Несколько ИБП для обеспечения контролируемого отключения в случае сбоя питания, и все готово. Почти все расходы приходятся на оборудование, поскольку программное обеспечение (удивительно) бесплатное.
Извините, что ответ получился немного длинным, но я надеюсь, что другая точка зрения будет для вас ценной.