Released 5.1.0
MyDockerBackup AIO
Docker volume backup and restore, in one container.
The problem
Anyone running a Docker host ends up with scattered scripts, hand-invented retention and restores tested for the first time during an outage.
Constraints
- One container: no orchestrators, no external services.
- Selective restore: one volume, not an entire archive.
- Reuse the proprietary storage already written instead of reimplementing it.
- Move from 'untested' to 'tested' without rewriting the product.
Architecture
- ASP.NET Minimal API backend with EF Core and SQLite, React frontend in the same container.
- Storage in a single CloudXFile master, with snapshot chains and integrity verification.
- Scheduler with calendar, time zones and explicit daylight-saving handling.
- Notification system configurable on twenty different events.
Decisions that matter
An audit changed the project
About fifty-five verified issues, six of which caused data loss. They were fixed before adding features, and that is where a seventy-one-test suite came from where none existed.
No authentication, stated plainly
The application drives Docker: whoever reaches it can act on the host. The choice is to assume a trusted network and write it down, instead of adding a login that would give a false guarantee.
Where it got to
Version 5.1.0 with end-to-end verified selective restore, stamped migrations and twenty-event notifications.