Resource
Disaster recovery for Pacific Northwest businesses
Generic disaster recovery templates assume a generic disaster. This region has a specific risk profile, and one feature of it invalidates the most common recovery design: a backup copy held in a data centre 20 miles away sits inside the same seismic zone as the original.
Five risks worth designing around
The first one shapes where your recovery copy should live. The second is the one you will most likely actually experience.
| Risk | Profile |
|---|---|
| Cascadia subduction eventA recovery copy inside the same seismic zone provides no protection | Regional, catastrophic, low frequency |
| Winter windstorm and icePower loss is the usual failure, not equipment damage | Local, multi day, near annual |
| Wildfire smokeSystems stay healthy. The building becomes unusable | Regional, days to weeks, increasingly common |
| Single carrier fibre routingCommon through parts of the Port and Kent Valley corridor | Local, hours to days |
| FloodingRelevant on valley floors and near the Puyallup river system | Local, seasonal |
What the plan needs to contain
The technical half of disaster recovery is largely solved by tested backups. The half that fails during real events is the human sequence, because nobody wrote it down.
- Who declares an incident, and who they call if that person is unreachable
- How staff are contacted when email and the phone system are both unavailable
- The order in which systems come back, agreed with the business rather than assumed by IT
- What the business does manually in the meantime, and how that work is reconciled afterwards
- Where the recovery copy lives, and in which seismic zone
- When the plan was last tested, and what the test found
The fourth item is the one most often missing. If order entry is down for six hours, somebody needs to know whether orders are taken on paper and how they are reconciled afterwards. That is a business decision made calmly in advance, not a technical one made under pressure.
The separation question
Ask your provider one question: which region does our recovery copy live in, and is it inside the Cascadia zone?
A surprising number of businesses discover that their offsite backup is offsite in the sense of being in a different building, which addresses a fire or a theft and addresses nothing about the scenario that dominates regional planning.
Moving a recovery copy to a genuinely separate region is usually inexpensive and frequently a configuration change rather than a project. It is one of the higher value questions to ask, and it takes a minute to answer if the documentation is any good.
Common questions
Answered before you ask.
Is cloud backup enough for earthquake risk?
It depends entirely on where the cloud region sits, and a great many businesses have never checked. A backup replicated to a data centre in the same region satisfies most compliance checklists and provides no protection against a regional seismic event, because both copies are inside the affected zone. Geographic separation for this specific risk means a different seismic zone, not a different building or a different county.
What is the most likely disaster we will actually face?
A multi day power loss from a winter storm, by a wide margin. Cascadia dominates the conversation because the consequences are severe, but the event businesses in this region actually experience with some regularity is losing power for two or three days, sometimes with road access affected. Planning that only addresses the catastrophic case leaves the common one unhandled.
How does wildfire smoke fit into disaster recovery?
It is an unusual category because nothing technical fails. Servers run, the network is fine, the internet works. What becomes unavailable is the building, and sometimes the ability of staff to travel safely. That makes it a remote work continuity problem rather than a technical recovery one, and it is worth planning for separately since the controls are different: device management, remote access capacity and a communication plan rather than backups.
How often should the plan be tested?
Restores should be tested continuously as part of normal backup operation. The plan itself, meaning the human sequence of who does what, deserves a walkthrough at least annually and after any material change to the environment or the team. A plan describing systems you retired two years ago, or naming a person who left, is worse than no plan because it creates false confidence.
Related
Read next.
Backup and disaster recovery
Immutable backups with tested restores and a defined recovery window.
Network and infrastructure
Firewalls, switching, Wi-Fi, servers and remote access, monitored.
Ransomware protection for small business
How attacks actually start, which controls stop them, and what to do in the first hour.
What is included in managed IT services
A line by line scope, including the exclusions most contracts hide.
Cloud services and migration
Azure, hybrid environments and planned server retirement.
Start with the assessment, not the contract.
We document what you have, test whether your backups restore, and give you the findings in writing. Yours to keep either way.