When did you last restore from backup?

Every organisation says it has backups. Far fewer have ever restored one — and the difference between those two groups only becomes visible on the worst day of the year.

Why backups fail when they are needed

• The job silently stopped months ago and nobody watches the alerts.
• The backup runs, but excludes the database or shared folder that actually matters.
• The backup sits on the same server, same building or same account that the incident just destroyed or encrypted.
• The restore has never been rehearsed, so recovery takes days while the procedure is invented under pressure.

Ransomware adds a newer failure mode: attackers deliberately find and encrypt backups first. A copy your admin can delete from their desk is a copy the attacker can delete too.

What a real recovery capability looks like

Start from two numbers per system: how long can it be down (recovery time objective), and how much data can you lose (recovery point objective). An accounting system might tolerate four hours and zero data loss; an archive server might tolerate a week.

Then design against those numbers: the 3-2-1 rule (three copies, two media, one off-site), immutability so ransomware cannot encrypt history, and monitoring so a silent failure lasts hours, not months.

Finally — rehearse. A quarterly restore drill of one critical system takes an afternoon and answers the only question that matters: does this actually work, and how long does it take?

The question to ask this week

Ask your team: "When did we last restore something from backup, and how long did it take?" If the answer is a guess, that is your project. Maxventures builds and tests backup and disaster recovery for institutions across Rwanda — including restore drills as part of the support contract.