Backups and ransomware recovery: making sure you can actually restore

A school district's IT team discovers on a Saturday that ransomware has encrypted their file servers. They reach for the backups and find those encrypted too, because the backup server sat on the same network with the same administrator password. The ransom note arrives with a deadline. Modern ransomware groups look for backups first and destroy them before triggering the encryption, because an organization that can restore does not pay. Whether your backups survive that is the real test of a backup plan.

The 3-2-1 rule, updated for the cloud

The classic rule still holds: keep at least three copies of your data, on two different kinds of storage, with one copy away from the primary location. Ransomware adds two requirements:

• One copy that cannot be changed or deleted. Immutable storage, such as Amazon S3 Object Lock or a locked backup vault, refuses deletion until a retention period passes, even for an administrator. Stolen administrator credentials cannot erase it.
• One copy under separate access. A copy in a different cloud account, with different credentials, means a compromise of the main account does not reach it.

What needs backing up

For Cascade sites, Cascade is the master copy of your content. Published pages can be regenerated by republishing, so what the hosting layer must recover is the server configuration, certificates, CDN and DNS settings, and anything not managed in Cascade.

How fast, and how much loss

Two measures describe any recovery plan. Recovery time objective (RTO) is how long the site can be down. Recovery point objective (RPO) is how much recent data you can afford to lose. They trade off against cost:

The right pattern depends on the site. A public-safety alert page or a permit application portal justifies more than a departmental news site. The targets for your environments are defined in your service agreement.

Restore safely after ransomware

1. Do not restore over the evidence. Keep the compromised environment isolated so investigators can see how the attacker got in. See if your site is hacked: the first hour.
2. Restore into a clean, parallel environment, then switch traffic to it. Production keeps serving, or stays safely offline, while you verify.
3. Pick a restore point from before the intrusion, not just before the encryption. Attackers often sit in a network for days first.
4. Close the way in before going live: patch, rotate credentials, and require MFA on the accounts involved. Then watch the restored site closely for the first few days.

An untested backup is not a backup

Most failed recoveries fail on something nobody tried: a database dump that was never complete, a missing encryption key, a restore that takes far longer than anyone assumed. Restore tests on a schedule are the only way to know your recovery time is real. Government agencies are often asked to show evidence of restore testing in audits, and a dated record of each test answers that question.

How eWay handles backups

On environments eWay manages, backups are taken from running systems without locking the application and are encrypted at rest. Restores are non-destructive: eWay restores into a parallel instance, then repoints or copies back selectively, so production keeps serving. Restores can be granular, from a full environment to a database point in time or individual files. Code and configuration recover from source control independently of content, so a bad deploy is a rollback, not a restore. Restores are tested on a schedule, and recovery targets are defined in your service agreement.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times). Suspected ransomware is a P1: call as well.
• What needs restoring, and the last time you know it was correct
• Whether you suspect a security incident, so evidence is preserved

eWay customers can open a ticket in the support portal, email support@ewaycorp.com, or see calling support for critical issues. Related reading: backup, restore, and disaster recovery for Cascade sites.