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

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

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

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

Клиент читает данные VM и делит их на блоки по 4 МБ
Вычисляет SHA-256 хеш каждого блока
Передаёт на PBS только блоки, которых ещё нет в хранилище
PBS хранит каждый уникальный блок один раз

Реальный пример экономии пространства:

Сценарий	Без дедупликации	С PBS дедупликацией
10 одинаковых VM (50 ГБ каждая)	500 ГБ	~60 ГБ
30 ежедневных бэкапов одной VM	1500 ГБ	~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 поддерживает end-to-end шифрование 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, которая безопасно уберёт блоки, на которые больше ничего не ссылается.