Автоматизация резервного копирования: сравнение Veeam, Acronis и Bacula

Привет, коллеги! Сегодня разберем три топовых решения для бэкапов, которые я лично юзал в продакшене. За 15 лет в системном администрировании я повидал всякого: и сгоревшие RAID-массивы, и шифровальщиков, и админов, которые rm -rf запускали не на той машине (да-да, был грех). Поэтому тему резервного копирования знаю не понаслышке.

Почему эти три, а не сто пятьсот других?

Потому что это реально работающие решения, которые я видел в бою. Veeam — король виртуализации, Acronis — швейцарский нож для всего подряд, а Bacula — хардкорный монстр для тех, кто не боится конфигов на тысячу строк. Остальные либо нишевые, либо просто не дотягивают по функционалу.

Veeam Backup & Replication — когда виртуалка наше всё

Если у вас в инфраструктуре VMware или Hyper-V, то Veeam — это как AK-47: надежно, просто, работает везде. Ребята из Veeam сделали продукт, который даже джуниор настроит за пару часов, а восстановление VM займет минуты, не часы.

Фишки, за которые я люблю Veeam:

• Instant VM Recovery — поднимаешь виртуалку прямо из бэкапа за 2-3 минуты. Спасало меня не раз, когда прод падал в пятницу вечером
• SureBackup — автоматически тестирует бэкапы, запуская их в изолированной среде. Никаких сюрпризов типа «а бэкап-то битый!»
• Changed Block Tracking — копирует только изменившиеся блоки, экономя время и место
• Application-aware processing — корректно бэкапит SQL, Exchange, Oracle без остановки сервисов

Минусы: дорого для малого бизнеса, для физических серверов функционал беднее, чем для виртуалок.

Acronis Cyber Protect — когда нужно всё и сразу

Acronis прошел путь от простой утилиты для клонирования дисков до комбайна «всё в одном». Сейчас это не просто система бэкапов, а целая платформа с антивирусом, защитой от шифровальщиков и управлением патчами. Для MSP-шников — просто находка.

Что круто:

• Universal Restore — восстанавливаешь систему на совершенно другое железо. Спасал, когда надо было мигрировать физический сервер в виртуалку за ночь
• Active Protection — следит за процессами и блокирует шифровальщиков на лету
• Мобильные бэкапы — да, можно бэкапить айфоны и андроиды. Для директоров самое то
• Blockchain-based защита — хеши бэкапов пишутся в блокчейн, никто не подменит данные незаметно

Минусы: интерфейс иногда тормозит, в сложных сценариях автоматизации не такой гибкий, как хотелось бы.

Bacula — для тех, кто любит командную строку больше, чем GUI

Bacula — это опенсорсный монстр, который может всё, если ты умеешь его готовить. Я его юзал на проекте с 500+ серверами на разных ОС — от Windows до FreeBSD. Конфигурация — это поэма на несколько страниц, зато потом работает как швейцарские часы.

Сильные стороны:

• Гибкость — можно настроить ВСЁ. Любые сценарии, любую логику
• Модульная архитектура — Director, Storage Daemon, File Daemon работают независимо. Можно раскидать по дата-центрам
• Поддержка ленточных библиотек — лучшая среди всех решений. Если у вас LTO-ленты, то Bacula рулит
• Бесплатность — Community Edition не стоит ни копейки
• Скриптование — можно вызывать любые скрипты на любом этапе бэкапа

Минусы: кривая обучения как у Эвереста, документация так себе, GUI в Community версии нет, нужен сеньор-админ для настройки.

Сравнение по понятиям: цена, функционал, геморрой

Цена:

• Veeam: от $450 за сокет для Essentials, Enterprise — от $1300+. Для 10 VM есть бесплатная Community Edition
• Acronis: от $50/год за рабочую станцию, от $700/год за сервер. Подписочная модель, что удобно для бюджетирования
• Bacula: Community — бесплатно, Enterprise — от $500/сервер/год. Но учитывайте стоимость внедрения!

Простота использования:

• Veeam: 9/10 — интуитивный GUI, настроил и забыл
• Acronis: 9/10 — современный веб-интерфейс, всё на виду
• Bacula: 3/10 — если не любишь конфиги и консоль, обходи стороной

Производительность:

• Veeam: для виртуалок — огонь, до 25 VM параллельно на один прокси-сервер
• Acronis: средняя, около 10-15 TB/час в зависимости от конфигурации
• Bacula: масштабируется линейно, видел установки, где через него прогоняли петабайты данных

Практический пример №1: Автоматизация бэкапов в Veeam через PowerShell

Допустим, нам нужно каждую ночь бэкапить критичные VM, а в воскресенье делать full backup в облако. Veeam это умеет из коробки, но через PowerShell можно добавить свою логику:

# Подключаемся к Veeam серверу
Add-PSSnapin VeeamPSSnapin
Connect-VBRServer -Server "veeam-server.local"

# Получаем job по имени
$BackupJob = Get-VBRJob -Name "Critical-VMs-Daily"

# Запускаем бэкап
Start-VBRJob -Job $BackupJob

# Ждем завершения
while ((Get-VBRJob -Name "Critical-VMs-Daily").GetLastState() -eq "Working") {
    Start-Sleep -Seconds 30
}

# Проверяем результат
$Session = Get-VBRBackupSession | Where-Object {$_.JobName -eq "Critical-VMs-Daily"} | Sort-Object EndTime -Descending | Select-Object -First 1

if ($Session.Result -eq "Success") {
    # Отправляем в облако только если основной бэкап успешен
    $CopyJob = Get-VBRJob -Name "Copy-to-Cloud"
    Start-VBRJob -Job $CopyJob
    
    # Отправляем уведомление в <a class="wpil_keyword_link" href="https://t.me/it_apteka_com/34"   title="Telegram" data-wpil-keyword-link="linked"  data-wpil-monitor-id="270">Telegram</a>
    $Token = &amp;amp;quot;YOUR_BOT_TOKEN&amp;amp;quot;
    $ChatID = &amp;amp;quot;YOUR_CHAT_ID&amp;amp;quot;
    $Message = &amp;amp;quot;Бэкап Critical-VMs успешно завершен и скопирован в облако&amp;amp;quot;
    Invoke-RestMethod -Uri &amp;amp;quot;https://api.telegram.org/bot$Token/sendMessage&amp;amp;quot; -Method Post -Body @{chat_id=$ChatID; text=$Message}
} else {
    # Если бэкап failed — алярм!
    Send-MailMessage -To &amp;amp;quot;admin@company.com&amp;amp;quot; -From &amp;amp;quot;veeam@company.com&amp;amp;quot; -Subject &amp;amp;quot;ALARM: Backup Failed!&amp;amp;quot; -Body &amp;amp;quot;Проверь логи, бэкап упал!&amp;amp;quot; -SmtpServer &amp;amp;quot;smtp.company.com&amp;amp;quot;
}

Disconnect-VBRServer

Этот скрипт можно повесить в Task Scheduler, и он будет работать на автопилоте. Я добавлял еще проверку свободного места на репозитории и автоматическую очистку старых бэкапов.

Практический пример №2: Acronis — бэкап с автоматической проверкой целостности

В Acronis есть фишка — можно автоматически валидировать бэкапы после создания. Настраивается через GUI, но можно и через командную строку:

# Создаем план бэкапа через CLI
"C:\Program Files\Acronis\BackupAndRecovery\bin\acrocmd" create backup --name "Daily-Server-Backup" --source "C:\" "D:\" --target "\\backup-server\share\server1" --schedule daily --time 23:00 --validation enable

# Скрипт для проверки последнего бэкапа
$BackupPath = "\\backup-server\share\server1"
$LatestBackup = Get-ChildItem $BackupPath -Filter "*.tib" | Sort-Object LastWriteTime -Descending | Select-Object -First 1

# Запускаем валидацию
& "C:\Program Files\Acronis\BackupAndRecovery\bin\acrocmd" validate --target $LatestBackup.FullName

# Проверяем exit code
if ($LASTEXITCODE -eq 0) {
    Write-Host "Бэкап валидный, всё ок" -ForegroundColor Green
    
    # Логируем в базу или <a class="wpil_keyword_link" href="https://it-apteka.com/category/monitoring/"   title="Мониторинг" data-wpil-keyword-link="linked"  data-wpil-monitor-id="42">мониторинг</a>
    Invoke-RestMethod -Uri "http://monitoring.local/api/backup-status" -Method Post -Body @{server="server1"; status="OK"; timestamp=(Get-Date)}
} else {
    Write-Host "ALARM! Бэкап битый!" -ForegroundColor Red
    
    # Слать алярм во все колокола
    Send-MailMessage -To "admin@company.com" -Subject "CRITICAL: Backup Validation Failed" -Body "Сервер server1, бэкап от $(Get-Date) не прошел проверку!" -SmtpServer "smtp.company.com" -Priority High
}

Такая схема спасла меня, когда диск на NAS начал сыпаться — мы узнали об этом сразу, а не когда понадобилось восстанавливаться.

Практический пример №3: Bacula — гибкая ротация бэкапов по схеме «дед-отец-сын»

В Bacula можно настроить сложную схему ротации: ежедневные бэкапы хранятся неделю, еженедельные — месяц, ежемесячные — год. Это делается через конфигурацию:

# /etc/bacula/bacula-dir.conf

# Определяем расписание для ежедневных бэкапов
Schedule {
  Name = "DailySchedule"
  Run = Level=Incremental daily at 23:00
  Run = Level=Differential weekly on sunday at 23:00
  Run = Level=Full monthly on 1 at 22:00
}

# Настраиваем пулы для разных типов бэкапов
Pool {
  Name = Daily-Pool
  Pool Type = Backup
  Recycle = yes                       # Автоматически перезаписываем старые volumes
  AutoPrune = yes                     # Автоматически удаляем старые задания
  Volume Retention = 7 days           # Держим 7 дней
  Maximum Volume Bytes = 50G          # Макс размер одного volume
  Maximum Volumes = 14                # Макс количество volumes в пуле
  Label Format = "Daily-Vol-"
}

Pool {
  Name = Weekly-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 4 weeks
  Maximum Volume Bytes = 100G
  Maximum Volumes = 8
  Label Format = "Weekly-Vol-"
}

Pool {
  Name = Monthly-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 12 months
  Maximum Volume Bytes = 200G
  Maximum Volumes = 24
  Label Format = "Monthly-Vol-"
}

# Job для наших бэкапов
Job {
  Name = "ProductionServers-Backup"
  Type = Backup
  Client = prod-server-01-fd
  FileSet = "Full Set"
  Schedule = "DailySchedule"
  Storage = BackupStorage
  Messages = Standard
  
  # Используем разные пулы в зависимости от уровня бэкапа
  Full Backup Pool = Monthly-Pool
  Differential Backup Pool = Weekly-Pool
  Incremental Backup Pool = Daily-Pool
  
  # Скрипты до и после бэкапа
  Run Before Job = "/scripts/pre-backup.sh"
  Run After Job = "/scripts/post-backup.sh"
  
  Priority = 10
}

# FileSet — что именно бэкапим
FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /etc
    File = /var/www
    File = /home
    File = /opt/applications
  }
  
  Exclude {
    File = /proc
    File = /tmp
    File = *.tmp
    File = /var/cache
  }
}

После настройки запускаем:

# Перечитываем конфиг
sudo systemctl reload bacula-dir

# Проверяем, что всё ок
echo "status dir" | bconsole

# Запускаем тестовый бэкап
echo "run job=ProductionServers-Backup yes" | bconsole

Такая схема работает годами без вмешательства. Главное — правильно рассчитать размеры пулов под ваши данные.

Практический пример №4: Veeam — автоматическое масштабирование прокси-серверов

Когда VM-ок становится много, один прокси-сервер не справляется. В Veeam можно динамически добавлять прокси и распределять нагрузку:

# PowerShell скрипт для автоматического добавления прокси-серверов из пула

Add-PSSnapin VeeamPSSnapin
Connect-VBRServer -Server "veeam-server.local"

# Получаем текущую нагрузку на прокси
$ProxyServers = Get-VBRViProxy
$BusyProxies = ($ProxyServers | Where-Object {$_.IsDisabled -eq $false -and $_.GetTaskCount() -gt 0}).Count
$TotalProxies = ($ProxyServers | Where-Object {$_.IsDisabled -eq $false}).Count

# Если все прокси заняты — добавляем еще один из пула
if ($BusyProxies -eq $TotalProxies) {
    Write-Host "Все прокси заняты, добавляем еще один из пула"
    
    # Список серверов-кандидатов в прокси
    $ProxyPool = @("proxy-03.local", "proxy-04.local", "proxy-05.local")
    
    # Проверяем, какие уже добавлены
    $ExistingProxies = $ProxyServers | Select-Object -ExpandProperty Host
    
    # Находим первый свободный
    foreach ($NewProxy in $ProxyPool) {
        if ($NewProxy -notin $ExistingProxies.Name) {
            # Добавляем новый прокси
            $Server = Get-VBRServer -Name $NewProxy
            Add-VBRViProxy -Server $Server -Description "Auto-added proxy"
            
            Write-Host "Добавлен новый прокси: $NewProxy"
            
            # Уведомляем админа
            $Message = "Veeam автоматически добавил прокси-сервер $NewProxy из-за высокой нагрузки"
            # Отправка в мониторинг/мессенджер
            
            break
        }
    }
}

# Обратная логика — если нагрузка спала, отключаем лишние прокси
$CurrentLoad = ($ProxyServers | Measure-Object -Property GetTaskCount -Sum).Sum

if ($CurrentLoad -eq 0 -and $TotalProxies -gt 2) {
    Write-Host "Нагрузка упала, отключаем лишние прокси"
    
    # Находим последний добавленный прокси (не основной)
    $ProxyToDisable = $ProxyServers | Where-Object {$_.Description -eq "Auto-added proxy"} | Select-Object -First 1
    
    if ($ProxyToDisable) {
        Remove-VBRViProxy -Proxy $ProxyToDisable -Confirm:$false
        Write-Host "Прокси $($ProxyToDisable.Host.Name) отключен"
    }
}

Disconnect-VBRServer

Этот скрипт можно запускать каждые 15 минут через Task Scheduler. Сэкономил мне кучу нервов во время массовых миграций, когда нагрузка прыгала непредсказуемо.

Практический пример №5: Acronis + Azure — автоматический failover в облако

Acronis умеет делать автоматическую репликацию в Azure с возможностью быстрого поднятия VM в облаке. Настроим это через Acronis Cloud Manager:

# PowerShell <a href="https://it-apteka.com/mikrotik-dlja-professionalov-pravilnaja-nastrojka-s-nulja-do-production-2026/" target="_blank" rel="noopener"  data-wpil-monitor-id="459">скрипт для настройки</a> репликации в Azure через Acronis API

# Параметры подключения к Acronis
$AcronisURL = &amp;amp;quot;https://cloud.acronis.com&amp;amp;quot;
$ClientID = &amp;amp;quot;your-client-id&amp;amp;quot;
$ClientSecret = &amp;amp;quot;your-client-secret&amp;amp;quot;

# Получаем токен
$AuthBody = @{
    grant_type = &amp;amp;quot;client_credentials&amp;amp;quot;
    client_id = $ClientID
    client_secret = $ClientSecret
}
$Token = (Invoke-RestMethod -Uri &amp;amp;quot;$AcronisURL/api/2/idp/token&amp;amp;quot; -Method Post -Body $AuthBody).access_token

# Создаем план защиты с репликацией в Azure
$ProtectionPlan = @{
    name = &amp;amp;quot;Prod-Servers-Azure-Replica&amp;amp;quot;
    backup_schedule = @{
        type = &amp;amp;quot;daily&amp;amp;quot;
        time = &amp;amp;quot;22:00&amp;amp;quot;
    }
    replication = @{
        enabled = $true
        target = &amp;amp;quot;azure&amp;amp;quot;
        region = &amp;amp;quot;West Europe&amp;amp;quot;
        retention_days = 7
    }
    resources = @(
        @{type = &amp;amp;quot;machine&amp;amp;quot;; id = &amp;amp;quot;vm-prod-01&amp;amp;quot;},
        @{type = &amp;amp;quot;machine&amp;amp;quot;; id = &amp;amp;quot;vm-prod-02&amp;amp;quot;}
    )
}

$Headers = @{
    Authorization = &amp;amp;quot;Bearer $Token&amp;amp;quot;
    &amp;amp;quot;Content-Type&amp;amp;quot; = &amp;amp;quot;application/json&amp;amp;quot;
}

Invoke-RestMethod -Uri &amp;amp;quot;$AcronisURL/api/2/protection/plans&amp;amp;quot; -Method Post -Headers $Headers -Body ($ProtectionPlan | ConvertTo-Json -Depth 10)

# Скрипт для аварийного переключения в Azure
function Start-AzureFailover {
    param(
        [string]$MachineID
    )
    
    $FailoverBody = @{
        machine_id = $MachineID
        target = &amp;amp;quot;azure&amp;amp;quot;
        boot_mode = &amp;amp;quot;quick&amp;amp;quot;  # Быстрое поднятие из последней реплики
    }
    
    try {
        $Result = Invoke-RestMethod -Uri &amp;amp;quot;$AcronisURL/api/2/disaster-recovery/failover&amp;amp;quot; -Method Post -Headers $Headers -Body ($FailoverBody | ConvertTo-Json)
        
        Write-Host &amp;amp;quot;VM $MachineID запущена в Azure, IP: $($Result.ip_address)&amp;amp;quot; -ForegroundColor Green
        
        # Обновляем &amp;lt;a class=&amp;quot;wpil_keyword_link&amp;quot; href=&amp;quot;https://it-apteka.com/tag/dns/&amp;quot;   title=&amp;quot;DNS&amp;quot; data-wpil-keyword-link=&amp;quot;linked&amp;quot;  data-wpil-monitor-id=&amp;quot;90&amp;quot;&amp;gt;DNS&amp;lt;/a&amp;gt; на новый IP
        # ... тут логика обновления DNS записей
        
    } catch {
        Write-Host &amp;amp;quot;Ошибка failover: $_&amp;amp;quot; -ForegroundColor Red
    }
}

# Использование при падении основного дата-центра
# Start-AzureFailover -MachineID &amp;amp;quot;vm-prod-01&amp;amp;quot;

Такая схема — это уже disaster recovery уровень «энтерпрайз». У меня был кейс, когда основной ДЦ встал из-за потопа, и мы за 30 минут подняли критичные сервисы в Azure. Бизнес даже не заметил.

Когда что выбирать: мой чек-лист

Берите Veeam, если:

• У вас VMware или Hyper-V, и это основа инфраструктуры
• Нужно быстрое восстановление (Instant VM Recovery — киллер-фича)
• Есть бюджет (от 50k до нескольких миллионов в зависимости от масштаба)
• Команда не хочет копаться в конфигах — нужен GUI
• Важна интеграция с облаками (AWS, Azure)

Берите Acronis, если:

• Смешанная среда: физика, виртуалки, облако, рабочие станции
• Нужна защита от ransomware из коробки
• Вы MSP или сервис-провайдер (мультитенантность рулит)
• Хочется всё в одном: бэкап + антивирус + патч-менеджмент
• Бюджет средний (дешевле Veeam для смешанных сред)

Берите Bacula, если:

• Огромная инфраструктура (500+ серверов) на разных ОС
• Есть спецы, которые умеют в Linux и не боятся конфигов
• Нужна кастомная автоматизация под ваши процессы
• Используете ленточные библиотеки
• Бюджет ограничен (open-source версия бесплатна)
• Критична гибкость и контроль над каждым аспектом

Антипаттерны: чего НЕ надо делать

Ошибка #1: Не тестировать восстановление

Бэкап, который не проверен на восстановление — это не бэкап, а самообман. Я видел компанию, которая три года делала бэкапы на старый NAS, а когда понадобилось восстановиться — оказалось, что диски сдохли полгода назад, а мониторинг молчал. Минимум раз в квартал делайте test restore критичных систем.

Ошибка #2: Хранить все бэкапы в одном месте

Правило 3-2-1: три копии данных, на двух разных типах носителей, одна копия offsite (в другой локации или облаке). Если все ваши бэкапы лежат на одном SAN в той же серверной — это проблема. Пожар, потоп, криворукий админ — и всё пропало.

Ошибка #3: Забыть про RBAC и шифрование

Бэкапы — это лакомый кусок для хакеров. Шифруйте бэкапы (минимум AES-256), ограничивайте доступ по ролям, делайте immutable бэкапы (которые нельзя удалить или изменить определенное время). Veeam и Acronis это умеют из коробки.

Ошибка #4: Не мониторить процесс бэкапирования

Настройте алерты на failed jobs, на заполнение хранилища, на долгие бэкапы. Интегрируйте с вашей системой мониторинга (Zabbix, Prometheus, чо угодно). Молчаливый фейл бэкапа — это бомба замедленного действия.

Ошибка #5: Экономить на хранилище

SATA-диски в RAID5 для бэкапов критичных систем — так себе идея. Лучше NVMe или SSD для быстрых бэкапов и восстановлений, плюс дедупликация и компрессия сэкономят место. А для долгосрочного хранения — ленты или облачный S3/Glacier.

Реальные цифры из практики

За годы работы я собрал статистику по времени восстановления разных систем:

• Veeam Instant VM Recovery: 2-5 минут до загрузки ОС, потом VM мигрирует на прод-хранилище в фоне
• Acronis Universal Restore: 15-30 минут для физического сервера, 5-10 минут для VM
• Bacula: зависит от размера данных и типа хранилища, в среднем 30-60 минут для полного восстановления сервера

Скорость бэкапирования (усредненные данные):

• Veeam: 200-400 GB/час для инкрементальных бэкапов VM, 100-150 GB/час для полных
• Acronis: 150-250 GB/час в зависимости от типа данных и железа
• Bacula: 300-500 GB/час при правильной настройке и быстром хранилище

Степень сжатия (зависит от типа данных):

• Текстовые файлы, логи: 70-85%
• Виртуальные диски: 40-60%
• Базы данных: 30-50%
• Медиа-файлы (фото, видео): 5-10% (почти не сжимаются)

Подводя итоги: что я бы выбрал сам

Если бы мне дали чистый лист и попросили построить систему бэкапов с нуля, я бы сделал так:

Для стартапа или малого бизнеса (до 20 серверов): Acronis Cyber Protect. Цена адекватная, настройка простая, функционал покрывает 90% потребностей. Плюс защита от шифровальщиков — это сейчас мастхэв.

Для среднего бизнеса с виртуализацией (50-300 серверов): Veeam Backup & Replication без вариантов. ROI окупается за счет скорости восстановления и минимизации даунтайма. Instant VM Recovery спасал продакшн столько раз, что я уже сбился со счета.

Для крупного энтерпрайза с зоопарком платформ: Bacula Enterprise с профессиональной поддержкой. Да, внедрение дорогое, да, нужны спецы. Но гибкость и масштабируемость того стоят. Видел установки на 2000+ серверов — работает как часы.

Для MSP или облачного провайдера: Acronis Cyber Protect Cloud. Мультитенантность, биллинг, автоматизация — всё из коробки. Конкуренты типа Veeam тут проигрывают по удобству управления множеством клиентов.

Мой личный опыт: что пошло не так и как я это чинил

Кейс 1: Veeam и переполненное хранилище

На одном проекте настроили Veeam, все довольны, бэкапы идут. Через полгода в 3 часа ночи звонок: «Бэкапы не идут, хранилище переполнено!» Оказалось, retention policy настроили, а вот на автоматическую очистку забили. Старые бэкапы висели мертвым грузом.

Решение: добавил скрипт проверки свободного места и автоматической очистки:

Add-PSSnapin VeeamPSSnapin
Connect-VBRServer -Server "veeam-server.local"

$Repository = Get-VBRBackupRepository -Name "Main-Backup-Repo"
$FreeSpaceGB = $Repository.GetContainer().FreeSpace / 1GB
$TotalSpaceGB = $Repository.GetContainer().CachedTotalSpace / 1GB
$UsedPercent = (($TotalSpaceGB - $FreeSpaceGB) / $TotalSpaceGB) * 100

if ($UsedPercent -gt 85) {
    Write-Host "Хранилище заполнено на $UsedPercent%, запускаем очистку"
    
    # Удаляем бэкапы старше retention period
    $OldBackups = Get-VBRBackup | Where-Object {$_.FindLastRestore() -lt (Get-Date).AddDays(-30)}
    
    foreach ($Backup in $OldBackups) {
        Remove-VBRBackup -Backup $Backup -Confirm:$false
        Write-Host "Удален старый бэкап: $($Backup.Name)"
    }
    
    # Компактим хранилище
    Start-VBRCompactFullBackup -Repository $Repository
}

Disconnect-VBRServer

Теперь этот скрипт крутится ежедневно и никаких проблем.

Кейс 2: Acronis и медленное восстановление

Клиент жаловался, что восстановление из Acronis занимает вечность. Копнули глубже — оказалось, бэкапы лежали на медленном NAS с RAID5 из 5400 RPM дисков. При восстановлении 500GB сервера уходило 6+ часов.

Решение: купили отдельный SSD-диск для Acronis cache, настроили staging area на быстром хранилище. Время восстановления упало до 45 минут. Иногда деньги решают всё.

Кейс 3: Bacula и битые конфиги

Самый эпичный факап: джуниор-админ правил конфиг Bacula, сделал опечатку в синтаксисе. Bacula молча «проглотил» ошибку и перестал делать бэкапы. Узнали мы об этом через две недели, когда понадобилось что-то восстановить.

Решение: после этого я внедрил mandatory syntax check и автоматическое тестирование конфигов:

#!/bin/bash

# Проверка синтаксиса конфига перед применением
bacula-dir -t -c /etc/bacula/bacula-dir.conf

if [ $? -eq 0 ]; then
    echo "Конфиг валидный, перезапускаем Bacula"
    systemctl reload bacula-dir
    
    # Запускаем тестовый бэкап для проверки
    echo "run job=TestJob yes" | bconsole
    
    # Ждем завершения
    sleep 60
    
    # Проверяем статус
    STATUS=$(echo "list jobs" | bconsole | grep TestJob | tail -1 | awk '{print $7}')
    
    if [ "$STATUS" == "OK" ]; then
        echo "Тестовый бэкап успешен, всё работает"
    else
        echo "ALARM! Тестовый бэкап failed, откатываем конфиг"
        <a class="wpil_keyword_link" href="https://it-apteka.com/tag/git/"   title="Git" data-wpil-keyword-link="linked"  data-wpil-monitor-id="228">git</a> checkout HEAD^ /etc/bacula/bacula-dir.conf
        systemctl reload bacula-dir
    fi
else
    echo &amp;amp;quot;Ошибка в конфиге! Не применяем изменения&amp;amp;quot;
    exit 1
fi

Теперь все конфиги лежат в Git, перед каждым изменением идет проверка, и автоматически запускается тестовый бэкап.

Интеграция с мониторингом: чтобы спать спокойно

Любая система бэкапов должна быть интегрирована с мониторингом. Вот пример интеграции Veeam с Zabbix:

# PowerShell скрипт для отправки метрик в Zabbix

Add-PSSnapin VeeamPSSnapin
Connect-VBRServer -Server "veeam-server.local"

# Получаем все джобы за последние 24 часа
$Sessions = Get-VBRBackupSession | Where-Object {$_.EndTime -gt (Get-Date).AddHours(-24)}

# Считаем статистику
$TotalJobs = $Sessions.Count
$SuccessJobs = ($Sessions | Where-Object {$_.Result -eq "Success"}).Count
$FailedJobs = ($Sessions | Where-Object {$_.Result -eq "Failed"}).Count
$WarningJobs = ($Sessions | Where-Object {$_.Result -eq "Warning"}).Count

# Считаем общий объем бэкапов
$TotalBackupSizeGB = ($Sessions | Measure-Object -Property BackupSize -Sum).Sum / 1GB

# Время последнего успешного бэкапа
$LastSuccess = ($Sessions | Where-Object {$_.Result -eq "Success"} | Sort-Object EndTime -Descending | Select-Object -First 1).EndTime

# Отправляем в Zabbix
$ZabbixServer = "zabbix.local"
$ZabbixHost = "veeam-server"

& zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.jobs.total" -o $TotalJobs
& zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.jobs.success" -o $SuccessJobs
& zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.jobs.failed" -o $FailedJobs
& zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.jobs.warning" -o $WarningJobs
& zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.backup.size" -o $TotalBackupSizeGB

# Если последний успешный бэкап был больше 26 часов назад — алярм
if ((Get-Date) - $LastSuccess -gt (New-TimeSpan -Hours 26)) {
    & zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.backup.status" -o 0
} else {
    & zabbix_sender -z $ZabbixServer -s $ZabbixHost -k "veeam.backup.status" -o 1
}

Disconnect-VBRServer

Аналогично можно интегрировать Acronis и Bacula. Главное — чтобы мониторинг орал при любых проблемах.

Защита от ransomware: must-have в 2026

Шифровальщики эволюционировали. Они уже не просто шифруют файлы, а ищут и уничтожают бэкапы. Поэтому:

1. Immutable backups — бэкапы, которые нельзя изменить или удалить определенное время

• Veeam: функция Immutability на Linux-репозиториях или в S3
• Acronis: Acronis Notary (blockchain-based защита)
• Bacula: настраивается через WORM-хранилища или специальные скрипты

2. Air-gap backups — физически отключенные от сети бэкапы

• Ленточные библиотеки, которые офлайн большую часть времени
• Съемные диски, которые подключаются только на время бэкапа
• Облачные бэкапы в отдельном аккаунте с MFA

3. Separate credentials — учетки для бэкапов отдельно от доменных

• Никогда не используйте Domain Admin для сервиса бэкапов
• Отдельный аккаунт с минимальными правами
• Ротация паролей каждые 90 дней

Облако или on-premise: вечный спор

Мое мнение после работы с обоими вариантами:

On-premise плюсы:

• Полный контроль над данными
• Нет зависимости от интернет-канала
• Предсказуемая стоимость
• Быстрое восстановление (если всё в одном ДЦ)

On-premise минусы:

• Нужно закупать и обслуживать железо
• Риск физического уничтожения (пожар, потоп)
• Сложнее масштабировать

Облако плюсы:

• Offsite по умолчанию
• Легко масштабируется
• Не нужно заморачиваться с железом
• Geo-redundancy из коробки

Облако минусы:

• Стоимость растет с объемом данных
• Зависимость от интернета
• Медленное восстановление больших объемов
• Vendor lock-in

Мой выбор: гибридная модель. Основные бэкапы on-premise для быстрого восстановления, реплики критичных систем в облако для DR. Best of both worlds.

Чек-лист настройки бэкапов: копипастьте и юзайте

Вот мой personal checklist, который я прохожу при настройке любой системы бэкапов:

□ Определены RPO и RTO для каждой системы

• RPO (Recovery Point Objective) — сколько данных можно потерять
• RTO (Recovery Time Objective) — за сколько нужно восстановиться

□ Настроено расписание бэкапов

• Критичные системы — ежедневно минимум
• БД — лучше чаще (каждые 4-6 часов)
• Статичные данные — еженедельно хватит

□ Реализовано правило 3-2-1

• 3 копии данных
• 2 разных типа носителей
• 1 копия offsite

□ Настроена ротация бэкапов

• Ежедневные — хранить 7 дней
• Еженедельные — хранить 4-5 недель
• Ежемесячные — хранить 12 месяцев
• Ежегодные — по требованиям бизнеса

□ Включено шифрование

• Минимум AES-256
• Ключи хранятся отдельно от бэкапов

□ Настроен мониторинг и алерты

• Failed jobs → мгновенный алярм
• Долгие бэкапы → уведомление
• Заполнение хранилища → предупреждение при 80%

□ Тестирование восстановления

• Критичные системы — ежемесячно
• Остальное — ежеквартально
• Документировать результаты

□ Документация

• Runbook для восстановления
• Контакты ответственных
• Пароли в секретном хранилище

□ RBAC и audit

• Минимальные права для сервисных учеток
• Логирование всех действий
• Регулярный аудит доступов

□ Защита от ransomware

• Immutable backups где возможно
• Air-gap для критичных систем
• Отдельные креды

Вместо заключения: главное, что я понял за годы работы

Бэкапы — это не продукт, а процесс. Купить Veeam, Acronis или Bacula — это только начало. Нужно выстроить культуру резервного копирования в компании:

• Бэкапы — это не расход, а инвестиция в непрерывность бизнеса
• Автоматизация — ваш лучший друг, ручные бэкапы рано или поздно забудут сделать
• Тестирование восстановления критично, непроверенный бэкап = нет бэкапа
• Мониторинг должен орать при любых проблемах, молчаливые фейлы — это зло
• Документация спасает жизни (и карьеры), когда восстанавливаться нужно в 3 ночи

Не экономьте на бэкапах. Я видел компании, которые разорились после потери данных. Я видел админов, которых уволили (и даже засудили) за отсутствие бэкапов. Но я также видел героев, которые за час восстановили весь продакшн из бэкапов и спасли бизнес.

Будьте вторыми. Делайте бэкапы, автоматизируйте их, тестируйте восстановление. И спите спокойно.

P.S. Если у вас есть вопросы по настройке конкретных систем или нужна помощь с автоматизацией — пишите в комментах. Помогу чем смогу. В конце концов, мы все тут в одной лодке, и лучше помогать друг другу, чем потом вместе гореть в аду из-за потерянных данных 😄