Выбор решения под бэкап
Модераторы: Trinity admin`s, Free-lance moderator`s
Выбор решения под бэкап
База MSSQL объёмом 20ГБ, рост 10 ГБ в год. текущие средства бэкапа - архив через скул менеджер и потом по расписанию на "бэкап" (файлопомойка) сервер не устраивает. Бэкапить надо минима два раза в световой день и ещё разок вечером. Скорость восстановления важна, но без фанатизма, т.е. простой до 4 часов допустим, более - уже скорее "нет" чем "да". Есть две мысли - сервер с большим количеством сата дисков, и ленточка. На примете msl 2024 LTO3 Ultrium 920 Tape Library и какой нибудь вариант типа супермикры на 12 саташников 2ТБ. Подскажите какой вариант из этих двух более приемлем. Или же из предложенных вариантов ваще ничего не катит и есть что то другое - мега-решение про которое я не знаю
Да. Бюджет - до 300 000 включительно.
PS.:Было бы совсем круто если бы хотя бы в общих чертах описали как налажен бэкап бизнес критикал БД в серьёзных конторах - всё таки чует одно место что к этому всё идёт.
Спасибо!
Да. Бюджет - до 300 000 включительно.
PS.:Было бы совсем круто если бы хотя бы в общих чертах описали как налажен бэкап бизнес критикал БД в серьёзных конторах - всё таки чует одно место что к этому всё идёт.
Спасибо!
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Выбор решения под бэкап
Начну с конца.
На сервера с приложениями и сервисами устанавливаются клиентские агенты управления РКиВД. Сначала в соответствии с определенными политиками и расписаниями делается резервное копирование на локальную дисковую подсистему сервера управления РКиВД - это можно назвать хранилищем оперативных бэкапов. Потом опять же в соответствии с определенными политиками оперативные бэкапы клонируются или переносятся на внешние устройства долговременного хранения (внешнии дисковые СХД, ленточные библиотеки или оба два).
Теперь по железу.
В течении часа пришлю вам в почту вариант сервера на 12 дисков по 2 Тб и пару вариантов ленточек. Тут вы зря на LTO3 смотрите, это уже сильно устаревший стандарт. Сейчас актуальный - LTO5. Ленточки могут быть как в виде просто привода (типа как дисковод, только с картриджем) без всякой автоматизации и с ручной заменой картриджей. А могут быть в виде роботизированных библиотек с 1 или более приводом и с автоматизацией замены картриджей (что дает возможность задавать различные политики по автоматической ротации и т.д.)
Так же следует еще принимать во внимание то на какой софт управления РКиВД расчитываете. Есть уже что на примете?
Как правило строят 2-х уровневую схему РКиВД (иногда ее называют схемой Disc-to-Disc-to-Tape). Отдельно ставить сервер управления РКиВД с соответствующим требованиям софтом, к нему же подключаются все необходимые устройства хранения - локальные диски, внешние СХД, ленточные библиотеки и т.д.Было бы совсем круто если бы хотя бы в общих чертах описали как налажен бэкап бизнес критикал БД в серьёзных конторах - всё таки чует одно место что к этому всё идёт.
На сервера с приложениями и сервисами устанавливаются клиентские агенты управления РКиВД. Сначала в соответствии с определенными политиками и расписаниями делается резервное копирование на локальную дисковую подсистему сервера управления РКиВД - это можно назвать хранилищем оперативных бэкапов. Потом опять же в соответствии с определенными политиками оперативные бэкапы клонируются или переносятся на внешние устройства долговременного хранения (внешнии дисковые СХД, ленточные библиотеки или оба два).
Вообще бэкап СУБД это практически отдельная религия :-) Вариантов масса. Как вариант можно делать полный бэкап до начала раб. дня, а в течении дня, например, ежечасно бэкап логов.База MSSQL объёмом 20ГБ, рост 10 ГБ в год. текущие средства бэкапа - архив через скул менеджер и потом по расписанию на "бэкап" (файлопомойка) сервер не устраивает. Бэкапить надо минима два раза в световой день и ещё разок вечером.
Теперь по железу.
В течении часа пришлю вам в почту вариант сервера на 12 дисков по 2 Тб и пару вариантов ленточек. Тут вы зря на LTO3 смотрите, это уже сильно устаревший стандарт. Сейчас актуальный - LTO5. Ленточки могут быть как в виде просто привода (типа как дисковод, только с картриджем) без всякой автоматизации и с ручной заменой картриджей. А могут быть в виде роботизированных библиотек с 1 или более приводом и с автоматизацией замены картриджей (что дает возможность задавать различные политики по автоматической ротации и т.д.)
Так же следует еще принимать во внимание то на какой софт управления РКиВД расчитываете. Есть уже что на примете?
С уважением, Александр
ICQ://13043204
ICQ://13043204
Re: Выбор решения под бэкап
Спасибо за ответ!
По поводу софта ещё не думал, честно говоря хотелось бы обойтись малой кровью - либо встроенным в винду (2008р2) сервисом (наследник ntbackup), либо опенсорсной разработкой. Пока что всё сводилось к встроенным средствам, но если стоимость решения уложится в бюджет - почему нет
Спасибо за разъяснение по поводу библиотек т.е. я правильно понимаю, что бэкап фактически мигрирует с одного типа носителя на другой ради надёжности? И ещё тогда вопрос - если на всю систему денег не хватит, - ну нет пока таких объёмов, тогда можно сделать первый шаг - сервер с кучей дисков для скоростного бэкапа, и потом по мере необходимости и роста критичности данных - докупать ленточку? направление мысли верное?
Опять таки волнует скорость бэкапа и восстановления в сравнении этих двух систем, в тех же MSL заявлено 864 GB/hr (ну как я понимаю это маркетологи вытащили максимальные расчётные цифры, в реальности слабо верится в 14.4 ГБ в минуту), а в файловом варианте думаю 100-110МБ\с более реально получить - т.е. фактически быстрее получится?
И ещё вопросик - как с надёжностью? Ребилд массива из 12*2ТБ дисков не самое быстрое занятие в случае чего....а в этом случае вся система хранения бэкапа ставится под угрозу. С другой стороны допустимый ли это уровень надёжности при таких затратах?
По поводу софта ещё не думал, честно говоря хотелось бы обойтись малой кровью - либо встроенным в винду (2008р2) сервисом (наследник ntbackup), либо опенсорсной разработкой. Пока что всё сводилось к встроенным средствам, но если стоимость решения уложится в бюджет - почему нет
Спасибо за разъяснение по поводу библиотек т.е. я правильно понимаю, что бэкап фактически мигрирует с одного типа носителя на другой ради надёжности? И ещё тогда вопрос - если на всю систему денег не хватит, - ну нет пока таких объёмов, тогда можно сделать первый шаг - сервер с кучей дисков для скоростного бэкапа, и потом по мере необходимости и роста критичности данных - докупать ленточку? направление мысли верное?
Опять таки волнует скорость бэкапа и восстановления в сравнении этих двух систем, в тех же MSL заявлено 864 GB/hr (ну как я понимаю это маркетологи вытащили максимальные расчётные цифры, в реальности слабо верится в 14.4 ГБ в минуту), а в файловом варианте думаю 100-110МБ\с более реально получить - т.е. фактически быстрее получится?
И ещё вопросик - как с надёжностью? Ребилд массива из 12*2ТБ дисков не самое быстрое занятие в случае чего....а в этом случае вся система хранения бэкапа ставится под угрозу. С другой стороны допустимый ли это уровень надёжности при таких затратах?
-
- Advanced member
- Сообщения: 327
- Зарегистрирован: 15 сен 2007, 13:23
- Откуда: Екатеринбург
- Контактная информация:
Re: Выбор решения под бэкап
Встроенным точно не получится обойтись. MS у него совсем оторвали возможность работы с ленточками.dcvl писал(а):По поводу софта ещё не думал, честно говоря хотелось бы обойтись малой кровью - либо встроенным в винду (2008р2) сервисом (наследник ntbackup), либо опенсорсной разработкой. Пока что всё сводилось к встроенным средствам, но если стоимость решения уложится в бюджет - почему нет :)
Посмотреть можно на MS Data Protector или на Symantec BackUp Exec.
Да, для резервирования хранимых копий и для архива копий.Спасибо за разъяснение по поводу библиотек :up: т.е. я правильно понимаю, что бэкап фактически мигрирует с одного типа носителя на другой ради надёжности?
Да, вполне правильное направление.И ещё тогда вопрос - если на всю систему денег не хватит, - ну нет пока таких объёмов, тогда можно сделать первый шаг - сервер с кучей дисков для скоростного бэкапа, и потом по мере необходимости и роста критичности данных - докупать ленточку? направление мысли верное?
Правило №1 построения системы РК: любое резервное копирование лучше, чем совсем его полное отсутствие. :-)
Тут еще будет сеть ограничения накладывать. Общение между серверов управления РКиВД и сервером непосредственно СУБД будет ведь по LAN происходить.Опять таки волнует скорость бэкапа и восстановления в сравнении этих двух систем, в тех же MSL заявлено 864 GB/hr (ну как я понимаю это маркетологи вытащили максимальные расчётные цифры, в реальности слабо верится в 14.4 ГБ в минуту), а в файловом варианте думаю 100-110МБ\с более реально получить - т.е. фактически быстрее получится?
Плюс еще разворачивание сервера СУБД полностью с нуля из резервной копии еще потянет за собой временные расходы на установку голой операционки (на которую потом сверху будут накатываться архивы из РК).
Чтобы совсем минимизировать время восстановления работы сервиса, можно еще посмотреть в сторону 2-го сервера СУБД и настройки репликации средствами MS SQL. Тогда у вас в случае аварии на основном сервере время переключения на зеркальный буквально минуты будет занимать, а основной потом уже можно будет вдумчиво и неторопясь обследовать и восстановить.
Под РК лучше массив собирать в 6-ой рейд, чтобы выход из строя одного диска не ставил весь массив в совсем плохое положение. И обязательно хот-спейр оставлять. Т.е. при 12 дисках реальный полезный объем из 9 будет состоять.И ещё вопросик - как с надёжностью? Ребилд массива из 12*2ТБ дисков не самое быстрое занятие в случае чего....а в этом случае вся система хранения бэкапа ставится под угрозу.
Ну тут уже от ценности данных зависит :-)С другой стороны допустимый ли это уровень надёжности при таких затратах?
С уважением, Александр
ICQ://13043204
ICQ://13043204
Re: Выбор решения под бэкап
Спасибо большое.
Re: Выбор решения под бэкап
Handy Backup Поддерживает два способа копирования MSSQL: http://www.handybackup.ru/mssql-backup.shtml
Удобно
Удобно
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Выбор решения под бэкап
"lem0n"
Вы на дату постов обращайте внимание.
Вы на дату постов обращайте внимание.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 19 гостей