Skip to content

Backup, DR and resilience

Recovery you have tested, not recovery you are hoping for.

Most organisations have backups. Far fewer know how long a full recovery would take, in what order systems would come back, or whether the backups would survive ransomware. We design recovery around your business priorities, test it on a schedule and show you the results.

Start with an Infrastructure Review
Row of server racks with blue status lights reflected in a polished floor.

What we cover

  • Recovery priorities: which systems matter most, how much data each can lose and how quickly each must be back, agreed with the business
  • Backup design for servers, Azure, Microsoft 365 and databases, with immutable and isolated copies that ransomware can't reach
  • Disaster recovery: failover to Azure or a second site, with the order of recovery and the dependencies worked out
  • Restore testing on a schedule, from single files to full applications
  • Recovery runbooks that are current, stored in your repository and used in the tests
  • Monitoring of every backup job, with failures fixed and reported

How it runs

  1. Assess: current backups, restore evidence, DR assumptions and recovery order reviewed against what the business needs.
  2. Design: recovery objectives per system, backup and DR architecture, and a test schedule.
  3. Build: backup and DR configured as code, with isolated copies and access separated from everyday admin accounts.
  4. Test: restores and failovers run on the schedule, with results and fixes recorded.
  5. Operate: under Managed Engineering, North Ark runs the platform, the tests and the runbooks, and reports results monthly.

Ransomware changes the design

Attackers target backups first, because deleting them makes a ransom more likely to be paid. Backup copies need to be immutable or isolated, backup administration needs separate credentials with MFA, and the recovery plan has to assume that identity and management systems are compromised too. We design and test for that case, not only for a failed server.

Evidence you can show

Auditors, insurers and regulators increasingly ask for proof of recovery. Each test produces a record of what was restored, how long it took and what had to be fixed, so you can answer those questions with evidence. For APRA-regulated entities, tests can be run against CPS 230 tolerance levels for critical operations.

Questions buyers ask

What is the difference between backup and disaster recovery?

Backup lets you get data back. Disaster recovery gets services running again, in the right order, within the time the business can tolerate. You need both, and they are designed differently.

Do you back up Microsoft 365?

Yes. Microsoft keeps the service running, but protecting your data from deletion, corruption and ransomware is your responsibility. We design and run backup for Exchange, SharePoint, OneDrive and Teams.

How often should we test restores?

Critical systems should be tested more often than the rest. We agree a schedule with you, typically including regular file and application restores and at least an annual full recovery exercise for critical services.

Do we need to change backup products?

Not necessarily. We work with the major backup platforms and design around what you already own where it is sound.

Can you run this without taking on other parts of the environment?

Yes. Backup and resilience can be a single Managed Engineering domain, alongside your internal team or MSP.

Start a conversation

Find out how long recovery would take before you need it.

Tell us which systems you could least afford to lose.

Talk to an Engineer