In short. A backup runs every night: full on Saturday, light on other nights with only what has changed. Every archive is test-restored right after it is written; if it is unreadable, it is marked invalid and the operator is alerted. AES-256-GCM encryption and the off-site copy are switched on at the server.
Full on Saturday, light on other nights
A backup runs every night. On Saturday it is full: every client database, the control database, the registers, the configuration and the media. On other nights it is light: only the databases that changed since the last valid archive. At most one day is lost. Each database is taken live through a consistent snapshot, never by a file copy that could capture a write in progress.
Verified by restoration. A backup nobody has ever restored is not a backup, it is an intention. Every archive is test-restored right after it is written: each database is reopened, its tables counted, a real query run. An archive that fails this test is marked invalid, and an email goes out at once.
Encrypted, then copied elsewhere
Two protections are added as soon as they are set on the server: encryption of every archive with AES-256-GCM, with a key the operator holds, and an off-site copy of the verified archive, to S3-compatible storage or another machine over SSH. The verification decrypts before reading back: an encrypted archive is proven restorable like any other.
Retention
The four latest full backups are kept, plus the first of each of the last three months, and the light ones under fourteen days old. The latest valid full backup is never removed. Before writing, the script checks the available space: if it is short, it clears old archives, and failing that it writes nothing and raises an alert, rather than leaving a truncated archive.
Getting back to the latest state
To get back to the latest state, you restore the latest valid full backup, then each valid light one that follows it, in order. The restoration plan shows that sequence before acting, and a single command runs it.
The watchdog
Every ten minutes, a watchdog checks that the site answers, that each client database still opens, that backups are running and leaving the server, that disk and memory are healthy, that the HTTPS certificate is not about to expire, and that logs are not eating the disk. It raises an alert if no valid backup has arrived for two days, or no full one for eight.
It reports in three colours — green, orange, red — and emails the operator when something changes. It does not repeat itself: one alert per situation, and one message when things return to normal.
See also: Security and data confinement · On-premise installation: the sovereign edition · Reversibility: export all your data · Reversibility plan: contents, Data Act, contract
Frequently asked questions
How much data can be lost at worst?
One day at most: a backup runs every night, full on Saturday and light on other nights.
How do you know a backup can be restored?
It is test-restored right after it is written: each database is reopened, its tables counted, a real query run. If that fails, the archive is marked invalid and an email goes out at once.
How long are backups kept?
The four latest full ones, the first of each of the last three months, and the light ones under fourteen days old. The latest valid full backup is never removed.