Backups and data recovery

The specific reasons vary. The job stopped running four months ago after a credential expired, and the failure email went to someone who left. A new server was added last year and never put on the schedule. The database was copied as a flat file while it was mid-transaction, so the file exists but will not load. The copies were on a network share that the ransomware encrypted alongside everything else, because the compromised server had write access to it.

Every one of these is discoverable in advance. That is really what this service is: closing the distance between believing you have backups and knowing it.

How much data can you afford to lose? If backups run nightly and the failure happens at four in the afternoon, you have lost a day of work. For some systems that is an inconvenience. For an order pipeline it is a serious problem, and the answer has to be minutes, which means a different and more expensive design.

How long can you be down? Restoring several terabytes over an internet connection takes as long as it takes. If the business can absorb two days, that is fine. If it cannot, the copies need to be closer and the restore path needs to be prepared in advance.

These are business decisions with a technical price attached, not technical decisions. We put the options and their costs in front of you and let you choose. Backing up everything continuously and holding it forever is possible and rarely proportionate.

The useful arrangement keeps copies at a distance from the thing they protect. Distance in location, so a fire, a flood or a stolen server does not take both. Distance in access, so an account compromised in production cannot reach the backup storage. And distance in time, so yesterday's copy still exists if today's has already picked up encrypted files.

That last point is what most setups miss. If your only backup is a mirror of the current state, ransomware propagates into it immediately. Retaining several older versions is what gives you a point to return to.

We also encrypt copies, which is straightforward, and then make sure someone can find the key during an incident, which is where this occasionally goes wrong in an embarrassing way.

So we restore. On a schedule, into an isolated environment, and then we check the result rather than the exit code: does the database open, is the data complete, does the application start against it. The first test on an inherited setup finds something roughly as often as not. A missing table because someone excluded a directory during a disk space crisis. An application that restores but will not start because its configuration was never in scope.

Testing also gives you an observed restore time instead of an estimate. That number belongs in your recovery plan, because during an actual incident, the question everyone asks in the first ten minutes is how long this will take, and a guess is not a good answer.

So the recovery procedure gets written down: what gets restored first, in what order, who does it, who has the access, who tells customers, and what the team does while they wait. Kept somewhere reachable when your own systems are not, which sounds obvious and is not, given how many recovery plans live on the file server they were written to protect.

Then it gets walked through at least once. Not a full simulation necessarily, but enough that the first time anyone reads the document is not during an outage.