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

Veeam Backup & Replication – это централизованное решение для защиты данных в виртуальных, физических и облачных средах. Оно позволяет создавать резервные копии, выполнять восстановление на уровне машин, файлов и приложений, а также автоматизировать процессы защиты и репликации данных для обеспечения непрерывности работы. helpcenter.veeam.com

 

Сценарий использования.

Гипервизор Microsoft Hyper-V соединен через локальную сеть с сетевым хранилищем. Veeam Backup устанавливается на одну из виртуальных машин (ВМ) на этом хосте. Далее настраивается доступ в гипервизор с целью выполнения резервного копирования других виртуальных машин и самого себя на сетевое хранилище. Veeam рекомендует виртуализацию сервера управления, чтобы при необходимости можно было легко мигрировать его на другой хост.

В результате Veeam Backup используется как централизованный сервер управления резервным копированием. Для защиты виртуальных машин Hyper-V применяется безагентное бэкапирование на уровне гипервизора (API-based backup). Veeam напрямую взаимодействует с Hyper-V хостами, выполняя создание контрольных точек и резервных копий виртуальных машин без установки агентов внутри ВМ.

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

 

Порядок действий:

Скачиваем ПО.

Создаем виртуальную машину.

Устанавливаем ОС.

Устанавливаем Veeam Backup.

Добавляем (регистрируем в Veeam) сервер.

Добавляем сетевое хранилище.

Добавляем сервер в инфраструктуру.

Создаем задание резервного копирования.

Проверяем результат.

 

Программное обеспечение (ПО).

Скачиваем ПО с официального сайта.

Бесплатная версия включает возможность бэкапировать до 10 виртуальных машин.

Перед загрузкой необходимо зарегистрироваться или войти в профиль доступным способом. Можно использовать учетную запись Google. Размер образа около 16Гб (для версии 12.3).

 

Создание ВМ.

В данном случае использован гипервизор Hyper-V на Windows Server 2019. Виртуальная машина с Veeam не будет полноценно работать на гипервизоре с операционной системой (ОС) Windows 10 или 11.

Для ВМ с Veeam Backup, который будет бэкапить 10 других ВМ, используются следующие параметры:

-ядер процессора х64 – 6шт;

-оперативная память – 12Гб;

-дисковое пространство для ОС – 200Гб SSD RAID;

-дисковое пространство для работы с бэкапами – 800ГБ (объем зависит от ситуации);

-операционная система – Windows Server 2019.

Диск на который планируется устанавливать Veeam Backup должен быть 150-200Гб для ОС, самого Veeam, базы данных и служебных нужд. Это с запасам. Можно взять меньше. Второй том или отдельный диск для проверки бэкапов, их разворачивания, запуска и тп взят тоже с запасом. Это в данном случае вторая часть 1-терабайтного дискового пространства RAID.

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

​

Установка ОС.

Устанавливаем Windows Server.

Настраиваем необходимые параметры: IP-адрес, антивирус, агенты мониторинга и тп.

 

Учетная запись.

В доменной инфраструктуре Veeam должен работать под отдельной технической доменной учетной записью, а не под локальными администраторами. Это наилучшая практика.

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

 

Доменная учетная запись.

У доменной учетки следующие плюсы:

-одна учетная запись для всей инфраструктуры;

-корректная работа Application-Aware Processing;

-не нужно заводить локального админа на каждом сервере;

-удобно управлять правами через группы и GPO;

-легче масштабировать (новые серверы сразу работают).

Недостатки доменной учетки:

-Зависимость от AD и DNS (могут возникнуть сложности при восстановлении DC);

-сложность настройки через GPO (RDP/Logon restrictions).

Учетную запись с правами Domain Admin использовать не рекомендуется – высокие риски безопасности. Из-за этого возникает сложность настройки нужных прав. А так как сам Veeam на начальном этапе развертывания не такой простой, как это кажется, то приходится использовать Domain Admin, чтоб еще больше не усложнять. В последствии эту учетку нужно заменить на правильно настроенную без прав Domain Admin.

 

Локальная учетная запись.

Положительные стороны у локальной учетки:

-не зависит от домена и DC (минимальные риски);

-простой вариант для одного сервера (standalone).

Недостатки:

-нужно создавать и поддерживать учетку на каждом сервере;

-пароли часто разные, сложно сопровождать;

-плохо работает с AAP, особенно для DC;

-плохо масштабируется.

В небольшой инфраструктуре и для одного сервера (гипервизора) использование локальной учетной записи – это вполне приемлемый рабочий вариант. Или вариант на начальном этапе с последующим переходом на доменную учетную запись.

Поэтому, для минимизации сложности при внедрении, далее описание с локальной учетной записью.

В сервер Veeam создаем локальную учетную запись с правами администратора. Встроенного администратора отключаем.

На начальном этапе ВМ с Veeam Backup не добавлялась в домен. Со временем можно добавить ВМ в домен и при этом работать под локальной учёткой в переходный период. Veeam никак не привязывается к домену. После установки, он просто использует те учётные данные, которые ему указаны для запуска служб или доступа к каждому серверу и репозиторию.

Переходим к установке Veeam.

 

Установка Veeam Backup and Replication.

Подключаем скаченный образ через виртуальный дисковод и запускаем установку.

 

Выбираем первый вариант установки из предложенных.

Install Veeam Backup & Replication – устанавливает основной сервер и все необходимые роли: база конфигурации, планировщик заданий, менеджер инфраструктуры. При такой установке Veeam может работать как прокси или репозиторий (по умолчанию).

Install Veeam Backup Enterprise Manager – дополнительный компонент, не обязателен в данном случае. Используется в больших инфраструктурах, где несколько серверов Veeam B&R. Дает web-интерфейс для централизованного управления и поиска бэкапов, отчётности, делегирования прав.

Install Veeam Backup & Replication Console – это только клиентская консоль. Можно ставить на другие админские рабочие станции/серверы, чтобы подключаться к Veeam Backup удалённо. На самом сервере Veeam она ставится автоматически вместе с п.1, отдельно выбирать её не нужно.

 

Принимаем лицензионное соглашение.

 

Активируем лицензию или используем бесплатную с ограничениями.

По умолчанию выставлена к использованию лицензия Community Edition – бесплатная версия Veeam с ограничением до 10 инстансов и без коммерческой поддержки, предназначенная для тестовых и небольших сред.

ВМ, физический сервер или агент = 1 инстанс.

В бесплатной версии нет технической поддержки от Veeam, нет Enterprise-функций, в том числе Backup Copy с расширенными сценариями, нет расширенного мониторинга и отчетности, отсутствуют некоторые автоматизации и масштабируемые сценарии. Нельзя использовать для оказания услуг третьим лицам (запрещено для аутсорса).

 

На следующем шаге можно внести собственные настройки через кнопку Customize Settings.

Installation folder – расположение файлов программы. Не изменяем.

vPower cache folder – кэш для Instant Recovery, при запуск ВМ прямо из бэкапа. Рекомендуется SSD, иначе скорость восстановления будет медленной.

Guest catalog folder – здесь Veeam хранит индексы файлов, которые находятся внутри бэкапируемых ВМ (если используется Guest File Indexing). Размер сильно зависит от числа ВМ и количества файлов. Для теста и нескольких ВМ хватает стандартного пути. Для продакшена желательно отдельный диск или раздел. У нас на Veeam это отдельный том.

Service account – учетная запись для запуска основных служб Veeam. Local System (по умолчанию) – служба Veeam работает под встроенной системной учёткой Windows, аналогом NT AUTHORITY\SYSTEM. На старте пойдет. В последствии можно заменить на локальную или доменную учетку.

Database engine – тип СУБД для хранения конфигурации.

Database server – адрес сервера базы данных.

Database name – имя базы данных конфигурации.

Catalog service port – порт для службы гостевого каталога файлов.

Service port – основной порт для подключения консоли управления.

Secure connections port – порт для защищенных подключений (шифрование данных).

REST API service port – порт для работы REST API.

Check for product updates – автоматическая проверка обновлений. Не отключаема на данном этапе.

Кроме двух пунктов (vPower cache folder  и Guest catalog folder) остальные настройки без изменений. Если Veeam видит свободные тома или диски, то он сам предложит изменить путь.

 

Ожидаем установку. Готово.

 

Подключаемся в Veeam B&R через создавшийся ярлык на рабочем столе.

 

Добавление сервера.

Managed Servers – раздел для регистрации серверов, которые будут использоваться как инфраструктурные роли Veeam.

Veeam регистрирует и доверяет серверу, проверяет доступы (ADMIN$, WMI, RPC), назначает роли. Может использовать сервер повторно в разных заданиях и понимает что это за сервер. Без этого Veeam не сможет корректно работать, назначать роли, будет выдавать ошибки (gateway, proxy, access denied и тп).

Добавляем хост Hyper-V.

Проходим мастер добавления.

 

Указываем IP-адрес или сетевое имя гипервизора.

Рекомендуется указывать DNS-имя (hostname), а не IP. Имя работает корректно при смене IP, правильно используется доменная аутентификация, меньше проблем с доступом ADMIN$, WMI, RPC.

На гипервизоре (HYPERV-SERVER) работает ВМ DC. Если это единственный DC в сети, то это значит что сам гипервизор не войдет в домен пока не запустит ВМ внутри себя. Получается замкнутый круг. Поэтому хост (гипервизор) не в домене. И на нем так же используется локальная учетная запись.

 

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

 

Если возникнет ошибка.

Это значит, что Veeam не смог подключиться к административному скрытому ресурсу ADMIN$ на Hyper-V-сервере.

Устранение ошибки под спойлером.

​

 

Проходим далее по мастеру настройки. Apply >> Next >>Finish.

 

 

 

Присоединенный сервер появится в списке.

 

Добавление репозитория.

В качестве репозитория по плану использование сетевого хранилища. Его нужно заранее подготовить. Создать сетевую папку, разрешить доступ для заданных IP и другие настройки.

Сетевое хранилище не должно находиться в одном сегменте сети с серверами, клиентами или сетевым оборудованием в целях информационной безопасности. Для надежного хранения нужен отдельный VLAN только для NAS. Наилучший вариант – подключение NAS напрямую к серверу Veeam через дополнительный сетевой адаптер. Например так.

Чтоб создание бэкапа или восстановление выполнялось быстро, сетевое хранилище и сервер должны быть соединены опто-волоконной линии связи 10Гбит/с. Для хранилища нужны надежные диски, например WD Red если HDD.

 

Добавляем репозиторий с заготовленной сетевой папкой.

 

Выбираем вариант сетевого хранения бэкапов. Так же возможны локальное и облачное хранение.

 

Выбор между NFS и SMB для репозитория Veeam зависит от среды и требований, но NFS часто предпочтительнее, особенно в виртуальных средах. Veeam лучше оптимизирован под NFS (производительность, мгновенное восстановление и тп). Выбираем NFS.

 

Указываем понятное название репозитория – QSAN-VEEAM-BACKUP-FOLDER.

 

Переходим далее. Если ошибка, то варианты решения под спойлером.

​

 

В расширенных настройках отмечены два пункта. Не изменяем их.

Align backup file data blocks (recommended) – оптимизирует ввод-вывод на уровне файловой системы, снижает нагрузку на NAS и ЦП и дает прирост скорости на NFS-хранилищах. Увеличение размера бэкапов менее чем на 2%, зато меньше фрагментации и нагрузка на CPU NAS ниже.

Decompress backup file data blocks before storing – эта опция используется только для dedup-устройств (DataDomain, StoreOnce, ExaGrid). QSAN (в данном случае) не выполняет дедупликацию на уровне блоков, поэтому decompress только увеличит трафик и нагрузку.

This repository is backed by rotated drives – это используется, для внешних USB- или съёмных дисков, которые периодически меняются. На стационарном NAS не нужно, иначе Veeam будет искать пропавшие тома.

Use per-machine backup files (recommended) – это современный режим хранения. Каждая ВМ или сервер получает свой отдельный .VBK/.VIB файл. Это увеличивает скорость параллельных задач, упрощает восстановление, снижает риск повреждения всей цепочки.

 

Следующий шаг мастера.

Mount Server – это сервер, через который Veeam будет монтировать резервные копии.

Mount Server – выбран сервер с Veeam (BACKUP-SERVER) потому что именно он инициирует все операции и имеет доступ к NAS по NFS.

Instant recovery write cache folder – это временное хранилище для изменённых блоков при запуске ВМ из бэкапа. После завершения восстановления оно очищается.

В зависимости от структуры кэш может располагаться на другом диске или томе.

Enable vPower NFS service on the mount server – включает службу vPower NFS на выбранном сервере монтирования. Позволяет Veeam предоставлять бэкапы виртуальных машин как временное NFS-хранилище, чтобы запускать Instant VM Recovery (мгновенный запуск ВМ прямо из бэкапа), выполнять file-level и application-item recovery без полного восстановления, тестировать бэкапы и запускать ВМ напрямую из backup-файлов. Тоесть работать с бэкапом как с «живым» диском, не дожидаясь полного восстановления.

Подсказка ниже сообщает что эта настройка критична для VMware-сценариев и почти не влияет на Hyper-V. Но её всё равно рекомендуют включать на будущее.

Можно изменить порты если это нужно.

Далее настройки не вносим. Можно указать поиск существующих архивов, но в данном случае это не нужно. Подтверждаем выбор, проверяем и завершаем.

 

 

Добавленное хранилище появится в списке.

И сразу же сообщение предлагает хранить в том же месте конфигурацию самого сервера Veeam. Соглашаемся. Конфиги нужно хранить вне сервера.

 

Добавление сервера Hyper-V. 

Virtual Infrastructure – раздел для подключения и инвентаризации платформ виртуализации.

При добавлении Hyper-V хоста Veeam подключается к его API (Application Programming Interface) и автоматически устанавливает на него свой служебный компонент – Veeam Backup Transport Service, обеспечивающий безагентный бэкап на уровне гипервизора.

 

Выбран сервер Microsoft Hyper-V так как именно он используется в данном описании.

 

Указываем IP-адрес или сетевое имя сервера.

 

Выбираем тип добавляемого сервера.

Microsoft System Center Virtual Machine Manager (SCVMM) – подключение централизованного менеджера Hyper-V. Подключается к SCVMM, а не к хостам напрямую Автоматически получает список Hyper-V хостов, кластеров, ВМ. Понимает Live Migration, кластеры, размещение ВМ и тп. Выбирать этот пункт если есть SCVMM и Hyper-V инфраструктура управляется через него.

Microsoft Hyper-V cluster – подключение кластера Hyper-V напрямую, без SCVMM. Регистрирует кластер как единый объект. Осознаёт Live Migration, Failover, сам управляет всеми узлами кластера. Выбирать этот пункт следует если есть Hyper-V Failover Cluster.

Microsoft Hyper-V server (standalone) – подключение одиночного Hyper-V хоста. Работает с одним сервером без кластерной логики. Выбираем в данном случае. Это самый простой и распространённый вариант для небольших инфраструктур.

 

Выбираем ранее созданные учетные данные.

Или создаем новые на кнопку Add.

Учетные данные должны быть с правами администратора на HYPERV-SERVER. Это может быть локальный или доменный админ, в зависимости от местных обстоятельств.

 

Завершаем мастер. Review >> Apply >> Summary.

This Hyper-V server will act as the backup proxy for jobs running in the on-host backup mode – в режиме on-host Veeam использует сам Hyper-V хост как прокси для чтения данных виртуальных машин.

Task limit: 4 – максимум 4 параллельных задачи бэкапа/восстановления, которые этот хост может обрабатывать одновременно. Ограничение по CPU/RAM или другим параметрам хоста.

 

 

 

После завершения мастера сервер появится в списке.

 

Задание резервного копирования (Jobs).

Создадим задание для резервного копирования служебных серверов (DC, KSC, СКУД и тп).

В разделе работ выбираем бэкап виртуальных машин.

 

Указываем понятное название.

 

Выбираем все необходимые ВМ, которые планируется бэкапить.

Если гипервизор не добавлялся ранее, то на этом шаге мастера будет предложено его добавить.

 

Следующий шаг – параметры самого бэкапа.

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

Назначение настроек.

Backup proxy: Off-host backup (automatic proxy selection) — Veeam будет выполнять бэкап не на самом Hyper-V хосте, а через отдельный backup proxy, который автоматически выбирается системой. Данные ВМ считываются с Hyper-V, передаются на выделенный прокси-сервер (обычно Veeam Backup Server или отдельная ВМ), нагрузка снимается с гипервизора. Veeam сам выбирает подходящий proxy по доступности, нагрузке, сетевой близости к хранилищу. Это нужно для уменьшения нагрузки на CPU Hyper-V. Рекомендованный режим.

Backup repository – выбираем созданный ранее репозиторий.

Retention Policy – это правила хранения точек восстановления, которые определяют, как долго и в каком количестве бэкапы будут храниться перед автоматическим удалением.

restore point – это одна копия состояния виртуальной машины на определённый момент времени. Зависит от регулярности выполнения бэкапа.

Если делать один бэкап в неделю, то 1 restore point = 1 неделя.

Если делать ежедневно – 1 restore point = 1 день.

Retention policy: 30 restore points означает храни последние 30 точек восстановления, а более старые удалять. Это не 30 дней и не обязательно 30 файлов, всё зависит от режима бэкапа.

restore days – дни восстановления. Хранить все точки восстановления за N календарных дней. Veeam считает время жизни каждой точки (по дате). Любые точки старше N дней автоматически удаляются.

 

Keep certain full backups longer for archival purposes – для целей архивирования рекомендуется хранить некоторые полные резервные копии дольше.

GFS retention policy (Grandfather-Father-Son) – гибкая структура хранения архивов по неделям, месяцам и годам. GFS добавляет к Retention policy архивные точки восстановления, которые не удаляются при обычной ротации и сохраняются по определённому расписанию.

Keep weekly full backups for (weeks) – хранить выбранное количество еженедельных полных резервных копий для среднесрочного восстановления.

If multiple full backups exist, use the one from – определяет, какую полную копию недели использовать в качестве weekly (например, за воскресенье).

Keep monthly full backups for (months) – хранить ежемесячные полные резервные копии для долгосрочного архивного хранения.

Use weekly full backup from the following week of a month – указывает, какая недельная копия будет сохранена как месячная (например, первая неделя месяца).

Keep yearly full backups for (years) – хранить ежегодные полные резервные копии для максимально долгого хранения.

Use monthly full backup from the following month – определяет, какая месячная копия используется как годовая (например, январская).

Выбираем:

Keep monthly full backups for: 3 months – хранить полные резервные копии в течение 3 месяцев.

Use weekly full backup from the following week of a month: First – первый бэкап месяца попадает в архив.

 

Расширенная настройка.

Reverse Incremental (медленнее) – последняя точка восстановления всегда является полным бэкапом (full backup). При каждом новом инкрементальном бэкапе изменения (инкременты) внедряются в основной файл полного бэкапа, а предыдущее состояние сохраняется как инкремент. Всегда есть актуальный полный бэкап для быстрого восстановления. Недостаток – высокая нагрузка на хранилище при каждой операции (перезапись основного файла).

Incremental (рекомендуется) – сначала создаётся полный бэкап (Full), затем каждый следующий бэкап сохраняет только изменения с предыдущего. Быстрее выполняется создание бэкапов. Меньше нагрузки на хранилище (запись только новых файлов). Но для восстановления нужна вся цепочка файлов (риск при повреждении любого звена).

Create synthetic full backups periodically on – это дополнительная опция для Incremental mode. Veeam периодически создаёт синтетический полный бэкап, собирая его из последнего Full + всех последующих инкрементов. Создаётся без нагрузки на виртуальные машины (не требует их чтения).

Active Full Backup (Активный полный бэкап) – Veeam периодически выполняет полный бэкап с нуля, читая все данные виртуальной машины заново. Создаётся новый независимый файл полного бэкапа (Full.vbk), не связанный с предыдущей цепочкой. Старая цепочка бэкапов удаляется согласно политике хранения.

Synthetic full может унаследовать незамеченные ошибки из старой цепочки. В этом плане active full backup надежнее.

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

Active Full и GFS Monthly – это не две разные копии, а одна и та же full-копия, просто она дополнительно помечается как архивная.

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

 

В итоге для бэкапа служебных серверов приняты следующие настройки:

Retention policy: 30 restore points

GFS – Keep monthly full backups for: 3 months

Incremental – активировано.

Active Full Backup – первую субботу месяца.

Запуск по расписанию: ежедневно в 00:00 (о расписании написано далее).

Тоесть сохраняются последние 30 состояний обычных копий, выполняемых ежедневно (инкрементно), плюс делается 1 полная  копия 1 раз в месяц, и удерживается 3 месяца. Получается, что хранится текущий месяц по дням, плюс 3 месячных архива. Старые ежедневные точки старше 30 дней удаляются. Старые месячные архивы старше 3 месяцев удаляются.

 

Место для хранения.

Нужно учитывать, чтоб на это хватило места хранилища. Объем всех серверов для данного бэкапа составляет 450Гб. 1 full + 30 incremental означает, что есть 1 базовый полный бэкап и 30 добавочных копий, где хранятся только изменения, то есть не новые 450 ГБ, а, например, 3-10 ГБ в день (зависит от активности). Если изменений немного так как, сервера не файловые, а служебные (KSC, DC и т.п.), то средний объём инкрементального бэкапа равен 5-10% от full.

30точек х 20Гб=600Гб.

450+600=1,05Тб места на месяц.

GFS Monthly (3 full) = 3 × 450 ГБ = 1,35 ТБ

Итого 1,05+1,35=2,4 ТБ на цикл. + запас в результате 3 Тб необходимо.

 

Следующий шаг – Guest Processing. Эти настройки превращают Veeam из простого инструмента бэкапа в интеллектуальную платформу для гарантированной консистентности приложений, гибкого управления и проактивной безопасности данных.

Enable application-aware processing – обеспечивает консистентный бэкап приложений (SQL, Exchange, Active Directory и др.) за счёт их подготовки к бэкапу и обработки логов транзакций. Исключает потерю данных в базах данных и почтовых ящиках. Гарантирует восстановление приложений в работоспособном состоянии.

Customize application handling options – позволяет задать индивидуальные настройки для каждого приложения и каждой ВМ (например, обработка логов SQL, усечение транзакций, скрипты до/после). Гибкая настройка под требования конкретных сервисов. Минимизация простоев при бэкапе критичных систем.

Enable guest file system indexing and malware detection – индексирует файлы внутри ВМ для быстрого поиска и автоматически обнаруживает подозрительную активность и известные вредоносные файлы. Ускорение поиска файлов для восстановления. Раннее обнаружение угроз. Анализ компрометации через историю бэкапов.

Customize guest OS credentials for individual machines and operating systems – настройка индивидуальных учётных данных гостевой ОС для каждой виртуальной машины. Позволяет задать разные логины/пароли для доступа к гостевым ОС внутри виртуальных машин – отдельно для Windows, Linux, отдельных ВМ или групп.

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

В случае локального админа выбираем под каждую ВМ учетные данные, затем нажимаем кнопку Test Now. Если возникнут ошибки доступа – ищем причину и устраняем. Повторяем тест. Если всё равно доступа нет – отключаем настройку Enable application-aware processing. Veeam не будет пытаться заходить в каждую ВМ, но и гарантии восстановления (особенно для баз данных) уменьшаются.

 

Следующий шаг – расписание.

Указываем дату, время и другие параметры для запуска создаваемого задания. Варианты настройки очень широкие.

Для бэкапа вышеназванных серверов выбраны следующие параметры:

Daily at this time: 00:00 Everyday – задание будет запускаться в ноль часов ежедневно.

 

Варианты запуска задания резервного копирования.

Run the job automatically – включает автоматический запуск задания по расписанию.

Daily at this time – запуск задания ежедневно в указанное время.

Monthly at this time – запуск задания раз в месяц в выбранный день и время.

Periodically every – запуск задания через равные интервалы времени (например, каждые N часов или минут).

After this job – запуск задания автоматически после завершения другого задания (цепочка заданий).

 

Другие параметры.

Automatic retry – автоматически повторяет попытку обработки объектов, если резервное копирование завершилось ошибкой.

Retry failed items processing: 3 times – количество повторных попыток бэкапа для объектов, завершившихся с ошибкой.

Wait before each retry attempt for 10 minutes – интервал ожидания между повторными попытками, чтобы дать инфраструктуре восстановиться.

Backup window – ограничивает время, в течение которого задание резервного копирования может выполняться.

Terminate the job outside of the allowed backup window – принудительно завершает задание, если оно выходит за пределы разрешённого временного окна, чтобы не влиять на рабочие часы и производительность продакшена.

При создании нескольких работ нужно следить чтоб их расписания не пересекались.

 

Завершаем мастер настройки.

 

Созданная работа появится в списке.

Аналогично создаются другие работы.

Для бэкапа самого себя (Veeam Backup сервера) необходимо создавать отдельную работу.

 

Проверка.

Можно запустить работу вручную и убедится что она выполнится.

 

 

После выполнения можно просмотреть отчет.

 

Первый бэкап для одного тестового сервера выполнялся 10мин (потому что full), все последующие очень быстро, менее 1 мин, (потому что incremental). В сетевой папке создались файлы.

На этом основная настройка по вводу Veeam Backup в эксплуатацию завершается.

 

Дополнение.

​