Veeam Backup: резервное копирование виртуальных машин VMware и Proxmox

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

Что такое Veeam Backup и почему это стандарт?

• Image-level backup: снимаем VM целиком, со всем содержимым
• Changed Block Tracking (CBT): инкрементальные бэкапы — гоняем по сети только изменённые блоки, а не всю машину
• Instant VM Recovery: VM поднимается из бэкапа за 1-2 минуты, пока все ещё пьют кофе
• SureBackup: автоматически проверяет, что бэкап реально восстановится, а не просто лежит мёртвым грузом
• Application-aware: корректный бэкап SQL Server, Exchange, AD — без битых транзакций и рассыпавшихся баз

Какие компоненты входят в Veeam?

• Backup Server: управляющий сервер, живёт на Windows
• Backup Proxy: рабочая лошадка, которая непосредственно обрабатывает данные VM
• Backup Repository: хранилище бэкапов — Windows, Linux, NAS, S3, что угодно
• Enterprise Manager: веб-консоль для тех, кто управляет несколькими площадками

Как установить Veeam Backup & Replication?

По железу минимум такой: Windows Server 2019 и новее, 4 ядра, 8 ГБ RAM, 80 ГБ на диске под саму систему.

# Тихая установка
setup.exe /silent /accepteula /acceptthirdpartylicenses   /vbr /vbr_sqlserver_server="localhost\VEEAMSQL"

Как настроить бэкап VMware vSphere?

# PowerShell: создание задачи
Add-VBRViBackupJob -Name "Daily-Backup-Prod"   -Entity (Find-VBRViEntity -Name "VM-SQL01","VM-DC01")   -BackupRepository (Get-VBRBackupRepository -Name "Repo-NAS")

# Расписание
$schedule = New-VBRDailyOptions -DayOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -Period "22:00"
Set-VBRJobSchedule -Job "Daily-Backup-Prod" -DailyOptions $schedule
Enable-VBRJobSchedule -Job "Daily-Backup-Prod"

Как настроить Veeam для Proxmox VE?

Начиная с версии 12.2 Veeam официально поддерживает Proxmox VE — теперь без костылей и танцев с бубном:

# Backup Infrastructure -> Managed Servers -> Add Server -> Proxmox VE
# Указать IP и учётные данные root
# Veeam установит агент автоматически

Как работает Instant VM Recovery?

Честно — это моя любимая функция в Veeam:

1. Veeam монтирует бэкап как NFS datastore прямо на гипервизор
2. VM стартует из бэкапа за 1-2 минуты — люди даже не успевают занервничать
3. В фоне Veeam тихо мигрирует данные обратно на production-хранилище
4. Переключение проходит без downtime — пользователи не замечают вообще ничего

Реальный случай из практики: у клиента в пятницу вечером накрылся SSD с 1С-сервером. 40 человек встали. Наш инженер поднял VM из бэкапа за 3 минуты. В понедельник утром никто даже не вспомнил, что что-то случилось.

Как реализовать правило 3-2-1?

• Копия 1: production-данные на основном хранилище
• Копия 2: бэкап на локальный Repository — отдельное железо, не тот же массив
• Копия 3: Backup Copy Job в облако (S3) или на другую площадку

Как автоматически проверять бэкапы (SureBackup)?

1. поднимает изолированную виртуальную лабораторию, которая никак не касается боевой сети
2. запускает VM прямо из бэкапа внутри этой лаборатории
3. прогоняет проверки: пинг, открытые порты, SQL query
4. выдаёт чёткий отчёт — восстановится или нет

Что проверить перед подключением Proxmox VE к Veeam

Плагин Veeam для Proxmox VE работает иначе, чем защита vSphere, и у него есть ограничения, о которых лучше узнать до покупки лицензий. Я сверяю площадку клиента с системными требованиями и списком ограничений из документации Veeam Plug-in for Proxmox VE (релиз 3, декабрь 2025):

• Версии. Поддерживаются Proxmox VE 8.2–9.1, установленные с официального ISO Proxmox. Для этого релиза плагина нужен Veeam Backup & Replication 13.0.1.180 или новее. Proxmox, поставленный поверх Debian вручную, формально не поддерживается.
• Что не бэкапится. LXC-контейнеры, шаблоны ВМ и связанные клоны (linked clones). Полные клоны поддерживаются. Если на кластере много контейнеров, для них остаётся штатный vzdump или Proxmox Backup Server.
• Кластер. Каждый узел кластера добавляется в Veeam отдельно, кластер как единый объект добавить нельзя. После миграции ВМ между узлами изменения могут появиться в консоли Veeam только через 15 минут — ускоряет процесс ручной Rescan.
• Сеть и доступ. Узел Proxmox должен видеть сервер Veeam напрямую, без NAT. Вход по SSH-ключу и учётные записи с многофакторной аутентификацией для подключения не поддерживаются.
• Workers. Данные гоняют служебные Linux-ВМ, которые Veeam сам разворачивает на узлах. В конфигурации по умолчанию worker получает 6 vCPU, 6 ГБ RAM и 100 ГБ диска и обрабатывает до 4 задач одновременно; каждая дополнительная задача — ещё 1 vCPU и 1 ГБ RAM. Хранилище под worker должно поддерживать снапшоты, а в сетях с VLAN тег на worker назначается вручную после развёртывания.

Ресурсы под workers я закладываю в расчёт узлов заранее: на небольшом кластере 6 ГБ памяти на время бэкапа — заметная доля, и ночью она должна быть свободна.

Hardened Repository: копии, которые шифровальщик не удалит

Самый частый сценарий атаки на бэкапы — злоумышленник получает доступ к серверу Veeam и удаляет копии перед шифрованием. Против этого Veeam предлагает Hardened Repository — репозиторий на Linux с двумя механизмами. Неизменяемость: в течение заданного срока файлы копий нельзя переместить, изменить или удалить, только скопировать. Одноразовые учётные данные: логин и пароль используются один раз при развёртывании Veeam Data Mover и нигде не сохраняются, так что даже при взломе сервера Veeam подключиться к репозиторию с ними не получится.

Требования из документации Veeam Backup & Replication 12, которые я проверяю при сборке такого сервера:

• блочное хранилище — локальное или подключённое; NFS и SMB не подходят. Veeam рекомендует физический сервер с локальными дисками;
• файловая система с поддержкой атрибута immutable (chattr) и расширенных атрибутов; рекомендована XFS — из-за клонирования блоков;
• RAID 1 на SSD не меньше 100 ГБ под систему, RAID 6/60 с write-back-кэшем под данные, размер страйпа 128 или 256 КБ;
• каталог копий с правами 0700, владелец и группа — учётная запись подключения;
• только прямой инкрементальный режим (forward incremental) с активными или синтетическими полными копиями. Reverse incremental и forever forward incremental с неизменяемостью несовместимы;
• на сервере не должно быть Veeam Agent for Linux, а сам репозиторий нельзя делить между несколькими серверами Veeam.

Отдельная деталь — время. Служба неизменяемости следит за сдвигом системных часов, и если сдвиг превысит 24 часа, операции retention блокируются. Это же произойдёт, если выключить репозиторий больше чем на сутки. Поэтому аппаратные часы (RTC) я выставляю в UTC, а регламентные отключения такого сервера планирую короче суток.

Какие типичные ошибки при настройке Veeam?

• Бэкап на тот же массив — если массив умрёт, потеряете и данные, и бэкапы одним махом
• Нет off-site копии — один пожар, один шифровальщик или банальная кража железа, и всё
• Не настроен SureBackup — бэкапы формально есть, но никто не знает, восстановятся ли они в нужный момент
• Retention 3 дня — шифровальщики умеют тихо сидеть в системе неделями. Ставьте минимум 30 дней
• Нет уведомлений — бэкап может падать месяц подряд, и никто не узнает, пока не грянет гром

Вопросы масштабирования Veeam для крупных сред

Когда виртуальных машин перевалило за сотню, типовая схема уже не работает. На каждый кластер ESXi или Proxmox мы выделяем отдельные прокси-серверы — иначе узкое место по сети гарантировано. Scale-out Backup Repository спасает, когда одно хранилище перестаёт справляться с потоком. WAN Accelerator обязателен, если площадки соединены медленным каналом. И ещё один момент, который часто игнорируют: при 200+ VM встроенный SQL Express задыхается — каталог бэкапов нужно выносить на отдельный SQL Server.

Как настроить мониторинг и оповещения Veeam?

Бэкап без мониторинга — это просто ощущение защиты, не более. Email-уведомления настраиваются в три клика: Global Settings → Notifications → Configure, указываете SMTP и адреса получателей. Veeam ONE добавит дашборды и начнёт предупреждать о проблемах до того, как они станут инцидентами. Мы идём дальше — интегрируем Veeam с Zabbix и Telegram, чтобы алерт прилетал нашему дежурному инженеру в ту же минуту.

# Dell PERC
omreport storage pdisk controller=0

# HP Smart Array
ssacli ctrl slot=0 pd all show status

# Linux mdadm
cat /proc/mdstat
mdadm --detail /dev/md0

Когда обратиться к профессионалам?

• у вас больше 10 виртуальных машин
• крутятся критичные базы данных — 1С, SQL, Oracle
• нужен off-site бэкап в облако или на вторую площадку
• текущий бэкап ни разу в жизни не тестировался на реальное восстановление
• вы уже потеряли данные хоть раз и не хотите повторения