Proof of work · our own systems
We restore our own backups, every week
This is Nexidy's own work, on Nexidy's own systems: the check we sell, run on ourselves first, with the results exactly as they were measured. It is internal work, not a client engagement.
The problem
A backup that has never been restored is a file, not a backup. A dump can be cut short, a checksum can go unread, and a restore can need a step nobody wrote down. The only proof that a backup works is restoring it and checking what comes back.
What runs on our systems
- Every night, a backup set: the PostgreSQL database (every table, with its row counts taken from the same snapshot), the MySQL database, the configuration and the code, each file with a SHA-256 checksum. An encrypted copy leaves the server.
- Every Sunday, a restore drill for each database: the newest set is checked against its checksums, restored into a throwaway server that is never the live one, and the restored copy is read back and compared.
The latest results, Sunday 1 November 2026
- PostgreSQL: 113 tables and 850,716 rows restored and compared, table by table, with the counts taken at backup time: 0 mismatches. This drill has passed every Sunday since 4 October.
- MySQL: all 10 checksums in the set verified, then the dump restored into a throwaway MySQL 8.4, the same version production runs: 227 tables in about a minute, with the newest content read back from the restored copy.
What the drill caught this week
Our production MySQL moved from 8.0 to 8.4 on 22 October. The two Sunday drills since then still restored into 8.0, so they proved that the backup restored into a version we would never restore into, and this morning's drill downloaded that old 1.1 GB image to do it. We changed the drill to read the version from the running production server and never to download anything, then ran it again: the MySQL result above is the first on the right version.
A test that checks the wrong thing still passes. That is why the check itself gets checked.
What you get when we do this for you
The same drill on your database and the server it runs on: your newest backup restored into a throwaway server that matches yours, the tables and rows compared with the original, the time it took, every step written down so anyone on your team can repeat it, and the fixes in writing if something fails. It is read-only on your production systems, and nothing changes there without your approval. Hamed Kabir reviews and signs off the report before it reaches you.