Бекап ОГРОМНОГО кол-ва данных

[metallic]

Имеется в хозяйстве:
Две СХД IBM Storwize V7000
Два сервера, подключенных к этим СХД через FC 8Gbit (каждый к своей хранилке)
Сервера работают в качестве файловых серверов samba, ОС redhat 6.
Каждый сервер подключен к своей хранилке.
Сервер1 имеет 92ТБ раздел.
Сервер2 имеет 92ТБ раздел и 23ТБ раздел.
У всех трех разделов ФС XFS.
Итого общий объем данных, которые нужно бекапить более 200ТБ

Как выполнять резервное копирование такого объема данных и главное какими средствами?

Сейчас резервное копирование выполняется с помощью ленточных библиотек LTO5 и LTO6 и программы bacula(данные пишутся по сети). Практика показала, что такое решение не жизнеспособно по нескольким причинам:
- время полного резервного копирования занимает около 3х недель
- второй пункт вытекает из первого, за 3 недели может случиться что угодно, отключение света, любой другой глюк и т.д. Почти не разу не удавалось записать бекап с первого раза
- не возможно продолжить бекап после прерывания, приходиться запускать заново
- все же ленточные библиотеки не предназначены для таких задач, судя по всему, такие объемы данных для них максимум слить данные в архив, но не бекапить постоянно, т.к. довольно часто ловлю глюки, то с приводами, то с роботом и бекап прерывается
- исходя из вышеперечисленного, в случае необходимости отката из бекапа, потеря составит не менее месяца, что не круто

В общем ищется альтернативное решение, более скоростное, более надежное(без застрявших картиджей в роботе и приводов, которые постоянно требуют чистки). Что можно придумать?

Мой вариант:
Собрать еще один сторвайз на 4ТБ дисках, объемом около 500ТБ, нарезать на куски по 92ТБ и 23ТБ и раздать их серверам(по FC), на них и бекапить. Только возникает вопрос, каким образом на горячую скопировать данные с одного раздела на другой? rsync? dd? тупо cp? или еще как?

В общем подкиньте идей для решения задачи.

[gs]

А смотрели, в чем тормоза?

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

[digitalm]

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

[metallic]

А смотрели, в чем тормоза?

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

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

Предлагаете делать снапшет на уровне сторвайза и монтировать его на сервер бекапов? Не получится по нескольким причинам:
- снапшет требует места, да и не продавит он производительность сторвайза? В линуксе, например, когда с LVM снимаешь снапшет, производительность дико падает, пока не удалишь снапшет
- и главная проблема: я недосказал, на самом деле 92ТБ раздел серверу от сторвайза отдается не одним луном, а несколькими(12шт) по 7.6ТБ, т.е. по одной рейд-группе, а уже на уровне сервера эти 12 рейд-групп собираются в один кусок с помощью LVM(страйп) для увеличения производительности

А в качестве носителя можно аппарат и попроще - V3700

А он нужное кол-во дисков даст? По-моему, нет? По моим подсчетам 168 шпинделей по 4Тб надо

или даже инфортренд.

Не в курсе что за зверь, не подкинете ссылок на варианты поглядеть

Бэкапить такие объемы, наверное, бессмысленное занятие. Тут надо иметь избыточное хранилище (failover) для каждого сервера

Дублирование сторвайзов не избавит от таких проблем как:
- логический обвал ФС
- случайное/умышленное удаление данных
- ну и глюки самого сторвайза, которых в нем еще вычищать и вычищать
В общем я б не стал хранить все яйца в одной корзине и называть это бекапом

файловую систему со снапшотами (zfs).

ZFS только для соляры и фряхи, ни первое, ни второе официально на серверах ИБМ не поддерживается, а всякие костыли типа zfs on linux не предлагать

[metallic]

Похоже что-то вроде Infortrend EonStor DS S12F G2850/R2850 может подойти
Могли бы сконфигурить со 192 дисками 3ТБ и скинуть(цену) ?

[gs]

Инфортренд я имел в виду такой: http://www.infortrend.com/us/products/m ... DS%203060R
Железки весьма приличные, диски из магазина (HCL широкий), но сервис только партнерский.

Щас посчитаем и еще подумаем над схемой.

[gs]

Да, у V3700 только 120 дисков.

[gs]

Ловите спецификации на профильное мыло.

[Bormoto]

Может быть, проще, в стиле "каменного века" - 2 сервера (исходя из количества серверов с данными - распараллелить копирование и одновременно для резерва) СРК на базе обычной супермикры, каждый с каскадом из корпусов с JBOD? Все соединить по 10 Gbit и вдумчиво разделить нагрузку от источников?

[metallic]

Ловите спецификации на профильное мыло.

Спасибо, жду еще конфиг на 6ТБ

Может быть, проще, в стиле "каменного века" - 2 сервера (исходя из количества серверов с данными - распараллелить копирование и одновременно для резерва) СРК на базе обычной супермикры, каждый с каскадом из корпусов с JBOD? Все соединить по 10 Gbit и вдумчиво разделить нагрузку от источников?

Не хотелось бы строить городульки и костыли.
Раз уже заложен фундамент FC сети(два свитча), надо его и развивать.

А по поводу софта, подсказали xfsdump, сейчас щупаю

[metallic]

Прикинул тут, получается 120 дисков по 6Тб самый оптимальный вариант:
это 15 рейд-групп по 8 дисков (рейд 6), в каждой рейд-группе из 8 дисков 6 дисков под данные, 2 диска под парити. Итого одна рейд-группа 5,5 * 6 = 33ТБ
15 * 33 = 495ТБ, как раз то, что мне нужно

Теперь самое интересное, эта хранилка как отдает массивы хостам? Это просто молотилка, тика как ибм 3512/3524, которая отдает рейд-группы? Или она имеет какую-то логическую прослойку и менеджер логических томов, типа сторвайза?

В принципе мне менеджер томов не нужен, если эта хранилка поддерживает рейд 60, как указано в спеке. Если я могу собрать рейд 60 из 24 дисков с 8ми дисковыми группами, то это получается раздел 99ТБ, как раз.
Итого
4 раздела(4 рейд 60 по 24 диска) по 99ТБ (два для одного сервера и два для второго)
2 раздела(2 рейд 6 по 8 дисков) по 33ТБ(один для одного сервера и один для второго)
и еще один раздел 33ТБ остается прозапас

Главный вопрос, как эта хранилка отдает диски хостам и можно ли собрать рейд 60 из 24х дисков(рейд 0 поверх трех рейд 6 из 8 дисков)

[gs]

Вопрос перешел в оффлайн.

[sivanov]

А ОП пробовал amanda и функцию RAIT (подразумевая, что несколько приводов LTO)? В конфигурациях RAIT аманда будет писать поток на несколько приводов одновременно, также повышая надежность хранения.

[metallic]

Вопрос перешел в оффлайн.

Запросил еще две конфигурации, посчитайте пожалуйста.

А ОП пробовал amanda и функцию RAIT (подразумевая, что несколько приводов LTO)? В конфигурациях RAIT аманда будет писать поток на несколько приводов одновременно, также повышая надежность хранения.

Нет, не пробовал, но боюсь, что с надженостью лент и моими объемами данных, запись на несколько приводов одновременно только добавит проблем, а не решит их.
По поводу технического решения уже определились: СХД + xfsdump

Кстати еще говорили про супермикро сервер с полками дисков по 90шт, а каким образом по FC отдавать массивы нодам? Разве linux умеет выполнять ф-ию СХД и отдавать по FC имеющиемя у него массивы, как блочные устройства?

[maverlife]

Кстати еще говорили про супермикро сервер с полками дисков по 90шт, а каким образом по FC отдавать массивы нодам? Разве linux умеет выполнять ф-ию СХД и отдавать по FC имеющиемя у него массивы, как блочные устройства?

например https://www.openfiler.com/products/open ... target-faq