fix: backups failling with `archive/tar: write too long`

[alehostert]

Backup jobs rely on podman commit, which fails with archive/tar: write too long when backing up a WordPress container in production. The error occurs consistently on some WP containers.

We haven't pinpointed the exact cause yet. The most likely hypothesis, based on similar reports upstream (containers/storage, containers/podman), is a mismatch between the size declared in the tar header (via stat() at read time) and the bytes actually read — which typically happens when a file changes size during the commit (concurrent writes). This container runs WordPress with an active cache plugin, so there's continuous file generation/writing in wp-content/uploads/ and cache directories during the backup window.

Steps to reproduce

1. WordPress container in production, with an active cache plugin continuously generating/rewriting files in wp-content/uploads/ (or cache).
2. Run a backup.
3. Observe the error at the job logs:

   Error: copying layers and metadata for container "...": initializing source containers-storage:<domain>: storing layer "<hash>" to file: on copy: archive/tar: write too long
   

4. Not every WordPress containers fails, suggesting containers without concurrent active writes (same base image, no traffic/cache generating files) do not reproduce the error.

Impact

• There's no error message identifying which file caused the mismatch, which makes diagnosis and any manual workaround (e.g. pausing the process writing to that specific file) difficult.