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
38
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
15
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
68
How to Ride Elephants Safely: Working with PostgreSQL when your DBA is not around
richyen
0
62
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時代のPlaywright活用(システムテストを自動化する ー 実行エンジンにPla ywrightを選んだ理由)
ynisqa1988
0
130
タスクの複雑さでモデルを選ぶ ── Thompson Samplingで動かす“トークン/コスト最適化
satohy0323
0
550
Network Firewallやっていき!
news_it_enj
0
170
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
230
AIコード生成×サプライチェーン攻撃 — PHPが直面する“二重の信頼問題
shinyasaita
0
190
「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル
jnishime_dresscode
0
880
kintone の AI コワーカーを、 Anthropic にエージェントを"ホストさせて"作った話 #devkinmeetup
sugimomoto
0
110
脱金融のフューチャー・デザイン / Future Design Beyond Finance
ks91
PRO
0
160
AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
sakajunquality
2
3.7k
関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす / Pure at the Core, Effects at the Edge: Bringing Functional Thinking into TypeScript
kaminashi
2
130
人を動かすのは時間ではなく、納得感 〜新任EMが入社3ヶ月、組織を2回変えた話〜
kakehashi
PRO
3
270
Featured
See All Featured
Leo the Paperboy
mayatellez
8
1.9k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
460
Balancing Empowerment & Direction
lara
6
1.2k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
390
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
How GitHub (no longer) Works
holman
316
150k
sira's awesome portfolio website redesign presentation
elsirapls
0
300
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
170
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Exploring anti-patterns in Rails
aemeredith
3
440
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
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.