We had backups. We had never pressed restore.
James Connolly · · 7 min read
An insurance form caught me out. It asked whether Classfolio had a disaster recovery plan, with an option for "Yes — tested". I knew the backups were running every night. I had checked the configuration in July, I could see current backups sitting there, and my first instinct was to tick it.
Then I stopped. I had proved that backups existed; I had not proved that I could get anything back from one. If a supplier gave me that answer for a system holding pupil data, I would not accept it, so I could not use it myself. A green status in a console is not a recovery test. We had never actually run a restore.
On 17 August I restored the previous night's backup into a separate scratch database. Production was never touched. The users, lessons and assessments collections all returned documents, and I checked displayName, role and updatedAt on one sampled user record against production; all three matched. The database restore completed in thirteen minutes and fifty-eight seconds. That did not prove we could recover the whole service in fourteen minutes. It did give me evidence for the database part — and it exposed four things I would never have found by looking at the backup settings.
This post is for anyone who has written "backups: yes" on a form for their school and moved on. That answer might be true. It is also not the question the form is really asking.
The status field lied for an hour
The single most useful thing the rehearsal taught me had nothing to do with the data. It was that the tool I was watching told me the restore was still running for a full hour after it had finished.
The command that lists operations kept reporting the job as in progress. I sat there believing recovery took seventy-three minutes. The actual completion timestamp, buried in the operation's metadata, said it had finished in under fourteen.
In a real incident, at two in the morning, that difference is the gap between waiting calmly and starting a second restore on top of the first because you think the first one has hung.
I would never have found that by checking the configuration. It is only visible if you run the thing and watch the clock.
At our scale, the fixed setup cost dominated
Classfolio's database is small — a couple of thousand documents at the time. I assumed a restore would therefore be quick. It was not, because restoring does not copy your rows into an existing database. It provisions an entirely new one, and that takes about a quarter of an hour before anything of yours starts moving.
So the honest shape of our recovery today is: a fixed cost of roughly fifteen minutes, and then the actual work. That was worth discovering, but it is a fact about our current size, not a law. As the data grows, the second half will start to matter. If a supplier tells you their recovery time scales neatly with your data, ask them when they last measured it.
The restored copy quietly lost a guarantee
Our compliance pack says we hold seven days of point-in-time recovery. The restored database came up with point-in-time recovery disabled and a one-hour window instead of seven days.
It inherited the delete protection. It did not inherit the thing we actually promise. Nobody would have noticed until the day we promoted a restored database into production and then needed to recover from it — at which point the guarantee in the document would simply not have existed.
The failure mode worth fearing is not the backup that is missing. It is the recovery that appears to work and quietly drops a property you have promised someone in writing.
Tearing it down was harder than standing it up
The scratch database refused to delete, because it had inherited the same delete protection production has. That is the setting working correctly. But it means that if you run a rehearsal and walk away, you are left with a full copy of your pupil data sitting in your cloud account, billing you, that you have not written down anywhere.
A rehearsal has a cleanup step, and the cleanup step is part of the rehearsal.
What I would ask a supplier now
Before the rehearsal I would have asked whether a supplier had backups. It is the wrong question. Most suppliers will say yes, and that answer tells you very little about whether those backups can actually be used.
- When did you last run a restore, and how long did it take?
- How did you verify the restored data was correct — what did you actually compare?
- Was it restored into a separate environment, or did you test on production?
- Does the restored copy keep the same protections as the original?
- How much recent data would we lose in a restore — what is the recovery point?
- How long until the whole service is usable again, not just until a database exists?
- Has anyone other than the person who wrote the procedure successfully followed it?
- Who has permission to run a restore, and have they done it before?
That last pair matters more than it sounds. Our restore requires the owner account. A second, perfectly legitimate administrator account can list every backup we hold and cannot restore a single one of them. Discovering that during an incident would cost real time.
It is also a resilience problem rather than a permissions one. A recovery procedure only one person can execute is still a single point of failure, whatever the backups say. Our next step is to write down the exact permissions and commands, and then have a second authorised person follow that runbook successfully — because a procedure nobody else has ever run is another untested claim.
What this test did not prove
This was a database-restore rehearsal, not a full disaster-recovery exercise. It proved that a dated Firestore backup could be restored into a separate database, that the collections I sampled came back with documents in them, and that one user record matched production field for field.
It did not test recovery of uploaded files, user identities, application configuration or integrations, and it did not measure how long it would take to put the whole of Classfolio back in front of teachers and pupils. Thirteen minutes and fifty-eight seconds is a measured database-restore time. It is not a promise that Classfolio recovers from an incident in fourteen minutes.
A number is only useful with its boundary attached. Ours is: one database, restored to a scratch copy, sampled — not the service, and not the whole of it.
That distinction is worth carrying into your own planning. For a school, recovery is not a database metric either. A plan that is any use names which functions have to come back first — live lesson access, assessment evidence, uploaded work — and tells teachers what to do in the lesson where those things are missing.
What we changed
The rehearsal is now written up with a date, a duration and a result, and there is a row to append each time we run another. A tested restore is only as current as the last test — a claim with a date on it is worth something, and the same claim with no date behind it is worth nothing.
For the record, and because this post argues you should ask: Classfolio is a data processor, acting on written instructions from the school, all data lives in United Kingdom (Google Cloud europe-west2), and we hold Cyber Essentials, certified 17 August 2026 for the whole organisation. Basic Cyber Essentials is a verified self-assessment marked by a qualified assessor, not a technical audit. Classfolio does not hold Cyber Essentials Plus.
An earlier post on this blog set out the questions to ask when you are choosing classroom software — the procurement and GDPR checklist. The rehearsal above is what one of those questions looks like when a supplier actually answers it with evidence rather than a yes.
The short version
"We can recover" is a belief. "We have recovered, on this date, in this many minutes, and here is what we compared" is a fact. Only one of those is worth putting on a form.
It took me an afternoon to move from the first to the second. If you are a school leader, it is a reasonable thing to ask of anyone holding your pupils' data — and if you run a school's systems yourself, it is a reasonable afternoon to spend.
Classfolio is a teaching platform built by a teacher. See what it costs, or read why it exists.