<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Disaster-Recovery on GeekyRyan</title><link>https://rnemeth90.github.io/tags/disaster-recovery/</link><description>Recent content in Disaster-Recovery on GeekyRyan</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 11 Dec 2025 09:00:00 +0000</lastBuildDate><atom:link href="https://rnemeth90.github.io/tags/disaster-recovery/index.xml" rel="self" type="application/rss+xml"/><item><title>Running the 2025 Annual Disaster Recovery Exercise</title><link>https://rnemeth90.github.io/projects/2025-12-11-annual-dr-exercise-2025/</link><pubDate>Thu, 11 Dec 2025 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2025-12-11-annual-dr-exercise-2025/</guid><description>&lt;p&gt;Annual DR exercise for a customer with strict compliance requirements (SOC 2). Copy representative data to an isolated environment, failover to the DR site, run a full smoke test against the failed-over setup.&lt;/p&gt;&#10;&lt;p&gt;Running this for the second year in a row meant comparing against last time - what was slower than expected, what documentation was wrong, where the runbook needed updates. If each iteration of an annual DR exercise doesn&amp;rsquo;t make you faster and more confident, it&amp;rsquo;s just checking a compliance box, not actually improving your recovery posture.&lt;/p&gt;</description></item><item><title>Running an Annual Disaster Recovery Exercise for a Compliance-Driven Customer</title><link>https://rnemeth90.github.io/projects/2024-12-17-annual-dr-exercise-2024/</link><pubDate>Tue, 17 Dec 2024 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2024-12-17-annual-dr-exercise-2024/</guid><description>&lt;p&gt;Regulated customers (financial services, etc.) need documented proof that disaster recovery actually works, not just exists on paper. Annual DR exercise to satisfy that requirement.&lt;/p&gt;&#10;&lt;p&gt;Copy representative data to an isolated recovery environment, failover to the DR site, smoke test critical functionality. Coordinating with the customer on what data&amp;rsquo;s usable and hitting their testing window is as much the project as the technical failover.&lt;/p&gt;&#10;&lt;p&gt;Running it annually instead of only when disaster strikes is what makes the DR plan credible instead of theoretical.&lt;/p&gt;</description></item><item><title>Developing and Documenting a Disaster Recovery Plan</title><link>https://rnemeth90.github.io/projects/2024-08-28-developing-a-disaster-recovery-plan/</link><pubDate>Wed, 28 Aug 2024 09:00:00 +0000</pubDate><guid>https://rnemeth90.github.io/projects/2024-08-28-developing-a-disaster-recovery-plan/</guid><description>&lt;p&gt;DR plans usually exist in people&amp;rsquo;s heads until you actually need one - at which point tribal knowledge doesn&amp;rsquo;t cut it. Time to actually write one down.&lt;/p&gt;&#10;&lt;p&gt;Turn the ad hoc recovery knowledge into a structured plan: recovery point/time objectives, failover procedures, who does what during an incident. A document so someone who wasn&amp;rsquo;t in the room when the environment was built can still execute a recovery under pressure.&lt;/p&gt;&#10;&lt;p&gt;The plan becomes the runbook you actually use during the DR exercises, so it pays for itself immediately.&lt;/p&gt;</description></item></channel></rss>