Резервное копирование 17 апреля 2026 · 16 мин чтения

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:

Открыть Home → Active Sessions → Instant Recovery, выбрать ВМ.
Запустить Migrate to Production. Veeam использует Quick Migration или Storage vMotion (на ESXi).
Дождаться завершения. Машина переедет на основной сторадж без даунтайма.
Только после этого нажать 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 — это видимость защиты. С ним — реальная страховка.

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

Не входит в десятку, но настолько важно, что не могу не упомянуть. По умолчанию Veeam просит «учётку администратора домена» для всего. Это плохая практика. Я разделяю учётки по принципу минимальных привилегий:

Учётка	Где используется	Минимальные права
svc-veeam-vsphere	Подключение к vCenter	Veeam Backup Administrator role в vSphere
svc-veeam-guest	Application-aware processing	Local admin на каждой ВМ, без доменных прав
svc-veeam-repo	Доступ к Linux Hardened	Непривилегированный пользователь с single-use sudo
svc-veeam-cloud	S3-репозиторий	Отдельный access key с минимальными правами на бакет

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

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-аутсорсинге для бизнеса.