В ситуации, когда вы бежите:
В таком приблизительном масштабе, какие решения для резервного копирования вам подходят? И, в качестве дополнительного вопроса, было ли у кого-нибудь из них дедупликация, которая, по вашему мнению, была эффективной и полезной?
У меня похожая среда, и я использую Veeam Backup делать как резервные копии, так и реплики. Veeam использует функцию отслеживания измененных блоков vSphere, которая сокращает окно резервного копирования. Вы можете установить срок действия резервных копий, чтобы обеспечить доступность резервных копий в течение 3 месяцев. Общий объем хранилища резервных копий будет зависеть от количества изменяемых блоков каждый день, а также от того, собираетесь ли вы сохранять ежедневные инкременты или использовать еженедельную или ежемесячную ротацию резервных копий.
Veeam лицензируется на каждый хост, а не на виртуальную машину, поэтому это довольно рентабельно, если у вас высокий коэффициент консолидации.
В vSphere есть новомодный API vBackup, который как бы устраняет прокси-сервер VCB, если вы хотите осуществлять прямую передачу данных на основе SAN в ваших резервных копиях. Есть несколько поставщиков продуктов, которые поддерживают это, и мой опыт пока очень положительный.
Основное преимущество заданий резервного копирования на основе SAN / vBackup:
Безагентное резервное копирование для большинства виртуальных машин. Резервные копии создаются путем создания снимка виртуальной машины, резервного копирования создаваемого статического диска и последующего выпуска снимка. Если программное обеспечение на виртуальной машине работает со снимками, то с помощью этого метода можно будет выполнять резервное копирование без агента. Я считаю, что приложения с поддержкой VSS, такие как Exchange и SQL, нормально работают со снимками ... так что вам не нужны агенты, если вы не хотите детализированное (на уровне элементов) восстановление таких вещей, как отдельные электронные письма и строки таблицы.
Резервное копирование на основе SAN может быть очень быстрым. Особенно, если вы отправляете эти данные в тихое время. Мы проверяем все интерфейсы SP на нашем iSCSI SAN, когда резервное копирование выполняется в течение ночи.
Отслеживание блоков изменений делает возможным инкрементное / дифференциальное резервное копирование всей виртуальной машины, быстрое и очень маленькое.
Есть несколько предостережений:
Вам действительно нужно переходить с диска на диск, а не с диска на ленту. Поэтому определенно рекомендуется несколько ТБ хранилища на вашем резервном хосте. Без этого вы просто не увидите пропускной способности.
Ваши физические резервные хосты должны быть подключены к вашей SAN и иметь возможность видеть все ваши LUN для их резервного копирования. На практике это означает, что у вас обычно есть коробка с Windows с HBA и тонна «неопознанных томов» в управлении дисками. Что он хочет инициализировать для вас каждый раз, когда вы туда заглядываете. Если вы это сделаете, он уничтожит ваши тома VMFS. Типа отстой.
Функция отслеживания блокировки изменений может показаться немного неудобной, если вы по какой-либо причине не получаете резервную копию в течение нескольких дней подряд.
Как вкратце упоминалось, вам, вероятно, понадобятся агенты для узлов SQL, Exchange и AD, даже если они являются виртуальными машинами, чтобы обеспечить детальное восстановление.
Ваши хосты ESX или ESXi должны быть лицензированы. ESXi Free не поддерживает vStorage. Также рекомендуется иметь VirtualCenter, но я считаю, что это не обязательно.
Трудно рекомендовать отдельные продукты, поскольку я действительно работал только с Backup Exec, но я считаю, что версия 2010 R2 является стабильной и удобной для работы.
Дедупликация - интересная тема. Мы оценили ее для BE2010 (первый выпуск) и обнаружили, что она содержит много ошибок. Это также не экономило нам много места (поскольку дополнительная работа так хороша) ... так что это не стоило дополнительных хлопот или затрат. В то время мы уведомили нашего поставщика, и они, похоже, хотели работать с нами над решением проблем, но мы отказались от этого, потому что преимуществ не было.
Решение для резервного копирования будет зависеть от целевых показателей RPO и RTO для организации, доступной полосы пропускания, оборудования и окон резервного копирования. Одна известная мне крупная среда VMware полагается на решение резервного копирования VMware по сценариям для восстановления ОС (полный образ диска ОС создается каждую неделю) плюс встроенные в ОС агенты для резервного копирования данных. В этом подходе помогает наличие выделенных загрузочных дисков на машинах.
Я бы не рекомендовал создавать резервные копии самих серверов ESX, гораздо проще подготовить установочный компакт-диск по сценарию и восстановить сервер путем неинтерактивной переустановки. Самое интересное - это виртуальные машины.
Поскольку у вас очень разнородная среда, я вижу два подхода:
1) Продолжайте делать то, что вы делаете, обращаясь с машинами как с отдельными физическими ящиками. Это может быть административной болью в нижних регионах из-за n отдельных процедур резервного копирования и восстановления, но если это сработало до сих пор, это сработало, верно?
2) Стандартизируйте один продукт, который может работать во всех средах. Я много слышу о TSM, но, возможно, здесь я не совсем объективен, потому что мой работодатель продает и поддерживает TSM.
Мы используем Avamar от EMC для резервного копирования нашей инфраструктуры VMware, и он работает очень хорошо. Это быстро и выполняет резервное копирование только измененных блоков и только одной копии каждого блока (поэтому обычные файлы Windows будут копироваться только один раз, а не один раз для каждой виртуальной машины). Обратной стороной является то, что это дорого, но если у вас есть EMC, это может быть не за пределами вашего бюджета (я не знаю полных затрат, потому что за это заплатил кто-то другой :-))