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

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

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

Проблема была двойной. Во-первых, бэкапы 40 VM через встроенный vzdump в Proxmox занимали 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, 4x 8 ТБ HDD в 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

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

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

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

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

PBS использует content-defined chunking — данные разбиваются на блоки (chunks) фиксированного размера (по умолчанию 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% overhead к размеру бэкапа и ~3% к времени. При этом даже если PBS-сервер будет скомпрометирован, данные останутся нечитаемыми без ключа, хранящегося на Proxmox VE.

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 поддерживает синхронизацию между 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

Благодаря дедупликации PBS отправляет на offsite только новые уникальные блоки. Ежедневная синхронизация после первого полного копирования занимает 15-20 минут вместо часов.

Мониторинг 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% меньше места, при этом хранятся в 2 раза дольше. Offsite-копия обеспечивает соответствие требованиям регуляторов. «МедИнфоСистем» успешно прошла проверку Росздравнадзора, предъявив отчёты о верификации бэкапов и результаты тестового восстановления.

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

Нет. PBS предназначен в первую очередь для Proxmox VE, но клиент proxmox-backup-client можно установить на любой Linux-сервер для бэкапа файлов и директорий. Также PBS поддерживает бэкап хостов через агент. Однако интеграция с Proxmox VE — основное преимущество: бэкап VM и контейнеров происходит «из коробки» через GUI, с поддержкой snapshot, live backup и быстрого восстановления. Для гетерогенных сред (VMware, Hyper-V) PBS не подходит — рассмотрите Veeam или Bacula.

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

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

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

PBS поддерживает экспорт в tape (ленточные накопители) через утилиту proxmox-tape-backup. Это позволяет реализовать долгосрочное архивирование на LTO-ленты — дешёвый носитель для хранения данных годами. В нашем кейсе мы использовали offsite-синхронизацию вместо лент, но для компаний с требованиями хранения данных 10+ лет (медицина, финансы) tape backup через 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 интеграция