Separate Proxmox encrypted chunk checks from plaintext recovery proof

Bottom line: Keep the server’s encrypted-chunk check separate from proof of readable recovered data. Preserve the corresponding key and intact index/chunk set through the approved recovery process.

Source fact: what the authority says

The Proxmox Backup Server technical overview says a server without the encryption key cannot verify an encrypted chunk against the original plaintext checksum; it checks CRC-32 instead. Index files contain an ordered list of references to the chunks needed to rebuild a file. The recover subcommand can restore specific snapshot files without a running server if intact indexes and chunks are available, with the corresponding key required for an encrypted backup. The overview recommends trying recovery with CRC checks enabled before considering the skip-CRC option.

What the source does not establish

This article concerns the documented encrypted-chunk and recovery prerequisites. It does not provide a complete disaster-recovery procedure or treat a server check as proof of application consistency and recovery time.

Applicability questions

• Which encrypted snapshots and recovery files are actually required?
• Who can retrieve the corresponding key through an authorized process?
• Where are the complete matching indexes and chunks retained?
• What harmless recovered content and separate application checks will demonstrate the required result?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends separate acceptance entries for the server’s integrity observation and readable recovered content. Record which snapshot and check the server reported without relabeling it as a plaintext comparison. Ask the recovery owner to name the exact files and key reference required for a bounded restore rehearsal.

Build a controlled recovery inventory linking the selected indexes and chunks to their corresponding encrypted backup and key custody record. Keep secret key material out of ordinary reports and screenshots. Have another authorized operator confirm that the recovery instructions identify the required items without relying on the creator’s memory.

Prepare a disposable recovery destination and a harmless known file chosen before the exercise. Use the documented recovery branch with CRC checking enabled for the initial attempt. Keep any proposal to skip that check outside the ordinary procedure until a separate investigation and recovery authority has reviewed its purpose and consequences.

Define a readable-content comparison and any required application consistency assessment separately. Agree who will evaluate a missing object, key-retrieval failure or unreadable recovered file. Preserve the original backup evidence and avoid manually modifying the source chunk population in an attempt to force the expected rehearsal result.

Verification and evidence

Proposed verification: retain the actual server check report, then have the authorized recovery operator follow the written inventory on the disposable destination. Record the selected snapshot, index and controlled key reference, recovery messages and observed result. Keep the key itself out of the retained evidence package.

Read and compare the agreed harmless recovered content using its previously defined reference. Record actual timing only if timing was part of the exercise; do not infer application consistency from a readable file. Have the recovery owner reconcile failures and accept the bounded result independently of the server’s earlier CRC observation.

Official references

• Proxmox — Technical Overview — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.