A backup you don't trust is not a backup
Backup software makes copies. Backup Manager checks whether those copies are correct — an engine that dumps daily and runs diagnostics every six hours, and a supervisor on a second machine that spots anomalies and puts them to a human. It never deletes on its own.
Dumping ≠ diagnosing ≠ reviewing ≠ cleaning up
Four steps, strictly separated. The engine writes, the diagnostics only read, the supervisor flags — and only a human decides what may be removed.
Disk pressure is rarely a disk problem
A real incident from our own history. A volume filled up because of two crash leftovers. On the left what happened, on the right what we have changed since.
What went wrong
- Two crash leftovers sit unnoticed on the volume
- A half-aborted folder and an old archive copy of ~500 GB
- The volume fills up — the alert only arrives at 100%
- A SQLite database belonging to another system becomes corrupt
- That service goes down and surfaces externally as a 530 behind the proxy
What we changed
- The supervisor reads the backup logs and sees the volume growing
- Unexpected files and folders are named, not touched
- Warning on disk pressure: volume1 >85%, volume2 >80%
- Unusual growth is flagged for human review
- A human decides what may go — the supervisor never deletes on its own
The lesson: disk pressure is rarely a disk problem. It is a data-loss problem that disguises itself as a capacity alert — and it strikes in a place you weren't looking.
Restraint is an architectural choice
Full dump, every night
Around 03:00 a full run executes: Docker volumes plus database dumps to disk. Part of that is a manifest of which containers should have been there — so that after a restore you can check what is missing.
Health run every six hours
A diagnostics-only run checks the storage driver, container counts and the critical containers. It mutates nothing; it writes a log file and a separate alert file. Diagnosis and intervention are separated.
Restore on reboot
After a restart a restore step runs. That makes the backup not an archive you hope never to need, but a path that gets walked regularly.
Supervision from a second machine
The supervisor deliberately does not run on the machine it watches. It reads the backup logs over SSH and detects anomalies: failed runs, growing volumes, files that do not belong.
Never delete automatically
This is the heart of the design. The supervisor flags unusual growth for human review and warns on disk pressure. It does not clean up on its own. Data is sacred — a system that is allowed to erase will erase the wrong thing one day.
Honest about what went wrong
The trigger was an incident of our own: a volume that filled up because of two crash leftovers, 505 GB together. The result: a corrupt database elsewhere and a service that went down. The lesson now sits in the design, not in a promise.
Want to know whether your backups are correct?
Backup Manager runs in our own lab: daily dumps, six-hourly diagnostics and a supervisor that presents anomalies instead of cleaning them up. Request a demo.