> Bron: https://neuralex.nl/en/showcase/backup-manager > A backup you don't trust is not a backup. Daily dumps, six-hourly diagnostics, restore on reboot — and a supervisor that flags anomalies but never deletes automatically. Showcase · Backup Manager # 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. [Request a demo](/en/contact) [View the incident replay](#replay) 03:00 daily full dump 6h health diagnostics interval 505 GB crash leftovers recovered 0 automatic deletions Architecture ## 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. Incident replay ## 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 1. Two crash leftovers sit unnoticed on the volume 2. A half-aborted folder and an old archive copy of ~500 GB 3. The volume fills up — the alert only arrives at 100% 4. A SQLite database belonging to another system becomes corrupt 5. That service goes down and surfaces externally as a 530 behind the proxy ### What we changed 1. The supervisor reads the backup logs and sees the volume growing 2. Unexpected files and folders are named, not touched 3. Warning on disk pressure: volume1 >85%, volume2 >80% 4. Unusual growth is flagged for human review 5. 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. Tech in detail ## 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. Built with PythonSSH pollingcron/launchdDashboardTelegram alertstar/dump Early access ## 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. [Request a demo](/en/contact) [Our approach](/en/aanpak) --- Volledige (opgemaakte) versie: https://neuralex.nl/en/showcase/backup-manager