[SOLVED] Unexpected use of .pxarexclude broke my container backup

[leesteken]

I just want to share the following story to prevent other people from making the same mistake:

I create a (unprivileged) Ubuntu (18.04) container to mimic a physical computer and to learn how to run proxmox-backup-client on another system with an external Proxmox Backup Server. This went very well using some tips from this forum. One of the experiments included writing a/.pxarexclude to exclude the Ubuntu system folders (like /usr, /bin and of cource /dev, /proc etc.) to reduce the size and time of the backup. This worked very well inside the container and is now happily working on the physical computer with the proxmox-backup-client running from a cron job.

This Ubuntu container was (and is) regularly backed up as part of my Proxmox VE vzdump backup regime. Some time later, I was again experimenting within the container and wanted to undo what I had just done by restoring the whole container from backup. This gave a not too serious error about unable to detect the architecture during restore. However, it gave unexpected fatal errors when starting the container. I found that this broken container is missing the Ubuntu system folders like /bin, which explains the earlier errors and the failure to start.

It turns out that the (outside) Proxmox VE vzdump backup also respected the /.pxarexclude in the container, which was only intended for the proxmox-backup-client running inside the container.

This was rather unexpected to me, as I assumed that the whole container was backed up by Proxmox VE like with VMs, but explainable in hindsight. Is this a bug or a feature?

 

[t.lamprecht]

Hi!

This was rather unexpected to me, as I assumed that the whole container was backed up by Proxmox VE like with VMs, but explainable in hindsight. Is this a bug or a feature?

It's intended as a feature. But granted, it may be a bit unexpected. Normally if one uses the Proxmox VE integration of Proxmox Backup Server it does not bring much additional value to run backups internally too and that even with different "inclusion scopes".
Here you run into it due to the evaluation happening inside a CT, which is not the norm.

Albeit, a realistic use case where this could be problematic can be constructed, e.g., a when the CT user and the PVE admin differ could lead in fact to issues when the PVE admin promises full backups and the CT user does some backup of specific folders them self and uses such ignore files.
The only solution would be providing an option to choose if any .pxarexclude from the CT filesystems should be honoured or ignored.

 

[leesteken]

Albeit, a realistic use case where this could be problematic can be constructed, e.g., a when the CT user and the PVE admin differ could lead in fact to issues when the PVE admin promises full backups and the CT user does some backup of specific folders them self and uses such ignore files.
The only solution would be providing an option to choose if any .pxarexclude from the CT filesystems should be honoured or ignored.

I would argue that an external backup (by Proxmox) should ignore the .pxaexclude, by default or always. If honoring is really required (and I fail to see the use case, since restoring is next to impossible), one could use the (internal) client-backup instead (if one uses a supported distribution).

 

[t.lamprecht]

This would require an extra flag that probably should be exposed per backup job.
As the backup client cannot actually distinguish a "normal" user triggered backup from a one that is triggered by the Proxmox VE backup stack ("vzdump"), and while I still can see that for some users this might be unexpected, for others it really might be the desired outcome, switching such a new flag to default one could lead to some big shares, that were formerly excluded, to be backed up too and thus create serious space bloat that might even fill up the target server completely.

So, feel free to open an enhancement request in our Bugzilla, but I do not think it should be enabled by default.
Once documented and exposed in the backup job UI it should be prominent enough for those admins that either have foreign users controlling CTs and admins still wanting to do full backups, or use PBS both, out- and inside the CTs.

 

[kwat]

This would require an extra flag that probably should be exposed per backup job.
As the backup client cannot actually distinguish a "normal" user triggered backup from a one that is triggered by the Proxmox VE backup stack ("vzdump"), and while I still can see that for some users this might be unexpected, for others it really might be the desired outcome, switching such a new flag to default one could lead to some big shares, that were formerly excluded, to be backed up too and thus create serious space bloat that might even fill up the target server completely.

So, feel free to open an enhancement request in our Bugzilla, but I do not think it should be enabled by default.
Once documented and exposed in the backup job UI it should be prominent enough for those admins that either have foreign users controlling CTs and admins still wanting to do full backups, or use PBS both, out- and inside the CTs.

Just wanted to chime in. My assumptions were the same as the leestken! When I restored what I thought was a complete backup of container the folders in the .pxarexclude file were missing and they are permanently lost since I deleted them in the container expecting they had been backed up. This should NOT be default behavior and/or documentation should be made much more clear.

Current PBS documentation implies .pxarexclude applies to the backup client and NOT to PVE GUI initiated backups.