Backup & Disaster Recovery

Having a backup is not the same as being able to recover.

Most businesses find out which of the two they have on the worst possible day. We design backup around how long you can actually afford to be stopped, then prove it works before you need it.

  • Restores tested, not assumed
  • Off-site copies
  • Ransomware-resilient
  • EndpointsLaptops and desktops, wherever they are
  • Servers & cloudOn-premise and cloud workloads
  • Microsoft 365Mail, files, Teams and SharePoint
  • Tested restoresOn a schedule, reported to you

Technologies we work with

  • Microsoft
  • SOPHOS
  • Acronis
  • HPE
  • 3CX
  • UBIQUITI
  • veeam

What we protect

Everything the business would miss on Monday morning

Backup fails most often at the edges — the laptop nobody enrolled, the cloud application nobody thought of, the server that dropped out of the job six months ago. We cover the whole estate and check that it stays covered.

Endpoint backup

Laptops and desktops backed up continuously, including for staff who rarely come into an office.

Server backup

Full image-level backup of physical and virtual servers, so a failed machine can be rebuilt rather than reinstalled.

Microsoft 365 backup

Independent backup of Exchange, SharePoint, OneDrive and Teams. Microsoft replicates your data; it does not archive it for you.

Cloud workloads

Cloud servers and line-of-business applications brought into the same backup regime as everything else.

Off-site copies

At least one copy kept away from your premises, so a fire, flood or theft is not also a data loss.

Immutable storage

Where the platform supports it, backups that cannot be altered or deleted for a fixed period — including by an attacker with your credentials.

Restore testing

Scheduled test restores with a written result, so "we have backups" becomes something you can actually rely on.

Monitoring & alerting

Failed and missed jobs are picked up and chased by us, not left in a report nobody opens.

Recovery documentation

A written recovery runbook: what gets restored, in which order, by whom, and who is told.

Ransomware recovery

Isolated, retained copies designed on the assumption that the attacker reached your live systems.

Retention that suits you

Retention periods set against how you work and what you are obliged to keep — not left at a vendor default.

Recovery planning

Scenario-based planning so the plan covers a failed server, a lost laptop and a bad afternoon equally well.

Plain English

What happens when something goes wrong?

That is the only question that matters, and it is answered by design decisions made long beforehand. Everything technical about backup traces back to two numbers that are yours to set, not ours.

  • We agree how much work you can afford to lose, and how long you can afford to be down
  • Backup frequency, retention and storage are designed to meet those answers
  • At least one copy is held off-site and, where supported, cannot be deleted
  • Restores are tested on a schedule and the results are written down
  • A recovery runbook says who does what, in what order, on the day
  • We review it as things change — new systems, new sites, new obligations
Restore drill Shared drive › Projects Restored and checked
  • Site survey.pdfRestored · 14:00 copy
  • PhotosRestored · 14:00 copy
  • Budget 2026.xlsxRestored · 14:00 copy
  • Client brief.docxRestored · 14:00 copy
  • Programme.xlsxRestored · 14:00 copy
  • DrawingsRestored · 14:00 copy
  1. Assess
  2. Contain
  3. Restore
  4. Verify

Restored, then checked with the people who use the files

Restore points Click a point to compare
YesterdayToday
How much work was lost? 25 min Working time from the 14:00 copy to 14:25
How long were people stopped? About 15 min Only the folder comes back. Nobody else is interrupted.
Illustration with sample times. Your own figures are agreed in your recovery plan.

On the day

What recovery actually looks like.

  1. Assess

    What has been lost, how far back the good copy is, and what has to come back first.

  2. Contain

    Where the cause is malicious, affected systems are isolated so we do not restore into the problem.

  3. Restore

    Systems come back in the order set out in the runbook — the ones the business needs first, first.

  4. Verify

    Data is checked with the people who use it before anyone calls it finished, and the event is written up.

Why CaminhoIT

We would rather find the problem in a test.

Backup is the part of IT that is easiest to leave unchecked, because nothing appears to be wrong until the day it matters. Testing restores is unglamorous work, and it is the reason a recovery goes to plan.

  • Tested restoresnot just green tick reports
  • A written runbookso nobody improvises
  • Ransomware-awareisolated, retained copies
  • Part of your securitynot a separate silo
  • Failures chasedby us, the same day
  • EU and UK storageconfirmed per client

Questions

Backup and recovery questions

What are RPO and RTO, in plain English?

RPO — the recovery point objective — is how much work you can afford to lose, and it decides how often backups run. If backups run nightly, your RPO is up to a day. RTO — the recovery time objective — is how long you can afford to be stopped, and it decides how recovery is built. Coming back within four hours needs standby capacity; coming back within three days does not. You set both against what the business can tolerate; we design to meet them.

We are entirely in the cloud. Do we still need backup?

Yes. Cloud platforms protect against their own infrastructure failing, which is not the same as protecting you against your own people or an attacker using your credentials. A deleted SharePoint library, a mailbox cleared by a compromised account, or ransomware that syncs into OneDrive are all your problem, and platform retention windows are short. Independent backup is what turns those from crises into inconveniences.

How often do you test restores?

On a schedule agreed with you, and always after a significant change to your environment. A test restore means actually bringing data back and confirming it is usable — not reading a backup report. You get the result in writing, including anything that did not go as expected.

What makes a backup ransomware-resistant?

Design that assumes the attacker already has administrative access to your live systems. That means copies held away from the production environment, credentials for the backup platform that are separate from everyday admin accounts, and — where the platform supports it — immutable storage that cannot be altered or deleted for a set period by anybody, including us. Modern ransomware looks for backups first.

Where is backup data stored?

In EU or UK data centres, chosen to suit where you operate and any obligations you have about data location. We confirm the specific location for your service and record it in your documentation rather than leaving it as an assumption.

Can you take over backup that another provider set up?

Yes. We start by establishing what is genuinely protected today, which is frequently less than expected, and by running a test restore against the existing system. That gives you an honest baseline before anything is migrated or changed.

Not certain what is actually being backed up? Run the IT Health Check →

Ready to get started?

Would your backups get you back?

Most businesses have never tested. We will review what you have, run a restore against it, and tell you honestly what you are working with.

Start IT Health Check No signup • ~5 mins