VibeLast edition I promised a practical one, and this is it. Having a backup is only the first answer. The harder question is the follow-up. When did you last restore a file from it, and did it open? That is the question this check answers, and it takes about thirty minutes.
There is a current reason to ask it. On October 20, 2026, CISA and the FBI published a joint advisory on the SafePay ransomware group, which has hit at least 600 organizations since August 2024. Buried in the technical details is the part that matters here: the attackers halted the Volume Shadow Copy Service and reset network storage devices holding backup data back to factory settings, specifically to stop victims from recovering on their own. Attackers go for the backups first because a business that can restore does not have to pay. The advisory's own mitigation list leads with the same advice it always gives: maintain offline backups of data, and regularly test and maintain your backup and restoration processes.
Minutes 0 to 5: What do you actually have?
Write down, in plain language, four things. What is being backed up (files, email, the line-of-business database, system images, or only some of those). Where each copy lives. When the last successful backup actually completed, which is not the same as when it was scheduled to run. And who gets told when a backup fails. If any of those four answers is a guess, that is your first finding, and it cost you five minutes instead of a very bad day.
Minutes 5 to 12: Count it against 3-2-1
The working rule is 3-2-1: three copies of anything that matters, on two different kinds of storage, with one copy off site. Then add the modern footnote CISA keeps repeating: at least one copy should be offline or otherwise unreachable from your everyday network, and backup data should be encrypted. A drive that stays plugged into the same computer all day is convenient, and it is also reachable by the same ransomware that reaches the computer. A cloud sync folder is not automatically a backup either: delete or encrypt a file on your machine and the sync will faithfully copy that deletion or encryption to the cloud. Check your setup against the rule and write down which number you fail, if any. Most small setups fail the offline part.
Minutes 12 to 22: Restore something. Actually restore it.
This is the step people skip, and it is the whole point. Restore three things to a different location than the original, never over the top of the live file. One, a file you changed this week. Two, a file from about a month ago, which tests whether your retention history is really there. Three, one file that matters: the accounting file, a customer document, a database export. Open each one. A restore that completes but produces a file the application cannot open is a failed restore that reported success. Time how long the three restores took. That number, scaled up, is your real recovery time, and knowing it now is what lets you decide whether it is good enough. NIST makes the same point in its recovery guide (SP 800-184, December 2016): recovery plans only mean something when they are built around realistic test scenarios and exercised, not just written down.
Minutes 22 to 27: Hunt the silent failures
Backups rarely fail loudly. They fail quietly, in one of these five ways. One, the storage filled up and the job started failing weeks ago, with the alerts going to an inbox nobody reads. Two, someone changed a password and the backup job has been failing to sign in ever since. Three, a new folder, a new computer, or a new database was added to the business and never added to the backup list. Four, the only copy is the sync folder problem above: deletions and encrypted files synced over the good versions. Five, the backup depends on one person: only one employee knows where it lives, how to restore, or what the encryption key is. Check each one by looking, not by remembering. Every yes is a fix that is cheap today and expensive during an incident.
Minutes 27 to 30: Write it down and set the next date
Finish with three lines in a note you will keep: the date of this check, what you restored and whether it opened, and the one gap you found. Fix the worst gap first; you do not have to fix everything at once. Then put the next check on the calendar, quarterly is a reasonable rhythm for a small business, and also run it after any big change: a new server, a new backup product, a password overhaul, a move. A backup check is not a project. It is a habit, and thirty minutes four times a year is a small price for knowing the answer to the only backup question that counts: can we restore?
If you run this check and find a gap you do not know how to close, that is the kind of thing VibeCMD does. Reach me through vibecmd.net/contact or at (279) 202-4794.