Robust Backup Automation: Handling Docker Permissions and GitHub Asset Limits
Grant backup user read/execute ACLs on Docker volumes and split large archives into 1900MiB parts before uploading to GitHub releases.
Grant backup user read/execute ACLs on Docker volumes and split large archives into 1900MiB parts before uploading to GitHub releases.
Summary
The article details a backup job that creates a local archive, verifies it, uploads it as a GitHub Release asset, prunes old releases, and cleans temporary files. Two failures were encountered: first, Docker‑owned Postgres volume files were unreadable by the backup user, causing an EACCES error; second, the archive exceeded GitHub’s 2 GiB per‑asset limit, leading to upload failure.
To resolve the permission issue, the author applied setfacl to grant the backup user read/execute rights on the volume directory and its default ACLs, avoiding root execution. For the size limit, the script now splits archives into 1900 MiB parts using split -b, uploads each part as a separate asset, and concatenates them during restore.
Additional robustness measures include verifying the archive before upload, deleting existing release tags to ensure idempotent runs, and cleaning up /tmp files to prevent disk fill. These changes make the backup process reliable, secure, and maintainable.
Key changes
- setfacl grants read/execute to backup user on Docker volume
- default ACLs propagate permissions to new files
- archive split into 1900MiB parts to stay below GitHub limit
- each part uploaded as separate asset
- archive verified locally before upload
- existing release tags are deleted before recreation
- temporary files are cleaned up after upload