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

My standard backup advice:

The whole point of backing up is to be able to restore. Unless you're fully confident that you can get your stuff back, your backups are useless. Everything you implement in your backup solution should be coming from the perspective of "how do I restore from this?"

Tape isn't that expensive, and it has the advantage that it's far more durable than disk. Less moving parts, no live electrical current going through it on a constant basis, all good stuff. If it saves your ass once then it's already paid for itself in my book.

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

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

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

Сделайте свое решение для резервного копирования простым и скучным. Слишком часто я видел, как люди внедряют необычные или сложные решения для резервного копирования, которые просто оказываются слишком сложными, надежными и ненадежными. Резервные копии скучны, потому что они должны быть скучными. Чем они проще, тем легче будет восстановить. Вы хотите подход "Я, ОГ, О, нажмите кнопку, О, верните данные". Держите ежедневный ручной элемент там. Это помогает установить детализацию, которая может избежать ситуаций, когда кто-то забудет сменить ленту или повернуть HD в пуле. После этого вы можете уволить ответственного за это, но угадайте, что? Вы все еще в состоянии, когда вы потеряли месяц данных.

Ник,

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

http://oreilly.com/catalog/9780596102463

http://oreilly.com/catalog/9780596102463

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

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

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

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

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

Резервное копирование вне сайта и в автономном режиме. Если это не за пределами сайта и в автономном режиме, это не резервное копирование.

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

• Оффлайн важен, если кто-то атакует вас и пытается испортить ваши данные. Если это вне сайта, но онлайн, то он уязвим для атак и "коррупции". Офлайн означает "воздушный зазор между резервной копией и сетью".

Дао Бэкапа - небольшая пустяковая коммерческая подача, но все в сообщении сайта верно и важно. Я бы посоветовал прочитать это.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would suggest running the fileserver on a physical box, since it's likely to be quite I/O heavy. It would also be nice to be able to hotswap a dead drive, without powering down all VM's. This depends on your specific setup though.

Your backup schedule sounds reasonable, but depends on how much you can afford to lose. It looks like most of your backups (except the monthly one) are on-site, which means you'll lose at most a month if the building burns down, or is broken into.

If you take the external drive home, you'll have to keep it home, until right before the backup is due, otherwise it's not really an off-site backup, is it? If you're disciplined about it, you'll lose at most a week. Better would be to rotate a set of three external harddisks, so you'll always have the oldest one on-site, and the newest one off-site.

Don't forget to test and document your backups periodically; You need the peace of mind that each of your backup systems can restore correctly. You'll need documentation so one of your colleagues can restore data. You'll also need documentation on how to rebuild an entire server. If one fails, you'll have too much on your mind to remember every detail.

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

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