Бэкапы 40 виртуальных машин за 6 часов: Proxmox Backup Server с дедупликацией

Задача клиента: бэкапы пожирают хранилище

В ноябре 2025 года к нам в АйТи Фреш обратилась компания «МедИнфоСистем» из Новосибирска — разработчик ПО для медицинских учреждений. Они делают систему электронных медицинских карт, развёрнутую на кластере Proxmox VE из 3 узлов. На кластере крутятся 40 виртуальных машин: серверы приложений, базы данных PostgreSQL, тестовые стенды и CI/CD-инфраструктура.

Боль была двойная. Бэкапы 40 VM через штатный vzdump тянулись 6 часов и заканчивались уже утром — прямо под начало рабочей нагрузки. Хранилище тоже трещало по швам: полные бэкапы за 7 дней съедали 14 ТБ из 18 ТБ, то есть 78% всего места. Каждый месяц — ручная зачистка старых копий. И вот однажды администратор в спешке удалил единственную рабочую копию тестового стенда. Просто удалил. Без возможности восстановить.

«Мы медицинская компания, нас проверяют регуляторы. Потерять данные — это не просто неудобство, это штраф и потенциальная уголовная ответственность. Но текущая система бэкапов — бомба замедленного действия» — CTO «МедИнфоСистем».

Аудит текущей системы бэкапов

Мы зашли в Proxmox-кластер и посмотрели, что там вообще происходит:

# Смотрим текущие backup jobs
pvesh get /cluster/backup --output-format json-pretty

# 3 задачи: ночной бэкап для каждого узла
# Mode: snapshot (vzdump --mode snapshot)
# Compress: zstd
# Storage: local-zfs (на каждом узле локально!)

# Размер бэкапов по узлам:
for node in pve1 pve2 pve3; do
  echo "=== $node ==="
  ssh root@$node "du -sh /var/lib/vz/dump/"
done
# pve1: 5.2T /var/lib/vz/dump/
# pve2: 4.8T /var/lib/vz/dump/
# pve3: 4.1T /var/lib/vz/dump/
# ИТОГО: 14.1 ТБ бэкапов

# Время последнего бэкапа:
grep "Backup job" /var/log/pvedaemon.log | tail -1
# Backup job finished successfully at 07:42
# Начался в 01:00, шёл 6 часов 42 минуты

# Retention: 7 daily, но без автоматической ротации!
# Админ удалял вручную через GUI

Картина оказалась неутешительной:

  • Нет дедупликации — каждый полный бэкап хранит все данные, включая неизменённые блоки
  • Бэкапы локальные — хранятся на том же узле, что и VM. Потеря узла = потеря бэкапов
  • Нет offsite-копии — вообще ни одной копии вне основной площадки
  • Нет шифрования — бэкапы с медицинскими данными лежат в открытом виде
  • Нет верификации — никто ни разу не проверял, восстанавливаются ли эти бэкапы вообще

Почему Proxmox Backup Server

Proxmox Backup Server (PBS) — это специализированное решение для бэкапов от тех же ребят, что написали Proxmox VE. Главное, за что мы его выбираем в таких проектах — дедупликация на уровне блоков фиксированного размера:

Возможностьvzdump (текущий)PBS
ДедупликацияНетДа, fixed-size chunks
Инкрементальные бэкапыНет (всегда full)Да, на уровне блоков
Шифрование (client-side)НетAES-256-GCM
Верификация целостностиРучнаяАвтоматические verify jobs
Remote sync (offsite)rsync вручнуюВстроенный sync job
Prune policiesРучная очисткаАвтоматическая по политике
Web GUIЧерез Proxmox VEСобственный интерфейс

На бумаге PBS закрывал все проблемы «МедИнфоСистем» разом. Дедупликация режет объём хранения, инкрементальные бэкапы укладываются в ночное окно, шифрование и remote sync дают и защиту данных, и offsite-копию. Проверим на практике.

Установка Proxmox Backup Server

Под PBS мы выделили отдельный физический сервер: Dell PowerEdge T340, Xeon E-2224, 32 ГБ RAM, четыре диска по 8 ТБ в ZFS RAIDZ1 — итого 24 ТБ полезного места. Сервер подключён к кластеру Proxmox по выделенному 10GbE-линку, чтобы бэкапный трафик не мешал продуктиву.

Установка PBS и подготовка хранилища

Скачиваем ISO-образ PBS и устанавливаем:

# Скачиваем Proxmox Backup Server
wget https://enterprise.proxmox.com/iso/proxmox-backup-server_3.2-1.iso

# Записываем на USB
dd if=proxmox-backup-server_3.2-1.iso of=/dev/sdb bs=4M status=progress

# Установка через графический мастер:
# Filesystem: ext4 (для системного диска — отдельный SSD)
# Hostname: pbs.medinfoSystem.local
# IP: 10.10.1.50/24
# Gateway: 10.10.1.1
# DNS: 10.10.1.1

# После установки — настраиваем free-репозиторий (без подписки):
ssh root@10.10.1.50

# Отключаем enterprise-репозиторий
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pbs-enterprise.list

# Добавляем no-subscription
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > \
  /etc/apt/sources.list.d/pbs-no-subscription.list

apt update && apt full-upgrade -y

Подготавливаем ZFS-пул для хранения бэкапов:

# Создаём ZFS RAIDZ1 из 4 дисков по 8 ТБ
zpool create -f -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O dnodesize=auto \
  backuppool raidz1 /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Проверяем пул
zpool status backuppool
#   pool: backuppool
#  state: ONLINE
# config:
#   NAME        STATE     READ WRITE CKSUM
#   backuppool  ONLINE       0     0     0
#     raidz1-0  ONLINE       0     0     0
#       sdb     ONLINE       0     0     0
#       sdc     ONLINE       0     0     0
#       sdd     ONLINE       0     0     0
#       sde     ONLINE       0     0     0

# Создаём dataset для PBS
zfs create backuppool/datastore
zfs set recordsize=64k backuppool/datastore  # оптимально для PBS chunks

df -h /backuppool/datastore
# Filesystem                    Size  Used  Avail  Use%
# backuppool/datastore           22T   128K   22T    1%

Создание Datastore в PBS

Datastore — базовая единица хранения в PBS. Создаём через CLI:

# Создаём директорию для datastore
mkdir -p /backuppool/datastore/medinfosys

# Создаём datastore через proxmox-backup-manager
proxmox-backup-manager datastore create medinfosys \
  --path /backuppool/datastore/medinfosys \
  --comment "МедИнфоСистем — бэкапы 40 VM"

# Проверяем
proxmox-backup-manager datastore list
# ┌─────────────┬──────────────────────────────────────┬─────────────────────────────────────┐
# │ name        │ path                                  │ comment                             │
# ├─────────────┼──────────────────────────────────────┼─────────────────────────────────────┤
# │ medinfosys  │ /backuppool/datastore/medinfosys      │ МедИнфоСистем — бэкапы 40 VM       │
# └─────────────┴──────────────────────────────────────┴─────────────────────────────────────┘

# Настраиваем garbage collection (очистка неиспользуемых chunks)
proxmox-backup-manager datastore update medinfosys \
  --gc-schedule "Sat 03:00"

# Структура datastore после первого бэкапа:
# /backuppool/datastore/medinfosys/
# ├── .chunks/              # дедуплицированные блоки данных
# │   ├── 0000/             # 256 поддиректорий для шардинга
# │   ├── 0001/
# │   └── ...
# ├── vm/100/               # бэкапы VM 100
# │   ├── 2026-01-15T01:00:00Z/
# │   └── 2026-01-16T01:00:00Z/
# └── vm/101/               # бэкапы VM 101

Интеграция PBS с Proxmox VE и настройка заданий

Теперь нужно связать PBS-сервер с кластером Proxmox VE, чтобы VM бэкапились на него автоматически.

Подключение PBS как storage в Proxmox VE

На каждом узле Proxmox VE добавляем PBS-хранилище:

# На любом узле Proxmox VE:
# Datacenter → Storage → Add → Proxmox Backup Server

# Или через CLI:
pvesm add pbs pbs-medinfosys \
  --server 10.10.1.50 \
  --port 8007 \
  --datastore medinfosys \
  --username backup@pbs \
  --password "Str0ngP@ssw0rd" \
  --fingerprint "AA:BB:CC:..." \
  --content backup

# Проверяем подключение
pvesm status
# Name              Type     Status  Total       Used      Available
# pbs-medinfosys    pbs      active  23068672    0         23068672

# Создаём API-токен для автоматизации (безопаснее пароля)
proxmox-backup-manager user create backup@pbs
proxmox-backup-manager acl update / Datastore.Backup --auth-id backup@pbs
proxmox-backup-manager user generate-token backup@pbs autojob
# Token: backup@pbs!autojob=d4f5e6a7-...

Создание backup jobs с расписанием

Для всех 40 VM создаём задания бэкапирования — разбиваем по группам в зависимости от приоритета:

# Datacenter → Backup → Add

# Job 1: Критичные VM (БД, серверы приложений) — каждый день в 01:00
# Storage: pbs-medinfosys
# Schedule: 01:00
# Selection mode: Include selected VMs
# VMs: 100,101,102,103,104,105,110,111,112
#   (PostgreSQL primary, replicas, app servers)
# Mode: Snapshot
# Compression: ZSTD
# Notification: Always
# Notes template: {{guestname}} daily backup

# Job 2: Тестовые стенды и CI/CD — каждый день в 02:00
# Storage: pbs-medinfosys
# Schedule: 02:00
# VMs: 200-230 (тестовые стенды, GitLab, Jenkins)
# Mode: Snapshot
# Compression: ZSTD

# Job 3: Инфраструктурные VM — 2 раза в неделю
# Storage: pbs-medinfosys
# Schedule: mon,thu 03:00
# VMs: 300-310 (DNS, DHCP, мониторинг)
# Mode: Snapshot

# Через CLI создание backup job:
pvesh create /cluster/backup \
  --id job-critical-daily \
  --schedule "01:00" \
  --storage pbs-medinfosys \
  --vmid "100,101,102,103,104,105,110,111,112" \
  --mode snapshot \
  --compress zstd \
  --mailnotification always \
  --mailto admin@medinfoSystem.ru \
  --notes-template "{{guestname}} - daily PBS backup" \
  --enabled 1

Первый полный бэкап 40 VM занял 3 ТБ. Каждый следующий инкрементальный — в среднем 120 ГБ, это около 4% от полного. Дедупликация PBS хранит только изменённые блоки, и это сразу чувствуется на объёмах.

Дедупликация, шифрование и политики хранения

Для медицинской компании критичны три вещи: экономия места, защита данных и предсказуемое хранение. Разбираем каждую.

Как работает дедупликация в PBS

PBS использует content-defined chunking — данные режутся на блоки по 4 МБ (дефолт), каждый блок хэшируется. Если блок с таким хэшем уже есть в datastore, повторно он не сохраняется:

# Смотрим статистику дедупликации после 2 недель работы
proxmox-backup-manager datastore list --output-format json-pretty

# Результат:
# {
#   "name": "medinfosys",
#   "used": 4189184000000,     # ~3.8 ТБ используется
#   "total": 24000000000000,   # ~22 ТБ всего
#   "avail": 19810816000000,
#   "gc-status": {
#     "disk-chunks": 978432,
#     "disk-bytes": 3891200000000,
#     "dedup-factor": 3.73    # ← фактор дедупликации!
#   }
# }

# Dedup factor 3.73 означает:
# Без дедупликации данные заняли бы 3.8 ТБ × 3.73 = 14.2 ТБ
# С дедупликацией: 3.8 ТБ — экономия 73%!

# Сравним:
# БЫЛО: 14.1 ТБ за 7 дней vzdump (без дедупликации)
# СТАЛО: 3.8 ТБ за 14 дней PBS (с дедупликацией)
# При этом хранится 14 дней бэкапов вместо 7!

# Смотрим размер chunks на диске
du -sh /backuppool/datastore/medinfosys/.chunks/
# 3.6T /backuppool/datastore/medinfosys/.chunks/

# Типичный размер инкрементального бэкапа одной VM:
proxmox-backup-client list --repository backup@pbs@10.10.1.50:medinfosys
# vm/100/2026-01-20T01:00:05Z 235.14 GiB (full)
# vm/100/2026-01-21T01:00:03Z 8.72 GiB  (incremental — только изменённые chunks)

Здесь есть важный момент, который часто путают. PBS не делает «инкрементальные бэкапы» в классическом смысле. Каждый бэкап — полноценный snapshot. Просто благодаря дедупликации на диск пишутся только уникальные блоки. Практический итог: восстановление из любой точки занимает одинаковое время — никаких цепочек инкрементов, которые нужно «накатывать».

Client-side шифрование

Медицинские данные — это отдельная история. PBS шифрует на стороне клиента: данные уходят на сервер уже зашифрованными, и даже администратор PBS-сервера не прочитает содержимое бэкапов:

# На узле Proxmox VE генерируем ключ шифрования
proxmox-backup-client key create \
  --kdf scrypt \
  /etc/pve/priv/pbs-encryption-key.json
# Enter new password: ********
# Key saved to /etc/pve/priv/pbs-encryption-key.json

# КРИТИЧНО: сохраняем ключ в безопасное место!
# Без ключа восстановить данные НЕВОЗМОЖНО
cp /etc/pve/priv/pbs-encryption-key.json /root/backup-key-KEEP-SAFE.json

# Создаём paperkey (бумажный ключ) для сейфа
proxmox-backup-client key paperkey \
  /etc/pve/priv/pbs-encryption-key.json \
  --output-format text > /root/paperkey.txt
# Распечатать и положить в сейф!

# Добавляем ключ в конфигурацию storage:
pvesm set pbs-medinfosys \
  --encryption-key /etc/pve/priv/pbs-encryption-key.json

# Теперь все бэкапы автоматически шифруются AES-256-GCM
# Проверяем:
proxmox-backup-client snapshot list \
  --repository backup@pbs@10.10.1.50:medinfosys
# vm/100/2026-01-22T01:00:03Z  encrypted: true  verify: ok

Шифрование добавляет примерно 5% к размеру бэкапа и около 3% ко времени. Зато если PBS-сервер окажется скомпрометирован — данные останутся нечитаемыми. Ключ хранится на Proxmox VE, а не на PBS.

Prune policies: автоматическая ротация

Ручная зачистка старых бэкапов — это путь к инцидентам, что «МедИнфоСистем» уже испытала на себе. Настраиваем политики хранения (prune policies) и забываем об этой проблеме:

# Через PBS Web GUI: Datastore → medinfosys → Prune & GC
# Или через CLI:

# Политика хранения для production VM:
proxmox-backup-manager datastore update medinfosys \
  --keep-last 3 \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 6 \
  --keep-yearly 1

# Расшифровка:
# keep-last 3    — всегда хранить 3 последних бэкапа
# keep-daily 14  — 1 бэкап в день за последние 14 дней
# keep-weekly 8  — 1 бэкап в неделю за последние 8 недель
# keep-monthly 6 — 1 бэкап в месяц за последние 6 месяцев
# keep-yearly 1  — 1 бэкап за последний год

# Автоматический prune по расписанию:
proxmox-backup-manager datastore update medinfosys \
  --prune-schedule "daily 04:00"

# Проверяем, что политика работает — dry-run:
proxmox-backup-client prune \
  --repository backup@pbs@10.10.1.50:medinfosys \
  --keep-daily 14 --keep-weekly 8 --keep-monthly 6 \
  --dry-run vm/100
# keep vm/100/2026-01-22T01:00:03Z (last, daily, weekly)
# keep vm/100/2026-01-21T01:00:03Z (daily)
# ...
# remove vm/100/2026-01-05T01:00:03Z (no match)

Verify Jobs и тестирование восстановления

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

Автоматическая верификация бэкапов

Verify job проходит по каждому chunk в бэкапе и сверяет хэши:

# Создаём verify job — проверка всех бэкапов раз в неделю
proxmox-backup-manager verify-job create weekly-verify \
  --store medinfosys \
  --schedule "Sun 05:00" \
  --ignore-verified true \
  --outdated-after 7

# ignore-verified true — не перепроверяем уже проверенные
# outdated-after 7 — перепроверяем, если прошло 7 дней

# Ручной запуск верификации:
proxmox-backup-manager verify-job run weekly-verify

# Результат в логах PBS:
# Starting verification of datastore medinfosys
# Verifying vm/100/2026-01-22T01:00:03Z
#   drive-scsi0.img.fidx: 58432 chunks verified
#   qemu-server.conf.blob: 1 chunk verified
# ...
# Verification complete: 40 snapshots verified, 0 errors

# Мониторинг через API:
curl -s https://10.10.1.50:8007/api2/json/admin/verify \
  -H "Authorization: PBSAPIToken=backup@pbs!monitor:token123" | \
  jq '.data[] | {id, "last-run-state": ."last-run-state"}'
# {"id": "weekly-verify", "last-run-state": "ok"}

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

Раз в месяц мы проводим drill — берём случайную VM и восстанавливаем её из бэкапа на тестовый узел:

# Восстанавливаем VM 102 (PostgreSQL replica) на тестовый узел pve3
# Через GUI: pve3 → local storage → PBS → Restore

# Или через CLI:
qmrestore pbs:backup/vzdump-qemu-102-2026_01_22-01_00_03.vma.zst 902 \
  --storage local-zfs \
  --unique true \
  --target-node pve3

# unique true — генерирует новый MAC-адрес, чтобы не конфликтовать
# VM 902 — временный ID для тестового восстановления

# Время восстановления:
# VM 102 (PostgreSQL, 200 GB диск) — восстановлена за 8 минут
# Через 10GbE: ~400 MB/s read from PBS

# Проверяем работоспособность:
qm start 902
ssh root@10.10.1.x "systemctl status postgresql && psql -c 'SELECT count(*) FROM patients;'"
# postgresql.service — active (running)
# count: 1847293 ✓

# Удаляем тестовую VM после проверки
qm stop 902 && qm destroy 902

Каждый drill фиксируется в отчёте: дата, какая VM восстанавливалась, сколько времени заняло, результат проверки работоспособности. Этот документ мы передаём регулятору при проверке — и вопросов обычно не возникает.

Remote Sync: offsite-копия бэкапов

Правило 3-2-1 знакомо всем, кто хоть раз терял данные: 3 копии, на 2 разных носителях, 1 — offsite. PBS закрывает последний пункт нативно — серверы умеют синхронизироваться между собой, и offsite-бэкап настраивается без сторонних костылей.

Настройка Remote и Sync Job

«МедИнфоСистем» арендовал отдельный сервер в другом московском ДЦ и поднял на нём PBS. Дальше — настраиваем синхронизацию между площадками:

# На основном PBS (Новосибирск):
# Configuration → Remotes → Add Remote

proxmox-backup-manager remote create moscow-offsite \
  --host 185.xx.xx.xx \
  --port 8007 \
  --auth-id sync@pbs!synctoken \
  --password "SyncP@ssw0rd" \
  --fingerprint "DD:EE:FF:..."

# Создаём Sync Job: ежедневная синхронизация в Москву
proxmox-backup-manager sync-job create daily-offsite \
  --store medinfosys \
  --remote moscow-offsite \
  --remote-store offsite-medinfosys \
  --schedule "daily 06:00" \
  --remove-vanished true

# remove-vanished true — удалять на remote то, что удалено 
#   локально после prune (чтобы offsite тоже ротировался)

# Первая синхронизация:
proxmox-backup-manager sync-job run daily-offsite
# Starting sync to remote "moscow-offsite"
# Syncing medinfosys → offsite-medinfosys
# Transferred: 3.8 TiB (full initial sync)
# Duration: 4h 12m (через интернет 100 Мбит)

# Последующие синхронизации — только новые chunks:
# Transferred: 120 GiB
# Duration: 18 minutes

Первая синхронизация шла несколько часов — это нормально. Зато каждая следующая занимает 15-20 минут: PBS гонит offsite только новые уникальные блоки, которых ещё нет на удалённой стороне. Дедупликация работает и здесь.

Мониторинг PBS через Prometheus

PBS из коробки отдаёт метрики для Prometheus. Добавляем сервер в существующий стек мониторинга:

# PBS экспортирует метрики на порту 8007 в формате Prometheus
# /etc/prometheus/prometheus.yml
scrape_configs:
  - job_name: 'pbs'
    scheme: https
    tls_config:
      insecure_skip_verify: true
    bearer_token: 'PBSAPIToken=monitor@pbs!prometheus:token456'
    static_configs:
      - targets: ['10.10.1.50:8007']
    metrics_path: '/api2/json/nodes/localhost/status'

# Ключевые метрики для мониторинга:
# pbs_datastore_used_bytes — использованное место
# pbs_datastore_available_bytes — доступное место
# pbs_datastore_dedup_factor — фактор дедупликации
# pbs_datastore_snapshot_count — количество снапшотов
# pbs_gc_status_removed_chunks — chunks удалённых при GC

# Grafana Dashboard — алерты:
# 1. Datastore usage > 80% → Warning
# 2. Verify job failed → Critical
# 3. Sync job failed → Critical  
# 4. Last backup older than 26 hours → Warning
# 5. Dedup factor < 2.0 → Warning (что-то не так)

Результаты внедрения

Через месяц после миграции на PBS мы сели и честно сравнили цифры со старой системой. Вот что получилось:

МетрикаДо (vzdump)После (PBS)
Время бэкапа 40 VM6 ч 42 мин1 ч 35 мин
Объём хранения (14 дней)14.1 ТБ (7 дней!)3.8 ТБ (14 дней)
Фактор дедупликации1.0 (нет)3.73x
Глубина хранения7 дней14 daily + 8 weekly + 6 monthly
Offsite-копияОтсутствуетЕжедневная синхронизация в Москву
ШифрованиеНетAES-256-GCM (client-side)
ВерификацияНе проводиласьЕженедельная автоматическая
Время восстановления VM35 мин (с локального)8 мин (через 10GbE)

Бэкапы ускорились в 4 раза, место на дисках сократилось на 73% — при этом срок хранения вырос вдвое. Offsite-копия закрыла требования регуляторов. «МедИнфоСистем» прошла проверку Росздравнадзора без проблем: инспекторам показали отчёты верификации и результаты тестового восстановления — вопросов не возникло.

Часто задаваемые вопросы

Нет, не только. PBS создавался под Proxmox VE, и именно здесь он работает идеально: бэкап VM и контейнеров через GUI, snapshot, live backup, быстрое восстановление — всё из коробки. Но клиент proxmox-backup-client ставится на любой Linux-сервер и бэкапит файлы и директории точно так же. Агент позволяет снимать бэкапы с хостов. Другой вопрос — гетерогенные среды. Если у вас VMware или Hyper-V, PBS не ваш инструмент. Смотрите в сторону Veeam или Bacula.

Клиенты иногда спрашивают: а вдруг дедупликация что-то перепутает и восстановит не те данные? Понимаю опасение, но на практике это исключено. Каждый chunk идентифицируется хэшем SHA-256 — вероятность коллизии 1 к 2^256, это число с 77 нулями. Каждый блок хранится с контрольной суммой и проверяется при чтении. Verify jobs перечитывают все chunks и сверяют хэши повторно. За годы работы PBS в тысячах организаций не зафиксировано ни одного случая потери данных из-за дедупликации. Ни одного.

Вот это — реально критичный момент. Потеряли ключ шифрования — данные пропали навсегда. PBS использует client-side encryption: ключ живёт только на стороне Proxmox VE, сервер хранит зашифрованные блоки и расшифровать их без ключа физически не может. Именно поэтому мы всегда делаем paperkey — распечатываем бумажную версию ключа и кладём в физический сейф. Плюс копия в защищённом менеджере паролей: Vaultwarden или HashiCorp Vault. В нашем кейсе ключ хранится в трёх местах одновременно — на узлах Proxmox VE, в офисном сейфе и в облачном Vault. Избыточно? Зато ни разу не подводило.

Запустить PBS можно и на скромном железе — 2 ядра CPU и 2 ГБ RAM как минимум. Но для реальной нагрузки в 40+ VM картина другая: 4 ядра, 16-32 ГБ RAM под кеш дедупликации, SSD под систему и ZFS RAIDZ1/RAIDZ2 на HDD под данные. Сеть — отдельная история. 1GbE — это уже терпимо, но 10GbE меняет ощущения кардинально, особенно когда одновременно бэкапятся десятки машин. Для среднего бизнеса ZFS RAIDZ1 из четырёх дисков по 8 ТБ даёт хороший баланс между ёмкостью и надёжностью.

PBS умеет работать с ленточными накопителями через утилиту proxmox-tape-backup. LTO-ленты — дешёвый способ хранить данные годами, и для медицины или финансов с требованиями хранения 10+ лет это реально интересный вариант. В нашем кейсе мы обошлись offsite-синхронизацией, но если бы клиент работал в финансовом секторе — скорее всего добавили бы ленты. Приятная деталь: PBS пишет на ленту уже дедуплицированные данные, так что ёмкость расходуется экономно.

Нужна помощь с настройкой?

Если хотите внедрить PBS без лишних экспериментов — команда АйТи Фреш разворачивала подобные системы не один десяток раз. 15+ лет в деле, обслуживание от 15 000 ₽/мес.

📞 Связаться с нами
#Proxmox Backup Server настройка#PBS дедупликация бэкапов#Proxmox Backup Server установка#PBS datastore настройка#PBS шифрование бэкапов#PBS prune policy ротация#PBS remote sync offsite#Proxmox VE backup PBS интеграция