MinIO как S3-хранилище для бэкапов Veeam: замена ленточных библиотек на объектное хранилище

Производственная компания «ПромГрупп» использовала классическую схему резервного копирования: Veeam Backup & Replication записывал бэкапы на дисковый репозиторий (60 TB на RAID6), откуда они копировались на ленточную библиотеку HP MSL6480 с LTO-7 лентами. Суммарный объём защищаемых данных — 85 TB, ежедневный прирост — 1.2 TB.

Проблемы, которые привели к решению о миграции:

• Скорость восстановления — восстановление с ленты занимало от 4 до 12 часов в зависимости от объёма. Лента физически перематывалась, загружалась, и только потом начиналось чтение.
• Надёжность — за последний год три ленты оказались нечитаемыми. Проверка целостности (verify) выполнялась раз в квартал, и промежуток между инцидентом и обнаружением составлял до 3 месяцев.
• Стоимость — обслуживание ленточной библиотеки (контракт HP) стоило 480 000 руб/год, плюс ленты LTO-7 по 4 500 руб за штуку (потребление 15-20 лент/год).
• Ransomware-защита — после атаки на партнёрскую компанию руководство потребовало иммутабельные бэкапы, которые невозможно удалить или зашифровать.

MinIO — S3-совместимое объектное хранилище, которое можно развернуть на собственных серверах. Мы выбрали distributed mode для отказоустойчивости.

Аппаратная конфигурация — 4 сервера, каждый:

• CPU: Xeon Silver 4310 (12 cores)
• RAM: 64 GB ECC
• Диски: 8 × 18 TB SAS HDD (JBOD, без RAID)
• Сеть: 2 × 25 GbE (bonding LACP)

Полезная ёмкость при erasure coding EC:4: 4 сервера × 8 дисков × 18 TB = 576 TB raw. С EC:4 (половина на данные, половина на чётность) — 288 TB полезной ёмкости. Это позволяет потерять до 4 дисков (или целый сервер) без потери данных.

Установка MinIO в distributed mode:

# На каждом из 4 серверов (minio1-minio4)
# Устанавливаем MinIO
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/

# Создаём пользователя
sudo useradd -r -s /sbin/nologin minio-user

# Монтируем диски в /data/disk1 ... /data/disk8
for i in $(seq 1 8); do
  sudo mkdir -p /data/disk${i}
  sudo mkfs.xfs /dev/sd${letter} -f -L disk${i}
  echo "LABEL=disk${i} /data/disk${i} xfs defaults,noatime 0 2" | sudo tee -a /etc/fstab
done
sudo mount -a
sudo chown -R minio-user:minio-user /data/

# Systemd unit
cat > /etc/systemd/system/minio.service << 'EOF'
[Unit]
Description=MinIO Object Storage
After=network-online.target
Requires=network-online.target

[Service]
User=minio-user
Group=minio-user
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server --console-address ":9001" \
  https://minio{1...4}.promgrupp.local/data/disk{1...8}
Restart=always
RestartSec=10
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

# Конфигурация
cat > /etc/default/minio << 'EOF'
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=ChangeMe-Strong-P@ssw0rd-32chars!!
MINIO_VOLUMES="https://minio{1...4}.promgrupp.local/data/disk{1...8}"
MINIO_SERVER_URL="https://minio.promgrupp.local:9000"
MINIO_BROWSER_REDIRECT_URL="https://minio-console.promgrupp.local"
EOF

sudo systemctl enable --now minio

Erasure coding в MinIO работает на уровне каждого объекта: файл разбивается на data shards и parity shards. При EC:4 (конфигурация по умолчанию для 4 нод по 8 дисков) — 16 shards на объект: 8 data + 8 parity. Потеря до 8 shards (целый сервер) не приводит к потере данных.

Object Lock — ключевая фича для защиты бэкапов. Объекты с включённым Object Lock невозможно удалить или перезаписать до истечения retention period — даже с правами root MinIO.

# Устанавливаем mc (MinIO Client)
wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc && sudo mv mc /usr/local/bin/

# Добавляем alias
mc alias set promgrupp https://minio.promgrupp.local:9000 admin 'P@ssw0rd'

# Создаём bucket с включённым Object Lock
# ВАЖНО: Object Lock можно включить ТОЛЬКО при создании bucket
mc mb promgrupp/veeam-backups --with-lock

# Устанавливаем default retention (Compliance mode, 30 дней)
# Compliance mode: никто не может удалить объект, даже root
# Governance mode: root может снять lock (менее безопасно)
mc retention set --default COMPLIANCE 30d promgrupp/veeam-backups

# Создаём отдельный bucket для архивных бэкапов (90 дней retention)
mc mb promgrupp/veeam-archive --with-lock
mc retention set --default COMPLIANCE 90d promgrupp/veeam-archive

# Проверяем настройки
mc retention info promgrupp/veeam-backups
# Mode: COMPLIANCE
# Validity: 30 days

Для Veeam создаём отдельного пользователя с минимальными правами:

# Создаём пользователя для Veeam
mc admin user add promgrupp veeam-svc 'Veeam-S3-Str0ng-Key!!'

# Создаём политику доступа
cat > /tmp/veeam-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetBucketLocation",
        "s3:ListBucket",
        "s3:GetBucketVersioning",
        "s3:GetBucketObjectLockConfiguration",
        "s3:PutObjectRetention",
        "s3:GetObjectRetention",
        "s3:GetObjectVersion",
        "s3:PutObjectLegalHold",
        "s3:GetObjectLegalHold",
        "s3:ListBucketVersions"
      ],
      "Resource": [
        "arn:aws:s3:::veeam-backups",
        "arn:aws:s3:::veeam-backups/*",
        "arn:aws:s3:::veeam-archive",
        "arn:aws:s3:::veeam-archive/*"
      ]
    }
  ]
}
EOF

mc admin policy create promgrupp veeam-policy /tmp/veeam-policy.json
mc admin policy attach promgrupp veeam-policy --user veeam-svc

В Veeam Backup & Replication 12 добавлена нативная поддержка S3-совместимых хранилищ как Object Storage Repository.

Пошаговая настройка:

1. Backup Infrastructure → Backup Repositories → Add Repository → Object Storage → S3 Compatible
2. Указываем endpoint: https://minio.promgrupp.local:9000
3. Credentials: Access Key = veeam-svc, Secret Key = пароль
4. Выбираем bucket veeam-backups, указываем folder /veeam/
5. Включаем Make recent backups immutable for 30 days — Veeam будет использовать Object Lock

Для Scale-out Backup Repository (SOBR) настраиваем двухуровневую архитектуру:

# PowerShell — настройка SOBR с Performance + Capacity Tier
# Performance Tier — быстрый локальный репозиторий (SSD)
$performanceTier = Get-VBRBackupRepository -Name "Local-SSD-Repo"

# Capacity Tier — MinIO S3
$s3Account = Get-VBRObjectStorageRepository -Name "MinIO-Backups"

# Создаём SOBR
Add-VBRScaleOutBackupRepository -Name "SOBR-Production" \
  -PolicyType DataLocality \
  -Extent $performanceTier \
  -EnableCapacityTier \
  -ObjectStorageRepository $s3Account \
  -OperationalRestorePeriod 7 \
  -OverridePolicyEnabled \
  -MoveBackupsToCapacityTierAfterDays 3 \
  -EncryptionEnabled \
  -EncryptionKey (Get-VBREncryptionKey -Description "MinIO-AES256")

Схема работы: свежие бэкапы за последние 3 дня хранятся на быстром SSD-репозитории (Performance Tier) для быстрого восстановления. После 3 дней Veeam автоматически перемещает их в MinIO (Capacity Tier) с Object Lock на 30 дней. Гранулярное восстановление работает прозрачно — Veeam автоматически скачивает нужные блоки из S3.

Для выполнения требования 3-2-1 (3 копии, 2 типа носителей, 1 offsite) мы настроили bucket replication на удалённый MinIO-кластер в другом дата-центре.

# Настраиваем репликацию bucket-to-bucket между сайтами
# Добавляем alias для удалённого сайта
mc alias set dr-site https://minio-dr.promgrupp.local:9000 admin 'DR-P@ss'

# Создаём target bucket с Object Lock
mc mb dr-site/veeam-backups-replica --with-lock
mc retention set --default COMPLIANCE 30d dr-site/veeam-backups-replica

# Настраиваем bucket replication (server-side)
mc replicate add promgrupp/veeam-backups \
  --remote-bucket "https://admin:DR-P@ss@minio-dr.promgrupp.local:9000/veeam-backups-replica" \
  --replicate "delete,delete-marker,existing-objects" \
  --priority 1

# Проверяем статус репликации
mc replicate status promgrupp/veeam-backups
# Replication ARN: arn:minio:replication::...
# Status: Active
# Priority: 1
# Sync: delete,delete-marker,existing-objects

Lifecycle policies для автоматического управления хранением:

# ILM (Information Lifecycle Management) правила
# Переводим объекты старше 30 дней в класс хранения WARM
# (если MinIO настроен с tiering на более медленные диски)
mc ilm rule add promgrupp/veeam-backups \
  --transition-days 30 \
  --storage-class WARM \
  --prefix "veeam/"

# Удаляем объекты старше 180 дней
# (Object Lock с retention 30 дней уже истёк к этому моменту)
mc ilm rule add promgrupp/veeam-backups \
  --expiry-days 180 \
  --prefix "veeam/"

# Просматриваем правила
mc ilm rule ls promgrupp/veeam-backups --json

MinIO экспортирует метрики в формате Prometheus. Мы подключили их к существующему стеку мониторинга.

# prometheus.yml — добавляем MinIO
scrape_configs:
  - job_name: 'minio-cluster'
    metrics_path: /minio/v2/metrics/cluster
    scheme: https
    tls_config:
      insecure_skip_verify: true
    bearer_token: 'prometheus-bearer-token'
    static_configs:
      - targets:
        - minio1.promgrupp.local:9000
        - minio2.promgrupp.local:9000
        - minio3.promgrupp.local:9000
        - minio4.promgrupp.local:9000

  - job_name: 'minio-node'
    metrics_path: /minio/v2/metrics/node
    scheme: https
    tls_config:
      insecure_skip_verify: true
    bearer_token: 'prometheus-bearer-token'
    static_configs:
      - targets:
        - minio1.promgrupp.local:9000
        - minio2.promgrupp.local:9000
        - minio3.promgrupp.local:9000
        - minio4.promgrupp.local:9000

Ключевые метрики для дашборда Grafana:

• minio_cluster_capacity_usable_free_bytes — свободное место
• minio_s3_requests_total — количество запросов по типам (GET, PUT, DELETE)
• minio_s3_traffic_received_bytes / minio_s3_traffic_sent_bytes — трафик
• minio_cluster_health_status — здоровье кластера
• minio_node_drive_offline_total — оффлайн-диски (алерт при > 0)

Тюнинг производительности:

# Системные параметры на каждом MinIO-сервере
# /etc/sysctl.d/99-minio.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
net.core.somaxconn = 65535
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

# XFS mount options для максимальной производительности
# /etc/fstab
LABEL=disk1 /data/disk1 xfs defaults,noatime,nodiratime,logbufs=8,logbsize=256k,largeio 0 2

Результаты бенчмарка (warp benchmark tool):

Финансовое сравнение за 3 года (для 200 TB полезного объёма):

MinIO дороже ленты в капитальных затратах, но окупается за 18 месяцев за счёт отсутствия сервисного контракта и кратно быстрого восстановления. Один инцидент с восстановлением за 20 минут вместо 8 часов уже окупил разницу в стоимости — простой производства обходился «ПромГрупп» в 180 000 руб/час.

Итоговые результаты:

• Время восстановления 1 TB: с 4-12 часов до 15-25 минут
• Иммутабельные бэкапы: Object Lock COMPLIANCE на 30 дней — защита от ransomware
• Репликация: автоматическая копия на DR-сайт с RPO < 1 часа
• Мониторинг: дашборд в Grafana, алерты при отказе дисков, заполнении > 80%
• Проверка целостности: ежедневная автоматическая верификация (healing) вместо квартальной ручной проверки лент