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


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

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

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

Мой вопрос: Как вы копируете столько данных !?

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

Нужен ли мне бюджет на второй сервер за пределами площадки или есть лучшее решение?


14
2017-10-28 20:15


Источник


Я оставлю свой обычный комментарий о том, что поддержка находится в автономном режиме. Я очень нервничаю по поводу того, что система резервного копирования постоянно «живая и онлайн». Если злоумышленник может получить доступ к вашей производственной системе и вашим резервным копиям, они могут уничтожить ваши резервные копии сразу же после того, как они завершат вашу систему производства. - Evan Anderson
@Evan Спасибо за подсказку. - Andrew Ensley
@Evan Я бы предпочел, чтобы оба, восстановление с ленты может занять много часов, но восстановление с локального или прямого подключения может быть сделано за считанные минуты. - Tom O'Connor
@Tim O'Connor: D2D2T отлично, когда вы можете это получить. Имейте в виду, что восстановление отдельных элементов с диска или лента может быть очень быстрой. Резервное копирование на основе диска имеет репутацию быстрого восстановления, но большинство людей думают «получить доступ к данным непосредственно со СМИ B2D», а не «восстановить их», когда они это скажут. Если вам нужно восстановить несколько ТБ данных из системы резервного копирования на диске, скажем, замены SAN после того, как вы сгорели в результате пожара, это не будет «минут», чтобы скопировать эти данные. Диск и высококачественная лента с точки зрения скорости передачи данных очень похожи. - Evan Anderson


Ответы:


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

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

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

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

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

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


О ленточном архиве ...

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

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


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


13
2017-10-28 22:22



Спасибо за долгий и продуманный ответ. Вы мне много подумали: -p - Andrew Ensley


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

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


9
2017-10-28 20:22



Я не знаком с ленточными системами. Я предполагаю, что нет возможности делать инкрементные резервные копии. Кроме того, не потребовалось бы нескольких часов и потребовалось бы вручную менять ленточные накопители один за другим? Это было бы нецелесообразно, потому что у меня было бы только такое время раз в месяц, и мы действительно не хотим, чтобы данные за месяц были подвержены риску. Я что-то упускаю, или это просто принятые неудобства / риски / ограничения систем резервного копирования на магнитной ленте? - Andrew Ensley
Современные системы резервного копирования на магнитной ленте очень автоматизированы и роботизированы :) - phoebus
Да, ленточные резервные копии обычно позволяют создавать инкрементные резервные копии. Хорошей стратегией резервного копирования является создание полных резервных копий (длинных, медленных, много лент) ежемесячно или два раза в год, а также ежедневное инкрементное или дифференциальное резервное копирование между ними. - Brent
Ленточные роботы по разумной цене и содержат много кассет. Что касается резервных копий, почему бы и нет возможности делать приращения? Наконец, большинство людей запускают резервное копирование для запуска в нерабочее время. Если у вас их нет, это важная часть спецификации. - Slartibartfast
Да, у нас действительно нет времени. У нас есть часы, когда было бы более приемлемым для системы быть недоступным (например, утром в 4 утра в субботу), но затронутые системы будут использоваться 24/7 потенциально сотнями пользователей. - Andrew Ensley


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

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

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

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

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

--added--

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


5
2017-10-28 22:23



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


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

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

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

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

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

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


2
2017-10-29 01:52



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


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


2
2017-10-29 15:38





Вне сайта, он-лайн резервное копирование (удаленное зеркало)

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

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

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

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


1
2017-10-29 03:44



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


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

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


1
2017-10-29 03:53



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