Every one of these is a decision. None of them should be a default.
Most backup disappointments trace back to an assumption nobody wrote down — a machine that was never in scope, a retention window shorter than the problem, a database the agent could not quiesce. These are the things we settle explicitly before anything is switched on.
- 01
Covered data, systems, and applicationsNamed machines and workloads, so nobody assumes coverage that was never scoped
- 02
Backup methodFull, incremental, differential, or application-aware where a database needs it
- 03
Storage locationCloud, local, or both — held in approved locations you have agreed to
- 04
Retention and storage allowanceHow far back you can reach, and what happens when the allowance is reached
- 05
Encryption and access controlsHow copies are protected, and who is able to reach or delete them
- 06
Job monitoring and failure alertingSomeone notices a failed job that night, not during the incident
- 07
Restore testing and verificationProving the copy opens, at an agreed cadence
- 08
Recovery responsibilities and procedureWho does what, in what order, when it is actually needed
Coverage, method, retention, storage allowance, location, encryption, testing cadence, recovery responsibilities, recovery objectives, exclusions, and pricing are defined in the applicable agreement.
Restore testing
A green tick means the job ran. It does not mean the data comes back.
Backup software reports on whether it completed, not on whether what it produced is usable. A job can succeed for months against a database that was never quiesced properly, or a machine whose most important folder stopped being included after a rebuild.
The only way to know is to restore something and open it. We do that on an agreed cadence, record the result, and tell you when a test fails — which is the useful moment to find out, because there is nothing else going wrong that day.
Scoped in your agreement
Which workloads are test-restored, how often, to where, who witnesses or signs off the result, and how failures are reported and remediated.
Testing raises confidence that a recovery will succeed. It is evidence, not a guarantee.
Recovery
The worst time to design a recovery is during one.
Accidental deletion, equipment failure, ransomware, a failed update — the events differ, the first hour does not. Someone has to decide what is being recovered, to where, in what order, and who tells the rest of the organization what to expect.
That sequence belongs in a document written on a calm Tuesday. Where recovery point and recovery time objectives are contractually confirmed, they are stated in your agreement in terms you can hold us to — and where they are not, we say so rather than implying a number.
Scoped in your agreement
Recovery procedures, escalation and decision-making, the order systems are restored in, what your team does, what we do, and any recovery point or recovery time objectives that have been confirmed.
Recovery duration depends on data volume, available infrastructure, and what you are recovering to.
We will never tell you your data is safe.
It is a comforting phrase that commits to nothing and cannot be tested. Here is what we will tell you instead — and what no backup service can honestly claim.
Existing is not the same as recoverable
A backup existing does not guarantee recovery. Coverage gaps, corruption, and untested restores are ordinary, and they are only discovered by testing. We report what has been verified and when.
Recovery times are contractual or they are guesses
We state recovery point and recovery time objectives only where they have been confirmed in your agreement. Any provider quoting a recovery time before scoping your data volume and target infrastructure is estimating.
Not a complete answer to ransomware
Recoverable copies limit the operational impact of an attack. They do not prevent one, and modern attacks deliberately target backups — which is why isolation and access control are part of the design. Managed cybersecurity
Nothing here is set and forget
Environments change. New machines appear, applications move, folders get reorganized, and a scope agreed last year quietly stops matching the business. Coverage is reviewed, not assumed.
Ask your current provider the first one today.
If the answer takes more than a minute to produce, that is the finding.
01When did you last prove a restore actually works?
This is the question that separates a backup service from a backup subscription. A dashboard of green ticks answers whether jobs completed. It does not answer whether the data comes back.
Ask for the date of the last successful test restore, which workload it covered, and who verified the result. A provider running real tests will have that to hand, because they wrote it down when they did it.
02How long would it take to get us running again?
It depends on how much data is involved, what infrastructure is available to recover onto, and whether you are restoring a file, a database, or an entire server. Those variables change the answer by orders of magnitude.
We scope it against your environment and state any recovery time objective in the agreement. We will not quote you a figure we have not committed to contractually — that number only matters on the day it is tested.
03Isn't backup already part of managed IT?
Backup oversight and recovery coordination for covered workloads sits inside managed IT — we watch the jobs and coordinate a recovery.
The backup platform itself, storage allowance, retention, encryption, testing cadence, and recovery objectives are scoped and priced separately, because they depend entirely on how much data you hold and how far back you need to reach.
04Will backups protect us from ransomware?
They reduce the operational impact of an attack by giving you somewhere to recover from, which is genuinely valuable. They do not prevent the attack, and they are not a security programme.
Attackers routinely go after backups first, so how copies are isolated, who can delete them, and whether credentials to the backup platform are separated from everyday admin accounts all matter. That is design work, and it belongs in the same conversation as your security programme.
05Where is the data actually held?
In approved locations that you agree to before anything is configured — cloud, local, or both, depending on how quickly you need to recover and what you are protecting against.
Where data resides is not only a recovery question. For organizations handling sensitive or regulated information it affects your obligations too, which is worth settling alongside a readiness assessment rather than after one.
Find out what is really covered.
A backup review establishes which systems are actually in scope, how far back you can reach, where copies are held, and when a restore was last proven to work. Most organizations find at least one assumption that was never true.
Or call (734) 772-9499 · Mon–Fri, business hours