Выбор решения под бэкап

[dcvl]

База MSSQL объёмом 20ГБ, рост 10 ГБ в год. текущие средства бэкапа - архив через скул менеджер и потом по расписанию на "бэкап" (файлопомойка) сервер не устраивает. Бэкапить надо минима два раза в световой день и ещё разок вечером. Скорость восстановления важна, но без фанатизма, т.е. простой до 4 часов допустим, более - уже скорее "нет" чем "да". Есть две мысли - сервер с большим количеством сата дисков, и ленточка. На примете msl 2024 LTO3 Ultrium 920 Tape Library и какой нибудь вариант типа супермикры на 12 саташников 2ТБ. Подскажите какой вариант из этих двух более приемлем. Или же из предложенных вариантов ваще ничего не катит и есть что то другое - мега-решение про которое я не знаю
Да. Бюджет - до 300 000 включительно.

PS.:Было бы совсем круто если бы хотя бы в общих чертах описали как налажен бэкап бизнес критикал БД в серьёзных конторах - всё таки чует одно место что к этому всё идёт.

Спасибо!

[Ziggy Stardust]

Начну с конца.

Было бы совсем круто если бы хотя бы в общих чертах описали как налажен бэкап бизнес критикал БД в серьёзных конторах - всё таки чует одно место что к этому всё идёт.

Как правило строят 2-х уровневую схему РКиВД (иногда ее называют схемой Disc-to-Disc-to-Tape). Отдельно ставить сервер управления РКиВД с соответствующим требованиям софтом, к нему же подключаются все необходимые устройства хранения - локальные диски, внешние СХД, ленточные библиотеки и т.д.

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

База MSSQL объёмом 20ГБ, рост 10 ГБ в год. текущие средства бэкапа - архив через скул менеджер и потом по расписанию на "бэкап" (файлопомойка) сервер не устраивает. Бэкапить надо минима два раза в световой день и ещё разок вечером.

Вообще бэкап СУБД это практически отдельная религия :-) Вариантов масса. Как вариант можно делать полный бэкап до начала раб. дня, а в течении дня, например, ежечасно бэкап логов.

Теперь по железу.

В течении часа пришлю вам в почту вариант сервера на 12 дисков по 2 Тб и пару вариантов ленточек. Тут вы зря на LTO3 смотрите, это уже сильно устаревший стандарт. Сейчас актуальный - LTO5. Ленточки могут быть как в виде просто привода (типа как дисковод, только с картриджем) без всякой автоматизации и с ручной заменой картриджей. А могут быть в виде роботизированных библиотек с 1 или более приводом и с автоматизацией замены картриджей (что дает возможность задавать различные политики по автоматической ротации и т.д.)

Так же следует еще принимать во внимание то на какой софт управления РКиВД расчитываете. Есть уже что на примете?

[dcvl]

Спасибо за ответ!
По поводу софта ещё не думал, честно говоря хотелось бы обойтись малой кровью - либо встроенным в винду (2008р2) сервисом (наследник ntbackup), либо опенсорсной разработкой. Пока что всё сводилось к встроенным средствам, но если стоимость решения уложится в бюджет - почему нет
Спасибо за разъяснение по поводу библиотек т.е. я правильно понимаю, что бэкап фактически мигрирует с одного типа носителя на другой ради надёжности? И ещё тогда вопрос - если на всю систему денег не хватит, - ну нет пока таких объёмов, тогда можно сделать первый шаг - сервер с кучей дисков для скоростного бэкапа, и потом по мере необходимости и роста критичности данных - докупать ленточку? направление мысли верное?
Опять таки волнует скорость бэкапа и восстановления в сравнении этих двух систем, в тех же MSL заявлено 864 GB/hr (ну как я понимаю это маркетологи вытащили максимальные расчётные цифры, в реальности слабо верится в 14.4 ГБ в минуту), а в файловом варианте думаю 100-110МБ\с более реально получить - т.е. фактически быстрее получится?
И ещё вопросик - как с надёжностью? Ребилд массива из 12*2ТБ дисков не самое быстрое занятие в случае чего....а в этом случае вся система хранения бэкапа ставится под угрозу. С другой стороны допустимый ли это уровень надёжности при таких затратах?

[Ziggy Stardust]

По поводу софта ещё не думал, честно говоря хотелось бы обойтись малой кровью - либо встроенным в винду (2008р2) сервисом (наследник ntbackup), либо опенсорсной разработкой. Пока что всё сводилось к встроенным средствам, но если стоимость решения уложится в бюджет - почему нет :)

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

Посмотреть можно на MS Data Protector или на Symantec BackUp Exec.

Спасибо за разъяснение по поводу библиотек :up: т.е. я правильно понимаю, что бэкап фактически мигрирует с одного типа носителя на другой ради надёжности?

Да, для резервирования хранимых копий и для архива копий.

И ещё тогда вопрос - если на всю систему денег не хватит, - ну нет пока таких объёмов, тогда можно сделать первый шаг - сервер с кучей дисков для скоростного бэкапа, и потом по мере необходимости и роста критичности данных - докупать ленточку? направление мысли верное?

Да, вполне правильное направление.

Правило №1 построения системы РК: любое резервное копирование лучше, чем совсем его полное отсутствие. :-)

Опять таки волнует скорость бэкапа и восстановления в сравнении этих двух систем, в тех же MSL заявлено 864 GB/hr (ну как я понимаю это маркетологи вытащили максимальные расчётные цифры, в реальности слабо верится в 14.4 ГБ в минуту), а в файловом варианте думаю 100-110МБ\с более реально получить - т.е. фактически быстрее получится?

Тут еще будет сеть ограничения накладывать. Общение между серверов управления РКиВД и сервером непосредственно СУБД будет ведь по LAN происходить.

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

Чтобы совсем минимизировать время восстановления работы сервиса, можно еще посмотреть в сторону 2-го сервера СУБД и настройки репликации средствами MS SQL. Тогда у вас в случае аварии на основном сервере время переключения на зеркальный буквально минуты будет занимать, а основной потом уже можно будет вдумчиво и неторопясь обследовать и восстановить.

И ещё вопросик - как с надёжностью? Ребилд массива из 12*2ТБ дисков не самое быстрое занятие в случае чего....а в этом случае вся система хранения бэкапа ставится под угрозу.

Под РК лучше массив собирать в 6-ой рейд, чтобы выход из строя одного диска не ставил весь массив в совсем плохое положение. И обязательно хот-спейр оставлять. Т.е. при 12 дисках реальный полезный объем из 9 будет состоять.

С другой стороны допустимый ли это уровень надёжности при таких затратах?

Ну тут уже от ценности данных зависит :-)

[dcvl]

Спасибо большое.

[lem0n]

Handy Backup Поддерживает два способа копирования MSSQL: http://www.handybackup.ru/mssql-backup.shtml
Удобно

[Stranger03]

"lem0n"
Вы на дату постов обращайте внимание.