A Backup Is Not a Backup Until It Is Verified
Almost every organization believes it has backups. Fewer have ever tried to restore one. That gap is where data gets lost: a backup job that silently failed months ago, an archive that was never completely written, a file that was deleted by a cleanup script, a copy that cannot be opened.
In our platform, we hold ourselves to a strict definition. A backup counts as a recovery point only when we can show it would actually work.
Our definition of a recovery point
A backup is a recovery point when all three of these are true:
- The operation completed. It ran to the end rather than stopping partway.
- Integrity verification passed. After writing the backup, we check that the archive is complete and readable.
- The artifacts still exist. The backup files are present locally or at a usable remote destination right now, not just at the moment they were created.
If any of those is missing, the backup is not protection, and our interface does not describe it as if it were. A pending backup is pending. An interrupted backup failed. An empty file is not a backup.
When things go wrong, close them cleanly
Backups can fail for ordinary reasons: a timeout, a full disk, a worker restarted during a release. When that happens, a sloppy system leaves behind a half-written archive and a status that says "in progress" forever. The next person sees the in-progress label and assumes protection is on its way.
Our backup process closes failed operations properly. It marks them as failed, removes the predictable partial files and keeps a clear state that allows a retry. The technical details of the error go to our logs; the customer sees a plain explanation and a retry option.
Schedules need two jobs, not one
Scheduled backups depend on a scheduler that actually runs them. We register two scheduled tasks: one that processes backups that are due and one that cleans up expired backups according to their retention rules. A scheduler that only creates backups and never cleans up fills storage until new backups fail. A scheduler that only cleans up would be worse. Both have to be present and running.
Restores require a decision and a snapshot
A restore replaces the current state of an account with an earlier one. That can be the right call after a serious mistake, but it also discards everything that happened after the backup was taken. So restores in our platform require explicit approval from an authorized person, and before any restore runs, a fresh snapshot of the current state is taken and verified. If the restore turns out to be the wrong decision, the snapshot lets us go back.
We never run a production restore casually, as a test or as a shortcut for a smaller fix.
Backups protect imports and big changes
The strict definition is what makes our import safeguard meaningful. Every import waits for a verified recovery point before it writes data, which we describe in why every import starts with an automatic backup. A backup that only looked finished would make that promise empty.
Source code is not a backup of data
Our code lives in a version-controlled repository with full history, and that is valuable. But it is not a backup of customer data. Pages, members, orders and uploads live in databases and storage, and they need their own recovery points. We keep those two kinds of protection separate in our thinking and our planning.
What you can take from this
Whether you run a website on our platform or anywhere else, it is worth asking three questions about your backups: Did the last one finish? Has anyone checked it can be opened? Do the files still exist today? If you are not sure, you may not have the protection you think you do. If you would like to talk about how we protect the organizations we serve, contact us.
Frequently asked questions
How do I know if my backup is good?
A good backup completed successfully, passed an integrity check and still exists where it is stored. Ideally, you have also tested restoring from it.
Why do failed backups need cleanup?
Partial backup files can be mistaken for real ones and waste storage. Closing failed operations and removing partial files keeps the record honest and allows a clean retry.
Is my code repository a backup of my website?
Not of your data. A code repository protects the software, but pages, members, orders and files need their own backups.
Related Posts
Why Every Import Starts With an Automatic Backup
Imports change a lot of data at once, so we never start one without a verified recovery point. Here is how the automatic backup step works and why it is not optional.
Every AI Call Is Registered Before It Runs
AI features cost money and touch customer data, so we keep a registry of every one. Here is how a call that is not on the list is refused before anything is spent.
Why Card Numbers Never Touch Our Servers
The safest way to protect card numbers is to never hold them. Here is how our checkout forms send card details straight to the payment processor instead.
Comparing the Old Site and the New Site Screen by Screen
After a website moves platforms, small differences hide in plain sight. Here is how we compare the old and new sites at desktop and phone sizes before calling a move complete.
Audit Trails: Recording Who Changed What
When something changes unexpectedly, the first question is who changed it and when. Here is how audit trails answer that question without becoming a privacy problem.
Comments (0)
No comments yet. Be the first to share your thoughts!