До основного вмісту

Дедуплікація та шифрування в Proxmox Backup Server

Proxmox VE · 19.04.2026 · 5 хв читання
Ілюстрація до статті «Дедуплікація та шифрування в Proxmox Backup Server»

Proxmox Backup Server використовує просунуту систему дедуплікації на рівні блоків (4 МБ chunks), що дозволяє зберігати десятки бекапів, займаючи місце лише трохи більше одного. Це принципово відрізняє PBS від традиційних рішень резервного копіювання.

Як працює дедуплікація PBS

Процес бекапу в PBS:

  1. Клієнт читає дані VM і ділить їх на блоки по 4 МБ
  2. Обчислює SHA-256 хеш кожного блока
  3. Передає на PBS лише блоки, яких ще немає у сховищі
  4. PBS зберігає кожен унікальний блок лише один раз

Реальний приклад економії простору:

СценарійБез дедуплікаціїЗ дедуплікацією PBS
10 однакових VM (50 ГБ кожна)500 ГБ~60 ГБ
30 щоденних бекапів однієї VM1500 ГБ~80 ГБ (інкременти)
10 клонів з одного шаблону500 ГБ~55 ГБ

Перегляд статистики дедуплікації

# Через CLI
proxmox-backup-manager datastore show backup-store

# Приклад виведення:
# Total Size: 2.5 TiB
# Used: 450 GiB
# Dedup Factor: 5.8x   <- економія у 5.8 раза
# Disk I/O Stats: ...

# Через API
proxmox-backup-client snapshot list --repository pbs:backup-store

Налаштування шифрування бекапів

PBS підтримує наскрізне шифрування AES-256 GCM. Шифрування відбувається на стороні клієнта, PBS зберігає лише зашифровані блоки:

# Створити ключ шифрування
proxmox-backup-client key create /etc/pve/priv/backup.key

# Переглянути fingerprint ключа
proxmox-backup-client key show /etc/pve/priv/backup.key

# Зареєструвати ключ у конфігурації сховища
# Storage → my-pbs → Edit → Encryption Key → вибрати файл ключа

Експорт і резервна копія ключа шифрування

# Експортувати ключ у захищений формат (з паролем)
proxmox-backup-client key export-config   /etc/pve/priv/backup.key   /tmp/backup-key-export.json

# Роздрукувати ключ як QR-код для фізичного зберігання
proxmox-backup-client key paperkey /etc/pve/priv/backup.key
Правило резервування ключа: Зберігайте ключ шифрування мінімум у трьох місцях: на самому PBS (у /etc/pve/priv/), у захищеному сховищі паролів (Bitwarden, 1Password) і фізично (роздрукуйте QR-код paperkey). Втрата ключа = втрата всіх бекапів.

Garbage Collection

Щоб звільнити місце від видалених бекапів, запустіть збирання сміття:

# Запустити негайно
proxmox-backup-manager garbage-collect backup-store

# Автоматично — через вебінтерфейс
# PBS → Datastore → backup-store → GC Schedule → встановити cron

Перевірка цілісності бекапів

# Верифікувати конкретний бекап
proxmox-backup-client verify pbs:backup-store:vm/100/...

# Запустити повну верифікацію датастора
proxmox-backup-manager verify backup-store --verify-outdated 1

# Встановити розклад верифікації
# PBS → Datastore → Verify Schedule

Помилки дедуплікації та шифрування

Три помилки, з якими стикаються під час верифікації та відновлення зашифрованих дедуплікованих бекапів.

verify backup-store:vm/100/2025-03-15T01:00:00Z failed: chunk 3a5f9c... missing
TASK ERROR: unable to load encryption key: wrong password or corrupted key file
TASK ERROR: garbage collection: not enough space to complete phase1
  • chunk ... missing: один із блоків у chunk store пошкоджений або видалений вручну — через спільне зберігання блоків це може вплинути на декілька бекапів одразу. Відновіть датастор із резервної копії диска PBS, не видаляйте файли з chunk store напряму.
  • wrong password or corrupted key file: вказано не той файл ключа шифрування або ключ пошкоджено під час копіювання. Звірте fingerprint ключа командою proxmox-backup-client key show з тим, що використовувався під час створення бекапу.
  • not enough space to complete phase1: збиранню сміття потрібне тимчасове вільне місце для перебудови індексу — якщо датастор заповнений вщент, GC не може завершитися. Звільніть місце, видаливши старі бекапи вручну перед повторним запуском GC.

Коли економія місця менша за очікувану

Дедуплікація PBS ефективна не для всіх типів даних.

  • Уже стиснуті або зашифровані дані всередині VM (відео, архіви, зашифровані диски) майже не дедуплікуються — такі блоки виглядають як випадкові дані, коефіцієнт економії близький до 1.
  • VM з інтенсивним перезаписом великих файлів по всій їхній довжині (активні бази даних) — кожен бекап створює багато нових унікальних блоків замість повторного використання старих.
  • Шифрування на боці клієнта збільшує економію лише між бекапами з одним і тим самим ключем — якщо у різних VM різні ключі, однакові за вмістом блоки шифруються по-різному і не збігаються.

Перевірка результату

# Коефіцієнт дедуплікації та зайняте місце
proxmox-backup-manager datastore show backup-store

# Повна верифікація конкретного бекапу
proxmox-backup-client verify pbs:backup-store:vm/100/2025-03-15T01:00:00Z

# Переконатися, що ключ шифрування підходить до бекапу
proxmox-backup-client key show /etc/pve/priv/backup.key

Якщо verify завершується без помилок, а fingerprint ключа збігається з очікуваним — бекап цілий і придатний для відновлення. Про встановлення та структуру PBS — у статті Proxmox Backup Server: встановлення.

Часті питання

Що станеться, якщо втратити ключ шифрування бекапів PBS?

Ключ шифрування існує лише у клієнта — сам Proxmox Backup Server способу його відновити не зберігає. Без ключа зашифровані блоки виглядають як випадковий набір даних, і відновити віртуальну машину з такого бекапу стає неможливо. Тому ключ варто зберігати одразу у кількох незалежних місцях: на сервері, у менеджері паролів і в роздрукованому вигляді, а не в єдиній копії.

Чому однакові дані в різних VM не дають економії під час дедуплікації?

Якщо різні VM мають власні ключі шифрування, однакові за змістом блоки перетворюються на різні послідовності байтів і перестають збігатися між собою. PBS порівнює блоки вже після шифрування, тому справжня економія місця виникає лише між бекапами, зашифрованими одним і тим самим ключем. Спільний ключ для однотипних VM повертає дедуплікації очікувану ефективність.

Як часто варто запускати Garbage Collection вручну?

Зазвичай запускати Garbage Collection вручну не потрібно — зручніше налаштувати розклад прямо в датасторі, і система сама звільнятиме місце від видалених бекапів. Ручний запуск стане у пригоді перед перевіркою вільного місця або одразу після масового видалення старих копій, коли чекати на черговий запуск за розкладом незручно, а місце потрібне швидше.

Чи можна звільнити місце, видаливши файли бекапів прямо зі сховища на диску?

Ні, видаляти файли з chunk store прямо небезпечно — один і той самий блок може використовуватися одразу кількома бекапами через дедуплікацію, і видалення файла здатне пошкодити інші знімки. Правильний шлях — видалити непотрібні бекапи через клієнт або вебінтерфейс PBS, а потім запустити Garbage Collection, яка безпечно прибере блоки, на які вже ніщо не посилається.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці