Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Disaster Recovery: A Process, Not a Tool
Search
Richard Yen
June 09, 2026
Technology
45
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Disaster Recovery: A Process, Not a Tool
As presented at PGDay Boston 2026
Richard Yen
June 09, 2026
More Decks by Richard Yen
See All by Richard Yen
pg_stats: How Postgres Internal Stats Work
richyen
0
20
Playing Nice with Your Friends: Database Diversity with Postgres FDWs
richyen
0
170
How to Ride Elephants Safely: Working with Postgres when Your DBA is not Around
richyen
0
160
Scaling the Wall of Text: Best Practices for Logging in PostgreSQL
richyen
0
190
How to Ride Elephants Safely: Working with Postgres when Your DBA is not Around
richyen
0
140
How to Ride Elephants Safely: Working with Postgres when Your DBA is not Around
richyen
0
75
How to Ride Elephants Safely: Working with PostgreSQL when your DBA is not around
richyen
0
64
Playing Nice with Your Friends: Database Diversity with Postgres FDWs
richyen
0
160
Explaining EXPLAIN: A Dive Into PostgreSQL EXPLAIN Plans
richyen
0
170
Other Decks in Technology
See All in Technology
サイバー捜査員研修(後半)
nomizone
1
810
Forza Horizon 6 のテレメトリ機能で 自動運転に使えそうな学習データを集める話
henjin0
0
150
LLM・AIエージェントシステムベストプラクティス
shibuiwilliam
2
350
つくって納得、つかって実感! 大規模言語モデルことはじめ ver2.0
recruitengineers
PRO
3
1.2k
関東Kaggler会発表資料
takoi
1
180
Software Supply Chain Attackからクラウド環境を守るためにできること
lhazy
2
220
[ChatGPT Work LT]事務作業が苦手な人のための バックオフィスの「半」自動化
chimaki_iot
0
250
GitHub CopilotのFinOps- AI CreditのObservabilityと価値を生むためのエージェント設計
yuriemori
0
140
FORENSIA: ローカルLLMフォレンジックハーネス
sumeshi
2
350
侵入は突然に 〜 IoTマルウェアと悪用される家庭の機器 ~ / When Intrusion Strikes: IoT Malware and the Abuse of Home Devices
nttcom
0
1.5k
取引先から届く 「セキュリティチェックシート」の読み解き方
kamadamakoto
0
130
Bill One 開発エンジニア 紹介資料
sansan33
PRO
7
19k
Featured
See All Featured
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
460
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
460
Producing Creativity
orderedlist
PRO
348
40k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
330
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
73
41k
Discover your Explorer Soul
emna__ayadi
2
1.2k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
230
Code Review Best Practice
trishagee
74
20k
What's in a price? How to price your products and services
michaelherold
247
13k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
200
Documentation Writing (for coders)
carmenintech
77
5.4k
The Limits of Empathy - UXLibs8
cassininazir
1
590
Transcript
Disaster Recovery A Process, not a Tool June 9, 2026
Richard Yen
The Changed Landscape
None
The Changed Landscape •99.99% Uptime •p95, p99 metrics •Status pages
•Social Media affects reputation
Agenda 1. Where We Are 2. Where We Need to
Be 3. How We’ll Get There 4. Some Stories Along the Way
Where We Are
A disaster is any sustained event that compromises the system’s
availability, correctness, or business trust
How DR is Usually Done 1. Prepare 2. Prevent
How DR is Usually Done 1. Prepare 2. Prevent “An
ounce of prevention is worth a pound of cure”
Disaster Recovery is the act of restoring business operations
Where We Need to Be
Postgres Makes Recovery Easy • pg_dump/pg_restore • pg_basebackup • pg_stat_replication
• pg_stat_activity • Point-In-Time Recovery • repmgr/efm • Third-party backup tools
RPO & RTO
RPO & RTO – It’s going to cost you
RPO & RTO Talk to your leadership, and you’ll discover
how much it’s really worth to them
RPO 1. 24-hour RPO -- $ 2. 15-minute RPO --
$$ 3. Near-zero RPO -- $$$
RTO is your team’s ability to execute the DR plan
How We’ll Get There
3 Layers of DR Planning 1. Infrastructure failure 2. Procedural
failure 3. Human failure
3 Layers of DR Planning 1. Infrastructure failure 2. Procedural
failure 3. Human failure Recovery is not always about failing over
Runbook Engineering Should Assume 1. Stress 2. Chaos 3. Confusion
4. Exhaustion 5. Ambiguity
Runbook Engineering Should Assume 1. Stress 2. Chaos 3. Confusion
4. Exhaustion 5. Ambiguity
Runbook Engineering: Anti-patterns 1. Wiki Pages 2. Stale documents 3.
Unclear owner 4. Vague instructions
Runbook Engineering: Non-Technical Essentials 1. Incident Commander 2. Communications Owner
3. Notification Cadence 4. Escalation Chain 5. Risk Authorization
Runbook Validation 1. Can a new engineer follow it? 2.
Does it assume access? 3. Are commands and names current? 4. Does it get regular playtime?
Runbook Validation: Level Up Your Ability 1. Prove that your
Runbook works 2. Reduce the time it takes to complete 3. Simulate failure 4. Test with unavailable human resources
Runbook Validation: Level Up Your Ability 1. Prove that your
Runbook works 2. Reduce the time it takes to complete 3. Simulate failure 4. Test with unavailable human resources This is how you reduce RTO
Validation Metrics 1. Did recovery succeed? 2. How long did
each section take? 3. What vagueness needs to be clarified? 4. Identify documentation gaps
Validation Metrics 1. Did recovery succeed? 2. How long did
each section take? 3. What vagueness needs to be clarified? 4. Identify documentation gaps 5. Be Encouraging! Go out for dinner!
Don’t Blame, or You’ll Feel Lame 1. Communication is Key
2. People hide when they feel shame 3. When people don’t feel safe to ask, they guess 4. Guessing hurts your RTO
Make your RPO worth it by investing in your RTO
© Copyright Microsoft Corporation. All rights reserved.