Felaket kurtarma: RTO ve RPO'ya göre aktif-pasif senaryoyu nasıl kurgularım?

Kısa cevap: Mimariyi sen seçmiyorsun, RTO 30dk / RPO 5dk seçiyor. Bu iki sayı, hangi felaket kurtarma stratejisini kuracağını tek başına belirliyor.

Asıl mesele şu: RPO ve RTO soyut hedefler değil, doğrudan teknik kararlara çevrilen rakamlar. Sayıyı oku, mimariyi ona göre kur.

1. RPO 5dk = sürekli replikasyon, gecelik dump değil. Region’lar arası streaming replikasyon (ya da RDS cross-region read replica) + WAL/PITR’ı S3’e gönder. Böylece bir felakette en fazla birkaç dakikalık veri kaybedersin, saatlerce değil. Gecelik yedek bu RPO’yu asla tutturamaz.
2. RTO 30dk = sıcak yedek (warm standby), sıfırdan kurmak değil. İkinci region’da terfi edilmeye hazır, önceden ayağa kaldırılmış bir kopya tut. 30 dakikada sıfırdan altyapı kuramazsın; o yüzden hazır beklesin.
3. Altyapıyı IaC ile önceden hazırla. İkinci region’ın ağ, sunucu ve yapılandırmasını Terraform ile kodla tanımla ki tek komutla ya da hazır halde dursun. Felaket anında elle tıklayarak kurmak RTO’yu patlatır.
4. Statik dosyaları ve DNS’i hazırla. Statik varlıkları S3 Cross-Region Replication ile ikinci region’a kopyala. Trafiği çevirmek için Route 53 health-check / failover routing kullan; birincil region sağlık kontrolünden düşünce trafiği otomatik olarak yedeğe yönlendirsin.
5. Aktif-aktif’e gitme — bu sayılar için fazla. RTO 30dk, aktif-aktif’in getirdiği maliyet ve karmaşıklığı gerektirmiyor. Aktif-pasif tam bu hedeflere oturuyor; ihtiyacın olmayan karmaşıklığı satın alma.

Sonuç: Ben olsam cross-region replica + PITR + Route 53 failover kurar, yedeği IaC ile önceden hazırlardım. Ekiplerin atladığı kısım şu: failover’ı düzenli prova et (game-day yap). Test edilmemiş bir felaket kurtarma planı, çalışacağına dair bir tahminden ibarettir. Cloud mu kendi sunucun mu sorusunu sade.dev’de ayrıca tartışıyorum.