Подходит ли наша запланированная стратегия резервного копирования для моей новой серверной инфраструктуры?

Мой стандартный совет по резервному копированию:

Весь смысл резервного копирования заключается в возможности восстановления. Если вы не уверены, что сможете вернуть свои данные, ваши резервные копии бесполезный. Все, что вы реализуете в своем решении для резервного копирования, должно исходить из точки зрения «как мне восстановить из этого?»

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

Помимо вопроса «сколько данных вы можете позволить себе потерять», вам также необходимо подумать, «как долго вы можете позволить себе простаивать в случае сценария аварийного восстановления»? 3 дня восстановления - это 3 дня потерянного бизнеса. Вы должны считать время восстановления в часах и на пальцах одной руки.

Вы можете очень быстро заработать глупые деньги, если позволите себе слишком параноидально относиться к этому, поэтому вам следует разделить свои серверы на 2 или 3 лота. Те, которые вам абсолютно необходимо вернуть СЕЙЧАС, чтобы продолжить свои основные бизнес-функции, а те, которые вы можете отложить, пока не вернутся основные. Вложите большие инвестиции в первую партию, убедитесь, что у вас есть полностью задокументированные процедуры восстановления (для ОС, для приложений и данных), которые может выполнить слепая прокаженная обезьяна с одной связанной за спиной рукой. Распечатайте, переплетите копию и храните ее в несгораемом сейфе. - вы облажались, если все, что у вас есть, - это электронная копия, которая теряется или уничтожается. Но не думайте, что это означает, что вы можете расслабиться со второй партией, просто вы можете отложить получение их обратно или сделать это немного дольше (например, поместив их на более медленный носитель).

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

Сделайте ваше решение для резервного копирования простым и скучным. Слишком часто я видел, как люди внедряют причудливые или сложные решения для резервного копирования, которые в конечном итоге оказываются слишком сложными, неудобными и ненадежными. Резервные копии скучны, потому что резервные копии должен быть скучным. Чем они проще, тем легче будет их восстановить. Вам нужен подход «я Og, Og click button, Og get data back». Держите там ежедневный ручной элемент. Это помогает установить тренировку, которая поможет избежать ситуаций, когда кто-то забывает сменить ленту или повернуть HD в бассейне. Если это произойдет, вы можете уволить виновного впоследствии, но знаете что? Вы все еще находитесь в положении, когда потеряли данные за месяц.

Ник,

Я настоятельно рекомендую вам взглянуть на книгу «Резервное копирование и восстановление» от O'Reilly.

http://oreilly.com/catalog/9780596102463

Он объяснит вам такие термины, как «единая точка отказа», а также общую стратегию резервного копирования ваших критически важных систем.

Это хорошая книга для любой книжной полки.

b Я сделаю комментарий, который я всегда делаю по поводу «резервного копирования»:

Резервное копирование осуществляется вне офиса и офлайн. Если это не офлайн и офлайн, это не резервная копия.

• Вне участка важен, если здание сгорает. На месте, но не в сети (представьте себе отключенный внешний жесткий диск в ящике), тогда он исчезнет, ​​когда здание сгорит (см. Очистка сервера от сажи ).

• Автономный режим важен, если кто-то атакует вас и пытается испортить ваши данные. Если он находится за пределами сайта, но в сети, он уязвим для атак и «коррупции». Offline означает «воздушный зазор между резервной копией и сетью».

Дао поддержки - это немного дрянная коммерческая подача, но все в сообщении сайта правдиво и важно. Советую прочитать.

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

Вы должны прочитать мою Обзор резервного копирования при сбое сервера электронная таблица, сравнивающая различные решения для резервного копирования. LTO-4 и ленты для 5-недельной ротации не который дорого. Это даже меньше, если вы используете ленточные технологии более низкого уровня, такие как LTO-3, LTO-2 или VXA.

Если вам нужны еще более точные рекомендации по резервному копированию, расскажите нам, например:

• Сколько всего данных будет сохранено
• Сколько данных меняется каждый день
• Как долго длится окно резервного копирования
• Сколько резервных копий вы хотите сохранить
• Сколько резервных копий за период времени вы будете хранить постоянно
• Как часто вы будете чередовать резервные носители за пределами площадки
• Сколько медиа / недель вы хотите менять

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

(Вы можете получить более подробную информацию о предположениях, сделанных в моем документе «Server Fault Backup Roundup» по адресу: Рекомендуемый носитель резервной копии примерно на 2009 год?)

Ключевой вопрос - сколько данных вы готовы потерять? Один месяц? Один день? 6 часов? 5 минут?

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

• Raid предназначен для действующей системы и может / должен содержать локальные резервные копии и / или записываемые снимки состояния.
• Лента ударопрочная для путешествий, выездного резервного копирования. Но лента не поддерживает высокие циклы (в среднем 250 перезаписей).
• Диск дешевле и быстрее, чем лента, и имеет гораздо более высокую возможность перезаписи.

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

Другой вариант - купить 5-1 терабайт внешних sata-накопителей по 90 долларов каждый - общая стоимость 450 долларов.

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

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

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

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

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

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

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

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

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

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

Не по теме: Как оказалось, я ищу аналогичную инфраструктуру для нашей небольшой компании. Аналогичный уровень опыта, хотя у нас уже есть резервные копии. Я поделюсь с вами нашим текущим дизайном, чтобы дать вам альтернативную перспективу, а не осуждать вашу:
Мы планируем три сервера: два хоста виртуализации и один сервер хранения. Сервер хранения, скорее всего, будет работать Openfiler. Он будет подключен через (возможно, двойной) гигабитный Ethernet к двум хостам, оба с хорошими процессорами и большим количеством памяти, но почти без хранилища (возможно, только с небольшими SSD). На этих хостах будет работать Citrix Xenserver (или, может быть, VMWare ESXi) на оголенный метал, потому что это намного эффективнее, чем запуск программного обеспечения виртуализации в другой операционной системе, которая в основном не делает много (например, посмотрите различия в производительности между VMWare Server и VMWare ESXi). Xenserver кажется наиболее интересным, поскольку он предоставляет корпоративные функции бесплатно, в то время как ESXi может стать дорогим, если вам нужно больше, чем базовые. Хосты Xenserver не будут иметь хранилища сами по себе, но будут использовать хранилище на уровне блоков через iSCSI с сервера Openfiler как виртуальные жесткие диски. Openfiler может делать снимки, RAID и так далее. Xenserver может выполнять живую миграцию виртуальных машин с одного сервера на другой, поэтому мы можем выполнять обслуживание одного сервера, не выключая гостевые виртуальные машины. Получите гигабитный коммутатор, поддерживающий VLAN, чтобы вы могли отделить трафик хранилища от трафика виртуальной машины. Несколько ИБП для контролируемого отключения в случае сбоя питания, и все готово. Почти вся стоимость идет на оборудование, поскольку программное обеспечение (на удивление) бесплатное.

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

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

... Джо, что ты имеешь в виду под живой системой? Производственные серверы?

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

... Итак, в описываемом вами варианте план следующий: ведение журнала на каждой рабочей станции общедоступных данных (зашифрованных).

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

Шифрование - на случай кражи рабочей станции и / или для защиты от «посторонних глаз». У нас есть хорошие разработчики, поэтому вы можете доверять им, чтобы они не пытались расшифровать. Они могут нанести ущерб бизнесу многими другими способами, требуется доверие.

... Эти снимки ежедневно попадают в систему с 5 внешними дисками или снимаются ежедневно на одном из 5 дисков?

Дорожные данные всегда на ленте. Лента выдерживает шок. Диск быстрее ищет, поэтому мы предпочитаем диски в качестве «журнальной» резервной копии. Ленты - это полные или инкрементные резервные копии, обычно без журналов / снимков. Большая часть восстановления данных будет выполняться в течение дня - для нашей пользовательской базы. «Мне нужен файл в том виде, в каком он был до обеда». «Я только что удалил не тот файл». Детализации восстановления с предыдущих дней обычно достаточно для одной версии в день. Если требуется дополнительное ведение журнала, выполняется корректировка резервного копирования или внедрение системы контроля версий и выполняется резервное копирование дерева изменений.

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

В установленный момент данные переносятся с журналируемого раздела резервного копирования производственных серверов и перемещаются в систему резервного копирования с подключенным внешним диском (дисками), создавая 2-5 копий, одну на внутреннем диске, одну на внешнем диске и на ленту. Рабочие станции копируются в системы резервного копирования, затем получают копию резервной копии общей производственной системы перед выключением каждой рабочей станции. Никогда не может быть меньше трех физических копий резервных копий данных. 3 копии, 5 копий и т. Д. - это вопрос избыточности, который необходимо смоделировать для каждого бизнеса и каждого типа данных. Вам может понадобиться 5 копий счетов-фактур, 7 копий контрактов, только 2 копии стандартной графики и одна копия исполняемых файлов текущей тестовой сборки и т. Д.

... Кроме того, одинаковые снимки на каждой рабочей станции? или все они суммируют полные общедоступные данные?

Либо. Зависит от доступного места и потребностей. Наши приобретенные системы всегда поставляются с дисками, которые намного больше, чем требуется для обычного пользователя (разработчики могут использовать дополнительное пространство, но регистратору не нужен диск 500 ГБ +)

... Что вы думаете о таких внешних концентраторах хранения, как linksysbycisco.com/US/en/…?

Не знаю. Мы предпочитаем машины, которые можно использовать для других целей, сервер резервного копирования сегодня, чья-то рабочая станция завтра, разгрузка копий виртуальных машин во время серьезного обновления для быстрого переключения при отказе и т. Д. Это одна из причин использования внешнего диска - чтобы все рабочие станции оставались одинаковыми. насколько возможно. Следовательно, на «сервере резервного копирования» будет тот же диск 500 ГБ +, что и на каждой рабочей станции. Это одна и та же физическая машина, приобретаемая наборами, поэтому со временем будут различия в ЦП, памяти и диске в зависимости от условий сделки. Машины распределяются на основе требований к производительности, и замена новой машины для увеличения памяти занимает меньше общего времени системного администратора, чем установка микросхемы памяти на отлично работающей машине. Если мы сохраним относительно постоянную замену ЦП и видео (AMD64, Nvidia), замена машин будет безболезненной.

В производственном сервере используются две рейд-карты: одна работает с SCSI со скоростью 10 тыс. Об / мин, а другая с дисками с частотой вращения 7200 об / мин для максимальной производительности. Терабайтный диск SATA за 60 долларов, используемый для резервного копирования, вмещает диски scsi, raid-контроллеры, стойки для горячей замены и т. Д. На тысячи долларов. Серверы разработки обычно подходят для SATA raid, больше места, но меньше производительности. Поскольку одновременных пользователей меньше, разница в производительности обычно незначительна.

Проще говоря -

1. Производственная система - активные общие данные и ОС на рейде «первичный раздел данных»
2. Производственная система - ежечасно журналируемые моментальные снимки с момента последнего резервного копирования на рейде «раздел резервных данных»
3. Система рабочей станции - активные данные и ОС на «основном разделе данных» без рейдов.
4. Система рабочей станции - резервное копирование данных на нерейдовый «раздел резервных данных»

Обычные рабочие станции, приобретенные с дисками 500 ГБ + и использующие максимум ~ 40 ГБ для мультизагрузочных разделов Windows / linux / bsd / opensolaris. Остальное - это раздел резервного копирования, который содержит резервные копии операционных систем каждой другой рабочей станции, резервную копию операционной системы рабочего сервера, журналируемые резервные копии данных производственных серверов и / или дополнительные резервные копии данных производственных серверов.

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

Мы можем потерять систему рейдов, ленту и две рабочие станции, не потерять никаких данных и начать работу в течение нескольких минут. (правда, без рейда, пока не починит) Но данные доступны "мгновенно". Это сэкономило часы времени во время сбоя, который всегда, кажется, случается в самое неподходящее рабочее время. Источники питания неизменно выходят из строя прямо перед важной встречей / демонстрацией продаж. Кажется, что рейдовые системы всегда выходят из строя утром, а не вечером в пятницу, поэтому вы можете исправить их и вернуться к работе к утру понедельника.

Документы, описывающие процесс резервного копирования, являются собственностью компании. Я постараюсь переписать для публичного просмотра с диаграммами и вариантами использования. Я использую эту общую методологию уже много лет, и она позволяет сэкономить время и данные, когда стандартные системы только с магнитной лентой выходят из строя. Я видел сбои в системах IBM, Compaq, HP и Dell, использующих DLT, LTO и т. Д. Обычный сбой - отсутствие ошибок во время резервного копирования, но при попытке восстановления данные повреждены. Всегда проверяйте восстановление. Это одна из причин, почему мы используем резервную копию онлайн-журнала, которую можно легко тестировать ежедневно. С тех пор, как пользователи привыкли к этому, мы никогда не проводили больше недели, чтобы кто-нибудь не использовал журналируемые резервные копии, и почти никогда не использовали ленты. Ленты на случай возгорания дома.