Как вы делаете резервную копию сервера хранения?

14

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

Под очень большим я имею в виду доступное пространство от 4 ТБ до 20 ТБ (хотя маловероятно, что мы фактически сделаем это 20 ТБ).

Сервер хранения будет RAID 10 для обеспечения безопасности и производительности данных, но нам все равно понадобится решение для резервного копирования, в том числе резервное копирование вне сайта.

Мой вопрос: как вы делаете резервную копию такого количества данных?

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

Нужно ли выделять бюджет на второй сервер хранения вне сайта или есть лучшее решение?

backup raid storage network-attached-storage Эндрю Энсли
источник
5
Я оставлю свой обычный комментарий о поддержке в автономном режиме. Я очень нервничаю из-за того, что система резервного копирования постоянно работает. Если злоумышленник может получить доступ к вашей производственной системе и вашим резервным копиям, он может уничтожить ваши резервные копии сразу после того, как они закончат уничтожать вашу производственную систему.
Эван Андерсон
@Evan Я бы предпочел оба варианта: восстановление с ленты может занять много часов, но восстановление с локального или напрямую подключенного диска может быть выполнено за считанные минуты.
Том О'Коннор
@ Тим О'Коннор: D2D2T великолепен, когда ты можешь его получить. Имейте в виду, что восстановление отдельных элементов с диска или ленты может быть очень быстрым. Дисковое резервное копирование имеет репутацию быстрого восстановления, но большинство людей думают «получить доступ к данным напрямую с носителя B2D», а не «восстанавливать», когда говорят это. Если вам нужно восстановить пару ТБ данных из дисковой системы резервного копирования, скажем, в замененную сеть SAN после того, как ваша система сгорела при пожаре, копирование этих данных не займет «минут». Диск и высокопроизводительная лента по скорости передачи данных очень похожи.
Эван Андерсон

Ответы:

13

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

  • Через Ethernet Как указано на коробке, данные передаются в Some Where Else для обработки. 20TB займет много времени, чтобы скопировать 1GbE, но это можно сделать. Может помочь оборудование (например, ссылки 10GbE или, в некоторых случаях, соединение NIC).
  • Через подсистему хранения Если вы находитесь на Fibre Channel, отправьте его на другое устройство в сети FC. Если у вас есть SAS, отправьте его на устройство, подключенное к SAS. Как правило, быстрее, чем Ethernet.
  • Отправьте его на другой дисковый массив. Отправьте его другому хранилищу, подключенному к тому же серверу.

Это вид на 100 км. Как только вы начинаете увеличивать масштаб, все становится более фрагментированным. Как уже упоминалось, LTO5 - это специальная ленточная технология, разработанная для таких нагрузок высокой плотности. Другой идентичный массив хранения - хорошая цель, особенно если вы можете использовать что-то вроде GlusterFS или DRBD для получения данных там. Кроме того, если вам понадобится резервное чередование или просто возможность продолжить работу в случае сбоя массива, это повлияет на то, что вы поставили на место.

Как только вы остановитесь на методе просмотра 100 км, следующей большой задачей станет внедрение программного обеспечения. Факторы, влияющие на это, - это то, что вы можете установить на свой сервер хранения в первую очередь (если это NetApp, это одно, а сервер Linux с кучей хранилищ - это совсем другое, как сервер Windows с кучей хранилищ) какое оборудование вы выберете (например, не все пакеты резервного копирования FOSS хорошо справляются с ленточными библиотеками) и какое хранилище вам требуется.

Вы действительно должны выяснить, какого рода аварийное восстановление вы хотите. Простая живая репликация проще, но не позволяет вам восстановить данные с прошлой недели только сейчас. Если для вас важна возможность восстановления с прошлой недели, то вам нужно спроектировать для такого рода вещи. По закону (в США и других странах) некоторые данные должны храниться в течение 7+ лет.

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

О резервном копировании на ленту ...

LTO5 может хранить 1,5 ТБ данных без сжатия. Кормление этих монстров требует очень быстрой работы в сети, то есть Fibre Channel или 6Gb SAS. Так как вам нужно сделать резервную копию более 1,5 ТБ, вам нужно взглянуть на автозагрузчики (вот пример: ссылка , 24-слотовый 1-дисковый автозагрузчик от HP). С программным обеспечением, которое их поддерживает, они будут обрабатывать сменные ленты в процессе резервного копирования. Они великолепны. Вам все равно придется извлекать ленты, чтобы отправлять их за пределы площадки, но это чертовски лучше, чем торчать всю ночь, чтобы загружать ленты самостоятельно, когда резервная копия требует их.

Если лента дает вам « наследство », виртуальная ленточная библиотека может быть более быстрой (например, из Quantum: ссылка ). Они претендуют на то, чтобы быть ленточными библиотеками для резервного копирования программного обеспечения, в то же время фактически сохраняя данные на диск с помощью надежных (как вы надеетесь) методов дедупликации. Любители даже копируют виртуальные ленты на реальные для вас, если вам нравятся такие вещи, которые могут быть очень полезны для ротации за пределами площадки.

Если вы не хотите копаться даже с виртуальными лентами, но по-прежнему хотите выполнять прямое резервное копирование на диск, вам понадобится массив хранения, достаточно большой для обработки этих 20 ТБ, плюс столько данных о сетевых изменениях, сколько вам нужно держать в руках. Различные пакеты резервного копирования обрабатывают это по-разному. Некоторые технологии дедупликации действительно хороши, другие - хакеры. Лично я не знаю состояния пакетов ПО для резервного копирования FOSS в этой области (я слышал о Bacula), но их может быть достаточно. Во многих коммерческих пакетах резервного копирования есть локальные агенты, которые вы устанавливаете на серверах для резервного копирования, чтобы увеличить пропускную способность, что имеет много достоинств.

sysadmin1138
источник
Спасибо за длинный и продуманный ответ. Вы дали мне много задуматься :-p
Эндрю Энсли
9

Музыкальный автомат LTO-5? вам понадобится где-то от трех до 15 лент для резервного копирования этого массива, а это не слишком большое количество. Музыкальный автомат позаботится о смене лент для вас, а хорошее программное обеспечение для резервного копирования (например, bacula) будет отслеживать, какие файлы на какой ленте находятся.

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

Безумный Шляпник
источник
1
Я не знаком с ленточными системами. Я предполагаю, что нет никакого способа сделать инкрементные резервные копии. Кроме того, не займет ли это несколько часов и потребует ли ручная замена ленточных накопителей один за другим? Это не было бы идеально, потому что у меня было бы такое время только один раз в месяц, и мы действительно не хотим подвергать риску данные за месяц. Я что-то упустил, или это просто признанные неудобства / риски / ограничения систем резервного копирования на магнитную ленту?
Эндрю Энсли
4
Современные системы резервного копирования на магнитную ленту являются высоко автоматизированными и роботизированными :)
Феб
3
Да, резервные копии на лентах обычно допускают инкрементные резервные копии. Хорошая стратегия резервного копирования - делать полные резервные копии (длинные, медленные, много лент) ежемесячно или раз в два года, а также делать ежедневные инкрементные или дифференциальные резервные копии между ними.
Брент
Ленточные роботы по разумной цене и содержат много лент. Что касается создания резервных копий, почему не было бы способа сделать инкрементные копии? Наконец, большинство людей запускают резервное копирование в нерабочее время. Если у вас их нет, это важная часть спецификации.
Slartibartfast
Да, у нас действительно нет выходных. У нас есть часы, когда было бы более приемлемо, чтобы система была недоступна (например, в 4 часа утра в субботу), но затронутые системы будут использоваться круглосуточно потенциально сотнями пользователей.
Эндрю Энсли
5

Вероятно, вам стоит подумать о резервном копировании на диск , поскольку запись на ленту займет много времени, а при последовательном доступе восстановление займет вечность.

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

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

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

Всегда думайте о процедуре восстановления . Однажды нас задело, когда нам пришлось восстанавливать файл из задания резервного копирования объемом в несколько сотен гигабайт, что занимало много памяти и много времени для восстановления индекса резервного копирования и восстановления. В конце концов, мы не смогли завершить его за один день, и нам пришлось построить выделенный сервер восстановления, чтобы наш основной сервер резервного копирования мог продолжать работу в ночное время!

--added--

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

казарка
источник
+1 за thinking about the restore procedure. Аминь!
Стивен Понедельник
Много отличных советов. Благодарю. У меня много мыслей, чтобы сделать.
Эндрю Энсли
2
Я бы хотел проголосовать, но я не вижу упоминания ленты. Лента, скорее всего, станет важной частью режима резервного копирования для такого количества данных, если потребуется какое-либо существенное окно хранения в сочетании с внешним хранилищем. Стоимость картриджей LTO-5 для длительного хранения вне площадки по сравнению со съемными жесткими дисками делает их очень привлекательными. Ленточные картриджи также предназначены для архивного хранения, тогда как съемные жесткие диски, как правило, нет.
Эван Андерсон
@Evan: Чтобы быть справедливым, он упомянул ленты в самом первом предложении.
Эндрю Энсли
2

Сначала перечислите риски, от которых вы защищаете. Некоторые общие риски:

  • Бедствие: что-то очень неприятное случается со всем вашим сайтом.
  • Человеческие ошибки (это то, что происходит _all_the_time_):
    • Кто-то решает использовать «горячую» замену вашего сервера хранения так, как это не предусмотрено производителем.
    • Кто-то запускает процесс, который незаметно повреждает данные, надежное резервное копирование которых выполняется в течение нескольких месяцев, прежде чем проблема будет обнаружена.
    • Кто-то удаляет важный отчет, который должен быть опубликован через час и стоит тысячи долларов.

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

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

Затем оцените стратегии ротации (насколько далеко вы хотите восстановить, сколько данных вы можете позволить себе потерять).

Затем выберите, что ваши данные стоит.

Слартибартфаст
источник
Приятно сломаться. Я уже оценил это по большей части и попал в автономный вариант резервного копирования онлайн. Целью резервного копирования главным образом является защита от стихийного бедствия в дополнение к очевидной человеческой ошибке. Стойка расположена в 2 милях от побережья залива, поэтому ураганы вызывают беспокойство. Мы просто должны сделать все возможное, чтобы защитить от ошибок человека с частыми проверками целостности. Ваш ответ помог мне почувствовать себя лучше в связи с этим выводом. Благодарю.
Эндрю Энсли
Я рад, что смог помочь. Некоторые комментарии относительно выбранного вами решения: Это может быть само собой разумеющимся, но сайт резервного копирования, вероятно, должен находиться в другом состоянии или в месте, хорошо защищенном от ураганов, которым вы подвержены. Вы можете смягчить проблемы коррупции, имея длинный «хвост» (резервные копии из большого числа дат в прошлом). При резервном копировании в онлайн-хранилище вы также должны учитывать опасность случайного удаления данных вместо их восстановления. Наконец, всегда проверяйте процесс восстановления.
Slartibartfast
2

У меня есть клиент с двумя аналогичными системами по 12 ТБ в двух разных зданиях, подключенных по 1 ГБ. Одним из них является производственная система; резервное копирование выполняется постепенно (с ежедневными снимками) в другую с помощью великолепной утилиты rdiff-backup . rdiff-backup должен быть доступен в вашем стандартном репозитории.

wazoox
источник
1

Автономное резервное копирование в режиме онлайн (удаленное зеркало)

используйте rsync, хотя ssh (только изменения) - первое резервное копирование должно быть сделано локально, но после этого резервное копирование будет быстрым в зависимости от изменений

если вам нужно сохранить версии с изменениями - rdiff-backup

http://www.nongnu.org/rdiff-backup/

Файловая система btrfs в Linux звучит многообещающе, но все еще находится в стадии разработки

реактивный самолет
источник
Спасибо, что указал мне на rdiff. Я уже использую rsync, и это выглядит как идеальный шаг вперед по сравнению с этим.
Эндрю Энсли
1

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

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

SpacemanSpiff
источник
Система будет использоваться тысячами, возможно, десятками тысяч пользователей, ежедневно вводящих формы и обновляющих информацию. Это очень динамичные данные. Я должен был упомянуть об этом в вопросе.
Эндрю Энсли
Если бы это был я, я бы спроектировал систему с достаточным объемом служебной информации или возможностью создания моментальных снимков, чтобы мне не пришлось бы переходить к настоящим резервным копиям, если это не катастрофа.
SpacemanSpiff
Я согласен. Как я уже говорил ранее, диски будут в RAID 10, так что мы находимся в случае сбоя жесткого диска, и у меня также будут локальные резервные копии / снимки. Автономное резервное копирование предназначено для наихудшего сценария, например, если метеор попадет в соседнее местоположение или кто-то случайно запустит команду rm -rf / * на сервере хранения.
Эндрю Энсли
Ну, я имел в виду накладные расходы в отношении емкости. Разумеется, RAID10 хорош для лучшей избыточности, но я бы взял RAID6, если бы производительность не была такой уж большой потребностью, и если бы я мог использовать дополнительное пространство для большей области снимков. Чем больше снимков вы можете себе позволить, тем меньше вам потребуется «резервное копирование» для восстановления файлов.
SpacemanSpiff