Veeam Backup для бизнеса: 10 ошибок и как их избежать

Veeam Backup & Replication остаётся индустриальным стандартом для виртуализированных инфраструктур, но я регулярно вижу одни и те же грабли. За 15 лет внедрений накопил список из десяти ошибок, которые встречаются у девяти из десяти клиентов до того, как мы приходим. Разберём каждую с конкретными настройками задания, репозитория и прокси.

Ошибка 1: выбор обратного инкрементного метода без понимания цены

Метод Reverse Incremental, признаюсь, звучит очень заманчиво. Представьте: полный бэкап всегда под рукой, его не нужно синтезировать, а восстановление происходит мгновенно! На первый взгляд, это просто идеальное решение. Но, по моему опыту, в реальных офисных условиях для большинства задач это, к сожалению, один из худших вариантов.

Каждый цикл Veeam должен прочитать предыдущий полный бэкап, применить дельту с обратным знаком и переписать VBK на месте. Если у вас репозиторий на NAS или на дисках с RAID 5/6 — производительность падает в 3-5 раз по сравнению с прямым инкрементным.

Что же я делаю? Конечно, на очень быстром локальном репозитории, например, на SSD или NVMe, использовать Reverse вполне допустимо. Но лично я всегда отдаю предпочтение Forward Incremental, дополняя его периодическими synthetic full бэкапами. Вот как выглядит конфигурация задания у меня:

Backup mode: Incremental
GFS retention: enabled
Synthetic full: Saturday
Active full: first Saturday of month
Storage optimization: Local target (large blocks, 1024 KB)
Compression level: Optimal (LZ4)
Encryption: AES-256, password from KeePassXC

Synthetic full собирает полный бэкап из существующих инкрементов без чтения исходной ВМ — это безопасно и не нагружает гипервизор. Active full раз в месяц делается ради защиты от тихой коррупции цепочки.

Ошибка 2: репозиторий на одном RAID c production-нагрузкой

Классика, которая встречается чаще, чем кажется. У клиента ESXi с локальным RAID на 12 ТБ. Половина — ВМ, половина — папка для бэкапов. И всё через один контроллер.

И что из этого выходит? Как только ночью стартует окно бэкапа, на этих же дисках одновременно продолжают работать наши prod-ВМ. Резервные копии начинают активно генерировать запись со скоростью 200-400 МБ/с, и ВМ тут же начинают безбожно тормозить. Конечно, пользователи сразу жалуются на жуткие лаги в 1С. На следующее утро бухгалтер, что неудивительно, пишет гневное письмо директору. А уже через день мне раздаётся звонок.

Что делать. Репозиторий должен жить на отдельном физическом устройстве. Минимально приемлемые варианты для офиса до 50 РМ:

• Отдельный сервер Linux с большими SATA-дисками в RAID 6, подключённый по 10GbE.
• NAS Synology/QNAP с iSCSI-target (не SMB!) и LACP 2×1GbE.
• Серверная дисковая полка через SAS, отдельная от prod.

Никогда не размещайте репозиторий на той же СХД, что и ВМ. Никогда — это значит никогда, даже если кажется, что «места ещё много».

Ошибка 3: SMB-шара вместо Linux Hardened Repository

До эпохи шифровальщиков SMB был приемлемым выбором. Сегодня — это приглашение к катастрофе. Если ваш репозиторий смонтирован как SMB-шара с правами на запись из доменной сети — шифровальщик найдёт его, зашифрует и удалит копии.

Hardened Repository в Veeam 12 решает проблему. Это Linux-сервер (мы используем Ubuntu Server 22.04 LTS) с отдельной непривилегированной учёткой, к которой подключается Veeam по SSH и собственному протоколу. Бэкапы помечаются immutable-флагом ОС:

# На стороне Linux-репозитория
sudo apt install xfsprogs
sudo mkfs.xfs -L vbr-repo /dev/sdb1
sudo mount -o noatime,nodiratime /dev/sdb1 /mnt/vbr

# Создание непривилегированной учётки
sudo useradd -m -s /bin/bash vbruser
sudo chown vbruser:vbruser /mnt/vbr

# Настройка single-use credentials в Veeam Console
# Backup Infrastructure → Backup Repositories → Add Linux
# ✓ Use single-use credentials (одноразовый sudo для chattr)
# ✓ Make recent backups immutable for: 14 days

После настройки Veeam помечает бэкапы атрибутом immutable. Файлы невозможно удалить или перезаписать в течение указанного срока даже учёткой root. У одного клиента в 2025 году это спасло продакшен — шифровальщик успешно зашифровал prod, но бэкап-сервер устоял.

Ошибка 4: отключённый Application-Aware Processing

Без Application-Aware бэкап ВМ с базой данных — это снимок дисков «как есть» в момент копирования. Если в этот момент СУБД писала транзакцию, восстановленная база может оказаться с повреждениями журналов или вообще не запуститься.

Включается в свойствах задания: Guest Processing → Enable application-aware processing. Под Windows используется VSS, под Linux — pre/post-freeze скрипты. Дальше нужно дать Veeam учётку с правами на гость:

Guest credentials: domain\svc-veeam-guest
Truncate logs: Enable for SQL Server, retain 24 hours
File system indexing: ✗ Disable (если не нужен поиск)
Pre-freeze script: /usr/local/sbin/pre-backup-1c.sh
Post-thaw script: /usr/local/sbin/post-backup-1c.sh

Для серверов с 1С под Linux я пишу простой pre-freeze, который через v8run выгружает базу в *.dt и кладёт рядом с ВМ. Это даёт двойную страховку: можно восстановить как из снапшота, так и из dt-файла.

Без VSS / app-aware — у вас не бэкап, а заклинание удачи.

Ошибка 5: индексация файлов «на всякий случай»

Я знаю, опция Guest File System Indexing выглядит очень заманчиво: ведь это так удобно — искать нужные файлы прямо из консоли, не разворачивая при этом всю виртуальную машину (ВМ)! Но, поверьте мне, цена за эту удобство всегда одна и та же, и она высока. Индексация работает изнутри гостевой системы, ей приходится читать буквально миллионы файлов, она забивает диск C: кучей служебной информации и, что самое неприятное, удлиняет окно копирования на целых 30-60%!

Лично я включаю индексацию строго на двух типах серверов. Во-первых, это файловые шары — там, где нам действительно регулярно требуется искать удалённые документы. И во-вторых, это почтовые серверы. А вот для контроллеров домена, веб-серверов или DB-серверов — никогда, ни при каких обстоятельствах. Честно говоря, поиск по этим машинам всё равно остаётся бессмысленным занятием.

Если индексация уже включена и диск C: на сервере раздулся — нужно очистить каталог:

C:\ProgramData\Veeam\Backup\IndexData\
# или эквивалент на Linux:
/var/lib/veeam/IndexData/

# Удаляем старые индексы вручную, если рестарт не помог
Stop-Service VeeamCatalogSvc
Remove-Item -Recurse C:\ProgramData\Veeam\Backup\IndexData\*
Start-Service VeeamCatalogSvc

Ошибка 6: один уровень хранения вместо 3-2-1

Самая дорогая ошибка по последствиям. У клиента есть Veeam, есть репозиторий, бэкапы каждую ночь, всё зелёное. Только репозиторий стоит в той же серверной, что и продакшн. В 2024 году у нас был случай: прорвало трубу — залило стойку и сервер, и репозиторий. Бэкапов нет.

Лечится двумя дополнительными звеньями цепи. Внутри Veeam это называется Backup Copy Job — задание, которое забирает свежие восстановительные точки из основного репозитория и копирует их в другое место.

Минимальная схема для офиса:

• Primary: Linux Hardened Repository в офисе. Хранит 14 ежедневных + 4 еженедельных + 6 ежемесячных точек.
• Secondary: второй Linux-репозиторий в другом здании или в офисе одного из учредителей. Backup Copy раз в сутки, хранение 30 дней.
• Tertiary: Cloud Tier в S3-совместимое хранилище (Selectel, Yandex). Capacity Tier с включённой immutability на 90 дней.

Cloud Tier настраивается через Scale-Out Backup Repository:

SOBR Performance Tier: Linux Hardened (10 TB)
SOBR Capacity Tier: S3 (Selectel Object Storage)
Move backups older than: 14 days
Copy backups: enabled
Encryption: AES-256
Immutability: 90 days

Это классическое 3-2-1, развёрнутое средствами Veeam без необходимости заводить отдельный Restic или скрипты.

Ошибка 7: Instant VM Recovery без последующего переноса

Instant VM Recovery — это магия для аварийного восстановления. ВМ запускается прямо из бэкапа за две минуты вместо часа на распаковку. Только многие забывают: после запуска машина живёт на дисках репозитория, а не на нормальном продуктовом стораже.

Что происходит. Репозиторий по IOPS обычно в десять раз медленнее основной СХД. ВМ работает, но тормозит. Юзеры жалуются. Хуже того — Veeam удерживает на репозитории runtime-каталог с дельтой, которая постоянно растёт. За неделю можно забить терабайт.

Что делать сразу после Instant VM Recovery:

1. Открыть Home → Active Sessions → Instant Recovery, выбрать ВМ.
2. Запустить Migrate to Production. Veeam использует Quick Migration или Storage vMotion (на ESXi).
3. Дождаться завершения. Машина переедет на основной сторадж без даунтайма.
4. Только после этого нажать Stop Publishing и закрыть сессию.

В моих личных регламентах чётко прописано следующее правило: после выполнения любого Instant Recovery миграция должна быть обязательно завершена в течение 24 часов. Если этого не сделать, то то, что мы изначально считали «успешным восстановлением», уже через неделю гарантированно превратится в новую, причём порой ещё более серьёзную проблему.

Ошибка 8: прокси на той же машине, что и Veeam Server

В небольших инсталляциях Veeam Server по умолчанию берёт на себя сразу три роли: Server, Repository и Proxy. Это, конечно, очень удобно, но для офиса, где работает всего с десяток виртуальных машин (ВМ), такой подход быстро становится настоящим узким горлышком. Давайте разберёмся: прокси — это компонент, который отвечает за чтение данных из ВМ через VMware API или Hyper-V, он же их дедуплицирует, сжимает и затем отправляет в репозиторий. Если же прокси совмещён с сервером консоли — производительность всей системы будет напрямую ограничена ресурсами всего одного хоста.

Правильная архитектура для офиса:

• Veeam B&R Server — отдельная Windows-ВМ, 4 vCPU / 8 ГБ. Только консоль и базы конфигурации.
• Backup Proxy — отдельная Windows или Linux-ВМ на хосте ESXi, 4-8 vCPU / 8-16 ГБ. На один прокси можно ставить 4-8 одновременных задач.
• Backup Repository — отдельный физический Linux Hardened.

Когда речь идёт о больших инсталляциях, мы действуем иначе: ставим прокси прямо на каждый хост ESXi, причём по одной ВМ-прокси на хост. Такой подход позволяет использовать режимы Direct SAN или Hot-Add, благодаря которым данные читаются напрямую с datastore, минуя сеть управления.

Транспортный режим выбирается в свойствах прокси:

Transport mode:
  ✓ Automatic selection (Veeam сам выберет лучший)
  Or manually:
    - Direct storage access (для FC/iSCSI SAN)
    - Virtual appliance (Hot-Add) (для большинства офисов)
    - Network (NBD) (резерв, медленнее всего)

Ошибка 9: репликация без NBD-прокси на удалённой стороне

Veeam умеет не только бэкапить, но и реплицировать ВМ на запасной хост. В офисе это часто используется для DR — копия критичных машин в другом здании или в облаке. Грабли подстерегают именно здесь.

Представьте ситуацию: прокси на удалённой стороне трудится в режиме Virtual Appliance (Hot-Add). Он создаёт снапшот реплики, монтирует диск к себе и записывает дельту через сетевой стек гипервизора. А теперь, что если канал WAN вдруг начинает «мигать» или просто становится слишком медленным? В этом случае снапшот может элементарно не успеть закрыться. И тогда нам приходится вручную консолидировать или, что ещё хуже, удалять зависшие диски — совсем не весело, я вам скажу.

Какое решение я предлагаю? На удалённой стороне мы всегда используем режим NBD (Network Block Device). Да, теоретически он немного медленнее, но зато отлично переживает любые обрывы канала и, что очень важно, не оставляет за собой висящих снапшотов. А на практике, для большинства офисных нагрузок, разница в скорости вообще не заметна — ведь узким местом всё равно остаётся канал WAN.

Backup Infrastructure → Backup Proxies → Edit remote proxy
Transport mode: Network (NBD)
Failover to network mode if primary fails: ✓
Connected to: Target side only (для replica jobs)

Ошибка 10: бэкапы делаются, но восстановление никогда не тестировалось

Самая распространённая ошибка, на самом деле. Veeam настроен, окно зелёное, отчёты приходят. Только когда наступает реальный инцидент — выясняется, что один бэкап битый, второй не разворачивается из-за нехватки места, третий шифрован паролем, который никто не помнит.

Veeam даёт три встроенных инструмента для регулярного тестирования:

SureBackup. Автоматический запуск ВМ из бэкапа в изолированной виртуальной лаборатории с проверкой работоспособности (heartbeat, ping, custom скрипт). Раз в неделю запускается для критичных машин.

SureBackup Job:
  Application Group: AD-DC + SQL + 1C
  Virtual Lab: Isolated network 192.168.99.0/24
  Tests:
    - VMware Tools heartbeat
    - Ping (gateway 192.168.99.1)
    - Test script: SQL connection, 1C ragent listen
  Schedule: weekly, Sunday 02:00

Instant Recovery to test environment. Раз в месяц вручную восстанавливаем случайную ВМ в тестовый ESXi-кластер, проверяем работоспособность, удаляем.

File-level restore. Раз в неделю запрашиваем у пользователя, какой файл удалили случайно, восстанавливаем, отдаём. Регулярная практика поддерживает навыки и проверяет консистентность бэкапов файловых шар.

Без этого цикла ваш Veeam — это видимость защиты. С ним — реальная страховка.

Бонус: правильные права на учётные записи

Это правило, хоть и не входит в мой топ-10, но настолько критично, что я просто не могу о нём не упомянуть. По умолчанию Veeam почему-то запрашивает «учётку администратора домена» буквально для всего. Это, на мой взгляд, очень плохая практика! Поэтому я всегда разделяю все учётные записи, строго следуя принципу минимальных привилегий:

Если шифровальщик скомпрометирует одну из учёток — он не получит доступ ко всей цепочке.

FAQ

Подходит ли Veeam Community Edition для офиса до 50 РМ?
Да, до 10 рабочих нагрузок (VM или агентов) бесплатной редакции хватает. Если виртуальных машин больше или нужны Tape, Cloud Tier и SureBackup — берём платную лицензию по подписке.

Какой репозиторий Veeam надёжнее: Windows или Linux Hardened?
Linux Hardened Repository однозначно безопаснее: иммутабельные бэкапы через chattr +i, отдельная учётка без sudo, нет SMB-шары для шифровальщика. Я ставлю Hardened везде, где есть техническая возможность.

Сколько прокси нужно для офиса с 30 виртуальными машинами?
Один прокси с 4 vCPU обрабатывает 4-8 параллельных задач. Для 30 ВМ при окне в 4 часа достаточно одного прокси, при окне в 1 час имеет смысл поставить два с балансировкой.

Что делать после успешного Instant VM Recovery?
Запустить Quick Migration или Storage vMotion для переноса машины в production-стораж. Если оставить ВМ работать с репозитория — в нагрузке упадёт IOPS, а сам репозиторий начнёт переполняться runtime-данными.

Можно ли восстановиться из Veeam-бэкапа без самого Veeam?
Да. Файлы VBK/VIB монтируются утилитой Veeam Extract Utility (она же входит в дистрибутив). Это спасает в катастрофе, когда Veeam-сервер тоже потерян. Я всегда оставляю копию extract.exe на USB-диске рядом с лентами.

Хотите аудит вашей инсталляции Veeam?

Если вы уже используете Veeam, но у вас закралось подозрение, что что-то в настройках работает не совсем оптимально, — я предлагаю заказать аудит у команды АйТи Фреш. Мы тщательно проверим конфигурацию ваших заданий, репозитория и прокси, обязательно проведём тестовое восстановление и выдадим подробный протокол с нашими рекомендациями. Вы можете оставить заявку на сайте itfresh.ru или написать нам на 7296241@gmail.com. Базовый аудит занимает всего три рабочих дня.

Семёнов Е.С., технический директор АйТи Фреш. 15+ лет в IT-аутсорсинге для бизнеса.