Most businesses we speak to have a backup. Far fewer have ever tried to restore from one.
A backup is worth exactly whatever you can get back out of it, and the usual way to find out which sort you have is on the worst day of your year, so it is worth spending 20 minutes on it well before then.
What to actually check
Start with when somebody last restored something. Not when the job last ran, which is a different question and the one most dashboards answer, but when a human last pulled a file back out and opened it to see that it was really there. If nobody can remember, treat everything below as untested.
Then work out what is not in the job. Backups get set up around whatever mattered at the time and the business grows past them without anyone revisiting the config, so email, the shared drive, the accounts package, the database behind your website and the laptops people actually work on can each end up sitting outside it. Ask for the list of what is covered rather than an assurance that everything is.
Where the copy lives matters more than people realise, since a backup on the same server as the original is a copy and a fire, a theft or a ransomware attack takes both together. You want at least one that is somewhere else entirely, on infrastructure that a compromise of your network cannot reach.
Retention is the one that catches businesses out. Ransomware commonly sits dormant for weeks before it triggers, so a 7 day window can mean every copy you hold is already encrypted by the time you go looking, and you will not find that out until you try.
Somebody also has to notice when it fails, because backup jobs fail quietly. They fail on a Tuesday, nothing goes red anywhere anyone is looking, and it surfaces 6 weeks later when a restore is needed. Without monitoring on the job itself, what you have is a scheduled task that used to work.
The 20 minute version
Pick a file at random, ask for it back, and open it. How long that takes, and whether anybody knows how to do it, tells you most of what the questions above would.
Who is actually accountable
Where one company hosts your systems, another backs them up and a third supports them, a failed restore turns into 3 suppliers pointing at each other while you are the one without your data, so it is worth establishing now which single company you would be ringing.
How we do it
We host, back up and support the systems we look after, which puts one company on the hook when it matters and leaves no seam between suppliers for a problem to fall down.
Restores get tested rather than assumed, because a restore nobody has attempted is a theory, and we would rather establish that data comes back and opens properly on an ordinary Wednesday than discover otherwise during an incident. The jobs themselves are monitored around the clock, so a failure raises an alert the day it happens instead of 6 weeks afterwards.
Copies run on trusted enterprise backup and disaster recovery platforms, kept separate from the systems they protect so that one event cannot take the original and the copy at once, with enough history retained that there is a clean point to go back to rather than only an encrypted one.
Recovery is part of the arrangement rather than a favour. Virtual and dedicated servers, backup and disaster recovery are things we run, with a dedicated team who know your setup because they built it, which is the difference between somebody reading documentation during an outage and somebody who already knows where everything is.
We go through all of this as part of the free consultation, and the findings are yours whether you work with us or not.