Назад | Перейти на главную страницу

Оборудование и стратегия резервного копирования в распределенной сети Windows Server 2008

Этот вопрос является продолжением этот.

У нас есть домен Windows Server 2008 R2 в сети, которая охватывает два разных здания, соединенных двухточечной линией со скоростью 100 Мбит / с. В организации работает более 60 пользователей. Мы планируем использовать папки DFS и репликацию DFS для обслуживания файлов по всей организации. Предполагаемый объем данных превышает 2 ТБ и будет расти примерно на 20% ежегодно. Идея состоит в том, чтобы установить файловый сервер DFS в каждом здании и использовать DFS, чтобы все содержимое оставалось реплицированным по каналу 100 Мбит / с.

Сейчас мы рассматриваем оборудование и стратегии резервного копирования. Мы - клиенты Dell, и, просмотрев онлайн-каталог Dell, я могу увидеть несколько вариантов оборудования для резервного копирования. Мои основные сомнения следующие:

  1. Вы бы выбрали ленточную библиотеку, резервную копию диска или есть другие варианты, которые стоит рассмотреть?
  2. Будете ли вы выполнять пакетное резервное копирование (например, каждую ночь) или использовать непрерывное резервное копирование (например, пока пользователи работают)?
  3. Вы бы использовали выделенный сервер резервного копирования, к которому подключена ленточная библиотека (или любое другое устройство резервного копирования), или есть другой альтернативный способ сделать что-то?

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

Во-первых, я бы рассмотрел другую структуру решения. Вы хотите избежать ситуации, когда два пользователя обращаются к двум версиям файла одновременно и вносят конфликтующие изменения. Репликация DFS может с этим справиться, но это некрасиво и может потребовать вмешательства администратора. Я предлагаю одно основное место для обмена файлами, реплицированное в другое место для резервного копирования. У вас огромный канал, поэтому, если файлы не большие, он должен работать хорошо. Или в каждом расположении размещены файлы, используемые в основном в этом расположении, и эти файлы реплицируются по сети для резервного копирования.

Репликация DFS довольно хороша, но требует ухода и поддержки и оставляет вас уязвимым для конфликтов обновления. Пользователям придется научиться не оставлять файлы открытыми ... им нужно войти, внести изменения и выйти. Другой альтернативой является использование репликации DFS, но перенос часто используемых файлов в библиотеку документов SharePoint, которая может управлять блокировкой и контролем версий.

Что касается резервного копирования ... Мне нравится магнитная лента .. как минимум для исторических архивов. Репликация снижает риск потери данных из-за отказа оборудования, пожара и т. Д. Таким образом, возникают следующие вопросы:
- Какие сценарии вы пытаетесь смягчить?
- Какое влияние эти сценарии допустимо?
- Сколько можно потратить?

Эти ответы определяют, какие резервные копии следует создавать и как часто, что, в свою очередь, позволяет вам определить, что вам нужно. Решением может быть ленточная библиотека, с диска на диск на ленту, сеть SAN, которая реплицируется каждую ночь, ночное резервное копирование на Amazon S3, Система резервного копирования SunGard, Резервное копирование Iron Mountain Online, какая-то их комбинация или что-то совсем другое.

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

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

Использование одного файлового сервера для совместного использования файлов снижает вероятность конфликта. Канал со скоростью 100 Мбит / с, конечно, не медленный, но в зависимости от размера совместно используемых файлов и частоты доступа пользователи в здании без файлового сервера могут иметь задержки при открытии файлов. Вам нужно будет проверить это и посмотреть. Документы Microsoft Office по каналу 100 Мбит / с не проблема. Файлы твердотельных моделей размером в несколько гигабайт, передаваемые по каналу со скоростью 100 Мбит / с, могут стать источником серьезной боли для пользователей.

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

Репликация DFS защищает вас только от катастрофического отказа / разрушения реплики. Случайное удаление или повреждение данных потребует другого типа защиты. Кроме того, если ваши здания расположены близко друг к другу физически, я бы сказал, что наличие копии в другом здании может быть недостаточной защитой от физических бедствий (пожара, наводнения, кражи и т. Д.). Вам нужно будет оценить риск и действовать соответствующим образом.

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

Вам все равно понадобится какое-то внешнее и автономное резервное копирование (в идеале с возможностью многократного полного обратного хранения). Лента, вероятно, отвечает всем требованиям с точки зрения стоимости / производительности.

Автозагрузчик LTO-4 быстро справился бы с резервным копированием этих данных, если ваши серверные компьютеры могут передавать данные на диск достаточно быстро. Независимо от того, запускаете ли вы полное резервное копирование каждый день, зависит от вашего окна резервного копирования и скорости резервного копирования. Стоимость одной ленты довольно разумна (около 50 долларов, когда я смотрел в прошлый раз), так что вы можете поддерживать ротационный архив старых резервных копий за разумные деньги.

Надеюсь, вы сможете рассчитать время так, чтобы превысить окно резервного копирования или емкость автозагрузчика в конце запланированного срока службы автозагрузчика. При росте на 20% в год ваш объем 2 ТБ должен составить около 3,5 ТБ к концу 3-го года. У 8-слотового автозагрузчика LTO-4 (800 ГБ естественной емкости / 1,6 ТБ сжатой емкости на картридж) все равно будет емкость. Возможно, вам придется перейти к полному / дифференциальному резервному копированию, чтобы по-прежнему соответствовать вашему окну резервного копирования, но кажется возможным получить 3 года работы с автозагрузчиком LTO-4.

Я также согласен с tomjedrz в отношении возможности выполнения преобразования с диска на диск на ленту, если у вас есть частые потребности в выполнении случайных восстановлений (и вы либо не используете теневое копирование тома, либо не получаете защиты, которую вы нужно из него). Что-то простое, например массив недорогих SATA-дисков RAID-0 или RAID-10, может передавать данные в LTO-4 достаточно быстро, чтобы поддерживать его работоспособность, и может служить местом для выполнения быстрых случайных восстановлений без необходимости монтирования. ленты (отправка на внешнее хранилище за кассетами и т. д.).