Restore yesterday without the vendor

Before you call yesterday's backup a recovery, three things have to be true when you are alone. You can find the copy without asking the person who built the product. You can load it onto a system that is not the one customers are using. A row you already know — one account, one invoice, one file — is present on that copy, and you did not prove it by writing over the live system. If any of the three needs a call, you do not have a restore. You have a file that may sit in an account you do not administer. Leave the sentence off the runbook.

This is the afternoon you load a copy. It is not the inventory of accounts you demand on the last day, and it is not the list of objects a twelve-week build owes you. The last day asks whether the repository, the domain, and an export path were ever in your name, and whether you have run that export. The twelve-week list includes a way to undo a release, which is a rollback of code, not a reload of customer rows. Closing public signup, and deleting the one account you just created, is a different afternoon again: that proves you can end a user, not that you can bring yesterday's users back. All three can be finished while the only copy of the database still lives in a project you cannot open. The rest of this article is the three proofs, in the order a founder can perform them without a call.

None of what follows makes you a federal system owner, and none of it is legal advice. The controls below describe what a serious operator already expects of a backup. They do not tell you what your terms must say when a customer asks for their data, and they do not replace the firm you call when production is already down and the copy will not load.

A known state, in a time you named. NIST's control CP-10, System Recovery and Reconstitution, is one sentence: "Provide for the recovery and reconstitution of the system to a known state within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] after a disruption, compromise, or failure" (NIST, SP 800-53 Rev. 5, September 2020, updated 10 December 2020). The discussion under it separates two words people treat as one. "Recovery is executing contingency plan activities to restore organizational mission and business functions. Reconstitution takes place following recovery and includes activities for returning systems to fully operational states." The same discussion says organizations establish recovery time and recovery point objectives as part of contingency planning. Read the assignment as the blank you are supposed to fill, not as a form a founder must file. The known state is a copy you can point at. The time period is the amount of yesterday you have decided you can lose. A sentence in a proposal that says "we take backups" has filled neither blank.

You are not reconstituting a federal system. The translation is still direct, and it is technical. Recovery, in that paragraph, is the part where the business function comes back. Reconstitution is the part where the temporary arrangement is turned off and the real system is itself again. A founder testing a backup is doing a smaller thing than either, and should not pretend otherwise. You are checking that a copy loads, on a system that is not live, far enough that you would trust it on a bad day. You are not cutting production over. A drill that ends by replacing the live database has stopped being a drill. Write down the time you would accept losing — an hour, a day, the last invoice — before you look for the file. A restore with no such time is a hope that the newest file is the right one.

The test has a place, and the place is not production. The CIS Controls Assessment Specification for Controls v8 opens safeguard 11.5, Test Data Recovery, with the sentence "Test backup recovery quarterly, or more frequently, for a sampling of in-scope enterprise assets." The operation under that safeguard is specific about where the test goes: "Use Input 1 to restore a sampling of the backups to a temporary location." The assumption above the operation is the part a founder can use without a committee: "Enterprise will know what a properly working restored backup looks like." The measurement is blunt. M4 is the time in months since the last recovery test. "If M4 is greater than three months, then this safeguard is measured at a 0 and receives a failing score. The other metrics don't apply" (CIS, Controls Assessment Specification, safeguard 11.5). A score of 0 is the specification's mark for a late test. It is not a finding that zero companies test, and it is not a percentage of your rows. Quarterly is the floor the sentence names, not a suggestion that a product with no customers yet must open a change ticket every ninety days. The sentence that binds tonight is the temporary location. A restore you can only perform by overwriting the database customers are using has not met the operation. It has rehearsed the incident.

People who were attacked often could not load the copy. Veeam's 2024 Ransomware Trends Report surveyed 1,200 respondents — CISOs or executives with similar responsibility, security professionals, and backup administrators — whose organizations suffered at least one ransomware attack in 2023. The surveys were contracted to independent research firms and, the report says, were intentionally not limited to that vendor's customers. Read the population before the percentages. These are organizations that were already hit, not a sample of startups, and not a probability that your product will be hit. Inside that population the report separates three different facts about the copies. "Backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases." A later line is a third number: "On average, 37% of backup repositories were affected by a successful attack." Targeted is not affected. Affected in the attack is not the same as the average share of repositories touched. Then the rows themselves: "On average, cyber victims reported that they were unable to restore 43% of whatever data was affected by the ransomware attack." That 43% is a share of affected data the victims said they could not bring back. It is not the 37% of repositories, and it is not the 96% of attacks in which the repository was a target. The recovery behavior is a different split again. "In their haste to resume work as quickly as possible, 63% restored directly back into their production environment without some type of quarantine or other scanning method during recovery," and the same section prints "37% use a quarantine or sandbox." Those two add to 100, so read them as one question's two answers, not as two studies. The vendor sells backup software. The figures are that report's, from that sample (Veeam, 2024 Ransomware Trends Report). What you take from it is the practice the percentages keep failing: a copy you have not loaded, onto somewhere that is not production, is the thing the victims did not have when they needed it.

You can find the copy. Sit down without a call. Name the account the snapshot lives in, the project, and the date on the object you would actually load. Open that account with a login that is yours. If the newest object is in a project under the contractor's email, you have not found a backup. You have found their backup. A console bookmark you were sent last month is not the same as a login you can reset. The handover inventory — registrar, cloud root, payment processor, and an export you have run — is the handover. Tonight's proof is smaller and the other direction. An export takes rows out. A restore puts a copy back. You can have a working export and still be unable to load yesterday, because the export is a file you made and the backup is a system someone else scheduled.

You load it somewhere that is not live. Create a second database, a scratch project, or a machine that has never served a customer. Load the copy there. The CIS operation calls that a temporary location, and the point of the phrase is that the test must not be the production system. Watch the load finish or fail in writing. A spinner that ends on someone else's laptop is not a result you hold. If the only documented procedure is a script the contractor runs, you do not have a procedure. You have a person. Time it, even roughly, and write the number next to the time you said you could lose. A load that takes a day, against a loss you said you could tolerate for an hour, has answered CP-10's blank in the wrong direction. Do not "fix" the miss by restoring onto production to see if it is faster. That is the 63% path in the report, performed on purpose.

A row you already know is the pass mark. The specification's assumption is that you know what a working restore looks like. Pick the row before you start: the invoice you sent on Tuesday, the user you created on Monday, the file you uploaded yourself. When the load finishes, that row is there, or it is not. An empty database that "restored successfully" has not passed. A row count that matches, while the one invoice you checked is missing, has not passed either. Counts lie when the copy is the wrong day. If you cannot name a row before you begin, you cannot tell a good load from a blank one, and the drill should wait until you can. The cousin of this check, for a single account you want gone rather than a database you want back, is what to prove before public signup. Deleting the test user does not load yesterday. Do not borrow that afternoon to avoid this one.

There is a version of this afternoon where hiring more engineering is the wrong purchase. Nothing has been built, so there is no copy to find and no row to recognize — that is a scope conversation, not a restore drill. You are still choosing between two firms, and neither has a database you administer. A product with no customer data, because it is a brochure, does not need this proof. A customer has already seen another customer's data. That is an incident, and the first hour is not a backup test. The twelve-week inventory, including the undo of a release, is what an MVP owes you in twelve weeks. A rehearsed rollback of code is not a loaded copy of the tables. Do not treat the word "backup" in a proposal as the proof. The proof is the load.

What the three proofs look like when a product actually holds records is ordinary and visible. Gigbase, a multi-tenant workspace, had to keep projects, contracts, and invoices in one product, with subscription plans and roles. A founder running this afternoon's test can name one invoice, load a copy somewhere that is not the live workspace, and see that invoice present, without anyone narrating the screens. Nothing in that description is a headcount, a duration, or a result figure. The shape is the point: if customers have rows, those rows are the thing you can recognize after a load. A workspace you cannot copy is a workspace you are renting from the person who can.

On the afternoon you are tempted to write "backups: daily" into the runbook, do the three proofs before you write it. Find the copy in an account you administer, and read the date. Load it onto a system that is not production, and keep the note of how long it took. Find the row you named before you started. Then the sentence is allowed. A startup software development company that expects this will have put the snapshot, the scratch target, and a login you control in place before the first customer row existed, because the proofs take them nothing they were not already operating. One that needs a call in order for you to load yesterday is telling you who holds the recovery. If the first slice is a fixed capability rather than an open-ended platform, an AI integration sprint is the shape where the acceptance sentence can include these three proofs before anyone calls the copy a backup. The criteria for choosing who holds that login sit on the page written for a top saas development company. That page is criteria, and it does not rank anyone, including us.