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
30
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
12
Playing Nice with Your Friends: Database Diversity with Postgres FDWs
richyen
0
160
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
180
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
67
How to Ride Elephants Safely: Working with PostgreSQL when your DBA is not around
richyen
0
60
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
AI Agentをシステムに組み込む前にゆるく向き合ってみる
hayama17
0
200
LiDAR SLAMの実装とセンサ融合 ~Lie群からContinuous-Time LIOまで~
naokiakai
1
940
AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 / ai-agent-saas-virtualization
flatt_security
2
950
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
maruloop
0
190
“全部コピーしない”ファイルデータの活用 : — FSx for ONTAP × S3 Tables × Icebergで作るメタデータカタログ
yoshiki0705
0
400
初めてのDatabricks勉強会
taka_aki
2
230
NDIAS CTF 2026 問題解説会資料
bata_24
0
170
Agentic AI 時代のテスト手法: Kiro とはじめるプロパティベーステスト (AWS Summit Japan 2026 | DEV212)
ymhiroki
0
200
4人目のSREはAgent
tanimuyk
0
380
Docker Desktop不要の時代が来る? WSL標準の「wslc」で Linuxコンテナを動かしてみた.
ueponx
0
660
Amazon EVS で VCF 9.0 / 9.1 のサポート開始まとめ
mtoyoda
0
190
スタートアップにおけるアジャイルの実践について #shibuyagile
murabayashi
3
2k
Featured
See All Featured
Faster Mobile Websites
deanohume
310
32k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.2k
Ethics towards AI in product and experience design
skipperchong
2
320
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
170
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
240
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.9k
Building Applications with DynamoDB
mza
96
7.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
410
Designing for Timeless Needs
cassininazir
1
270
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.2k
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.