Verify Proxmox container mount data beyond the restored configuration

Bottom line: Do not accept a restored mount definition as evidence that its files were restored. Map bind and device mounts to their separate protection and recovery procedures before rehearsing the container restore.

Source fact: what the authority says

The Proxmox Container Toolkit guide says bind and device mount points are never backed up; the simple restore step restores their configuration options rather than their files. The guide expects those mount points to be protected by another mechanism or intentionally excluded from backup. Simple restore uses backed-up mount configuration when neither rootfs nor optional mpX parameters are explicitly set. Specifying rootfs switches to advanced restore mode, which ignores the archive’s rootfs and mpX configuration and uses the explicitly supplied options.

What the source does not establish

This article concerns the documented LXC restore and mount-data boundary, not the separate Proxmox Backup host-file archive procedure. It does not establish application consistency or imply that every mount point is excluded from a container backup.

Applicability questions

• Which mounts are storage volumes and which are bind or device mounts?
• Where is the independent backup for each required bind or device data path?
• Will the restore use backed-up mount definitions or explicit advanced-mode options?
• What harmless markers can distinguish configuration recovery from actual file recovery?

DSE recommendation: controlled next steps

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

DSE recommends a mount recovery map with container path, host or device dependency, configuration source and protected-data source. Mark intentional exclusions plainly and have the application owner accept them. Do not fill the data-protection column merely with the container backup job name.

Choose the restore mode deliberately before preparing the command or interface operation. For an advanced-mode plan, review every explicitly supplied mount option against the approved target layout. Keep a separate record of the archive’s original layout so the operator can explain each intentional difference without guessing during recovery.

Plan independent restoration of the required external data into an isolated destination. Reconcile its recovery point with the container’s recovery point and ask the application owner how mismatched dates will be handled. Keep the original host paths and live devices outside the rehearsal’s writable scope.

Use a proposed disposable container with one ordinary backed-up volume and one independently protected bind-mounted directory. Place differently named harmless markers in both. Require the reviewer to predict which procedure will restore each marker before executing the approved trial.

Verification and evidence

Proposed verification: inspect the recovered container configuration and compare each mount with the recovery map. Check the exact source of the external data path before starting the test workload. Restore the external marker through its separately planned procedure and compare its content with the saved reference.

Record which recovery operation supplied each file instead of treating a successful container start as the complete result. In the isolated trial, investigate an absent external path or marker without reconnecting a live production directory to make the test pass. Accept the configuration, data coverage and application check as separately observed outcomes.

Official references

• Proxmox — Proxmox Container Toolkit — official product documentation; confirm the installed release and configuration.

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