Comments 23
И – по многочисленным просьбам пользовательской аудитории! — Failover Cluster
По многочисленным просьбам? В вашем агенте просто нет базовой функциональности, которая в других продуктах есть десятилетиями.
Как без этого вы представляете резервное копирование файлового кластера? Наугад? Или надо чтобы виртуальные сервисы обязательно съехали на предпочтительные узлы?
Так же вы примерно бекапите Exchange — с нулевым интеллектом. Нельзя просто взять и указать базу в DAG. Надо создать задание на конкретном сервере на уровне тома. Вариант, что в DAG на одном из узлов может и не быть некой базы, никому в голову не приходил? А если на томе вдруг RDB лежит, то ее не надо бекапить? А если логи и база на разных томах, то надо не забыть галочки проставить. Или то, что надо бекапить пассивные копии, выбрав из них ту, которая не lagged?
До полноценного бекапа серверной физики по состоянию на Update2 вам еще ой как далеко.
Вы починили то что на windows server 2016 версия powershell новее и из-за этого при попытке снять снапшот базы была ошибка?
На этом же шаге необходимо определиться, в каком режиме будет работать агент, ответственный за резервное копирование.
А какой режим будет включен на уже подключенных серверах с агентами после обновления сервера до Update 3? А то у меня возникли сложности в своё время с удалением агента на CentOS 7 — процесс просто зависал и агент не удалялся, помнится даже кейс открывал, но саппорт мне так помочь и не смог.
Там в 10-ке не планируется кластеризация серверов Veeam то?
Поддерживаю с кластеризацией
Зачем кластер? Отказоустойчивость можно организовать другими методами.
Лучше бы сделали серверную часть на линуксе или хотя-бы проксю на линуксе.
Лучше бы сделали серверную часть на линуксе или хотя-бы проксю на линуксе.
Отказоустойчивость можно организовать другими методами.
С удовольствием послушаю ваш рассказ
Конечно же fault tolerance для Бэкап сервера. А вот серверная часть\прокси на линуксе — дело хорошее.
Как сделано в TSM: репликация на второй сервер и переключение клиентов на него при недоступности основного.
А датамуверы на линуксе действительно нужны (кластер AHV может быть вообще без лицензий на винду) и вряд ли портирование на .NET Core является невыполнимой задачей.
А датамуверы на линуксе действительно нужны (кластер AHV может быть вообще без лицензий на винду) и вряд ли портирование на .NET Core является невыполнимой задачей.
А зачем мне репликация?
Или вот пример — хочу отказоустойчивый прокси физический, покупаю 2 сервака, подключаю к СХД и...? :)
Или вот пример — хочу отказоустойчивый прокси физический, покупаю 2 сервака, подключаю к СХД и...? :)
Для DR при потере основного ЦОДа.
У меня продуктивная и резервная схд и так в разных цодах. Я привёл пример, который меня очень интересует :)
КМК, бекап всё равно нужен на случай, если навернутся снепшоты СХД или данные в них и погибнет основной ЦОД.
А вот зачем нужен HA-кластер для сервера бекапа представить не могу. TSM так умеет, но даже на продвинутом курсе про это не рассказывают.
А вот зачем нужен HA-кластер для сервера бекапа представить не могу. TSM так умеет, но даже на продвинутом курсе про это не рассказывают.
Когда очень часто нужно бэкапить\восстанавливать, без рабочей копии мастер-сервера бывает тяжело.
У меня складывается впечатление, что я хочу чего то странного :)
Вот есть 2 цода, в каждом свой кластер vmware, продуктивная схд в одном цоде и схд для рк во втором (с нормальными дисками, которые выдержат запуск 85% вм с продуктива). Я делаю бекап вимом из цода в цод, те не реплика снепшотов, а именно бекап (каналы позволяют). И вот у меня виртуальный сервер вима (да хоть пусть и физический) в основном цоде. Если цод основной ложиться, у меня есть бекапы, но нет сервера, который их восстановит. В итоге был поднят кластер MSSQL, растянутый на 2 цода для вима, один виртуальный сервер на основной площадке и резервный на второй в выключенном состоянии :) Но это какие то грабли :) Другой схемы от ТП я так добиться вразумительно и не смог (как и отказоустойчивости прокси :)) Или я хочу чего то слишком странного? :)
Вот есть 2 цода, в каждом свой кластер vmware, продуктивная схд в одном цоде и схд для рк во втором (с нормальными дисками, которые выдержат запуск 85% вм с продуктива). Я делаю бекап вимом из цода в цод, те не реплика снепшотов, а именно бекап (каналы позволяют). И вот у меня виртуальный сервер вима (да хоть пусть и физический) в основном цоде. Если цод основной ложиться, у меня есть бекапы, но нет сервера, который их восстановит. В итоге был поднят кластер MSSQL, растянутый на 2 цода для вима, один виртуальный сервер на основной площадке и резервный на второй в выключенном состоянии :) Но это какие то грабли :) Другой схемы от ТП я так добиться вразумительно и не смог (как и отказоустойчивости прокси :)) Или я хочу чего то слишком странного? :)
Коллега. Перенесите серевер BR на ваш DR Site. А в основном цод разместите прокси. При таком раскладе, при потере основного цод, у вас всегда будет готова система резервного копирования на удаленной площадке.
В такой ситуации достаточно иметь во втором ЦОДе второй сервер, на котором будет смонтирован тот же репозиторий. Если навернется перый ЦОД или первый бэкап-сервер, то что-бы экстренно восстановить что-то достаточно импортировать .vbk на втором сервере и восстановить данные. Для дальнейшей работы (пока не будет восстановлен первый) на втором сервере можно накатить бэкап конфигурации VeeamConfigBackup.
Мне вот линуксовый сервер/прокси интересен исходя из экономии Win-лицензии и т.к. у нас на хостах имеются свободные* локальные сторажи, то на них созданы ВМ с линуксом, которые через iSCSI отдают эти свободные* пространства бэкап-серверу под бэкап-копи-репозитории. Так вот неплохо было бы этим ВМ дать еще роль прокси.
Мне вот линуксовый сервер/прокси интересен исходя из экономии Win-лицензии и т.к. у нас на хостах имеются свободные* локальные сторажи, то на них созданы ВМ с линуксом, которые через iSCSI отдают эти свободные* пространства бэкап-серверу под бэкап-копи-репозитории. Так вот неплохо было бы этим ВМ дать еще роль прокси.
импортировать .vbk
Не нужно.
Если уж совсем срочно — Veeam Extract Utility.
не всегда хороший вариант:
1. восстанавливает только точку полного бэкапа (инкрементальные недоступны);
2. распаковываются файлы ВМ сначала локально, потом их надо выгрузить на сторадж (две операции, для большой ВМ накладно);
3. для большой ВМ может быть быстрее быстро развернуть с нуля новый сервер, импортировать .vbk (.vbm) и быстро запустить Instant VM Recovery (или полное восстановление в одну операцию).
1. восстанавливает только точку полного бэкапа (инкрементальные недоступны);
2. распаковываются файлы ВМ сначала локально, потом их надо выгрузить на сторадж (две операции, для большой ВМ накладно);
3. для большой ВМ может быть быстрее быстро развернуть с нуля новый сервер, импортировать .vbk (.vbm) и быстро запустить Instant VM Recovery (или полное восстановление в одну операцию).
А вот был бы прокси на линуксе, можно было бы собрать GFS и лить с двух железяк в один общий диск. Одна умерла — не беда, льет вторая как и лила.
Sign up to leave a comment.
Анонс: новые возможности Veeam Backup & Replication 9.5 (и далее)