Business continuity: backup and disaster recovery

The RTO (recovery time objective) is the maximum time a system can be down. The RPO (recovery point objective) is the maximum amount of information, measured in time, that can be lost. A billing system may require an RTO of a few hours and an RPO of minutes; a historical archive may tolerate days.

We define these objectives with the business areas, not only with IT, because they know the impact of an interruption. With the agreed objectives we choose backup frequency, the need for replication and the type of secondary site. That way the investment goes where it is truly needed.

The cloud makes it possible to have a secondary site without buying or maintaining a second data center. Critical servers are replicated to a region on AWS, Azure or Google Cloud and only fully started when needed, which lowers the cost compared with a traditional secondary site.

We design the failover procedure, user connections and the return to normal operations once the primary site recovers. Backups are stored as immutable copies separated from the main network to withstand ransomware; to reduce the likelihood of those attacks, you can complement the plan with a cybersecurity assessment.

A plan that is never tested loses validity with every change of systems or staff. We schedule restore tests and recovery drills with your team, measure actual times against the objectives and update the procedures with what we learn.

Daily backup checks and periodic tests can be included in our managed services, with a report showing the status of each copy.

Ransomware is now one of the most frequent causes of downtime. Attackers no longer just encrypt servers: they look for network-connected backups to encrypt them too and increase the pressure to pay. A modern continuity plan assumes this scenario and keeps at least one copy separate from the main environment, with different credentials and immutable retention.

It also defines how to verify that restored systems are clean before reconnecting them, so the problem is not reintroduced. This procedure is tested like any other recovery scenario.

In an emergency, time is lost deciding who does what. The plan defines specific roles: who declares the contingency, who carries out the technical recovery, who communicates with users and customers and who authorizes the return to normal operations. Each role has a backup person, so the plan never depends on a single individual.

Many organizations run some systems in the cloud and others in their own data center. A continuity plan must cover both worlds and the connections between them: if the cloud is available but the link to the office fails, users still cannot work. We review those dependencies, define alternatives for connectivity and identity, and document the recovery order so that the most important services come back first.

The same applies to software-as-a-service platforms such as email or CRM: although the provider operates them, your organization is responsible for backing up its own information and for knowing how to recover it.