
Infrastructure as Code ile Disaster Recovery Planı Oluşturmak
Sunucu arızaları, veri merkezi kesintileri veya siber saldırılar her an gerçekleşebilir. Infrastructure as Code (IaC) ile disaster recovery planınızı kod olarak tanımlayarak, felaket anında dakikalar içinde altyapınızı yeniden oluşturabilirsiniz. Bu rehberde RPO/RTO kavramlarından Terraform multi-re
Ahmet Yılmaz
Kıdemli Altyapı Mühendisi
Sunucu arızaları, veri merkezi kesintileri veya siber saldırılar her an gerçekleşebilir. Infrastructure as Code (IaC) ile disaster recovery planınızı kod olarak tanımlayarak, felaket anında dakikalar içinde altyapınızı yeniden oluşturabilirsiniz. Bu rehberde RPO/RTO kavramlarından Terraform multi-region kurulumuna, otomatik yedeklemeden failover otomasyonuna kadar tüm DR sürecini inceliyoruz.
DR Temel Kavramları: RPO ve RTO
Disaster recovery planının temelini iki kritik metrik oluşturur: RPO (Recovery Point Objective) kabul edilebilir veri kaybı süresini, RTO (Recovery Time Objective) ise kabul edilebilir kesinti süresini tanımlar.
| Metrik | Tanım | Örnek | IaC ile Hedef |
|---|---|---|---|
| RPO | Maksimum veri kaybı süresi | Son 1 saatlik veri | Dakikalar (otomatik replikasyon) |
| RTO | Maksimum kesinti süresi | 4 saat | Dakikalar (otomatik failover) |
| MTTR | Ortalama onarım süresi | 2 saat | Dakikalar (kod ile yeniden oluşturma) |
💡 İpucu: RPO ve RTO değerlerini iş gereksinimlerinize göre belirleyin. E-ticaret siteleri için RPO 5 dakika ve RTO 15 dakika hedeflenirken, dahili araçlar için RPO 1 saat ve RTO 4 saat kabul edilebilir olabilir.
Terraform ile Multi-Region Altyapı
Terraform modülleri kullanarak birincil ve DR bölgelerinde aynı altyapıyı kod olarak tanımlayabilirsiniz. Bu sayede felaket anında DR bölgesini dakikalar içinde aktif hale getirebilirsiniz.
# Birincil bölge (Primary)
module "primary" {
source = "./modules/infrastructure"
region = "eu-west-1"
env = "production"
is_primary = true
instance_count = 3
instance_type = "c5.xlarge"
db_multi_az = true
}
# DR bölgesi (Standby)
module "dr" {
source = "./modules/infrastructure"
region = "us-east-1"
env = "dr"
is_primary = false
# DR'da daha az kaynak (maliyet optimizasyonu)
instance_count = 1
instance_type = "c5.large"
db_multi_az = false
}
IaC ile Otomatik Yedekleme Yapılandırması
Yedekleme stratejinizi de kod olarak tanımlayarak, tutarlı ve tekrarlanabilir backup süreçleri oluşturabilirsiniz. Aşağıdaki Terraform konfigürasyonu veritabanı ve dosya sistemi yedeklemelerini otomatikleştirir.
# Otomatik veritabanı yedekleme
resource "aws_db_instance" "primary" {
identifier = "app-db-primary"
engine = "postgres"
engine_version = "15.4"
instance_class = "db.r6g.large"
# Yedekleme ayarları
backup_retention_period = 30
backup_window = "03:00-04:00"
copy_tags_to_snapshot = true
# Cross-region replikasyon
replicate_source_db = null
}
# DR bölgesine cross-region replica
resource "aws_db_instance" "dr_replica" {
provider = aws.dr
replicate_source_db = aws_db_instance.primary.arn
instance_class = "db.r6g.large"
}
Failover Otomasyonu
Manuel failover süreçleri hata yapma riskini artırır ve zaman kaybettirir. DNS tabanlı failover ile otomatik geçiş yapılandırabilirsiniz.
# Health check - birincil bölge
resource "aws_route53_health_check" "primary" {
fqdn = "primary.example.com"
port = 443
type = "HTTPS"
resource_path = "/health"
failure_threshold = 3
request_interval = 10
}
# DNS failover kaydı
resource "aws_route53_record" "primary" {
zone_id = var.zone_id
name = "app.example.com"
type = "A"
set_identifier = "primary"
health_check_id = aws_route53_health_check.primary.id
failover_routing_policy {
type = "PRIMARY"
}
alias {
name = module.primary.lb_dns_name
zone_id = module.primary.lb_zone_id
}
}
⚠️ Dikkat: DNS failover'da TTL değerini düşük tutun (60 saniye gibi). Yüksek TTL değerleri, failover sonrası kullanıcıların hala eski IP'ye yönlendirilmesine neden olabilir.
DR Test Checklist
DR planınızı düzenli olarak test etmeden, gerçek bir felaket anında çalışacağından emin olamazsınız. Aşağıdaki checklist'i üç ayda bir uygulayın.
- ✅ Terraform state dosyasının remote backend'de güncel olduğunu doğrulayın
-
✅
DR bölgesinde
terraform plançalıştırarak drift kontrolü yapın - ✅ Veritabanı replica'sının senkronizasyon gecikmesini kontrol edin (lag < 1 dakika)
- ✅ DNS failover'ı simüle ederek geçiş süresini ölçün
- ✅ DR ortamında uygulama smoke testlerini çalıştırın
- ✅ Yedeklerden geri yükleme (restore) testi yapın
- ✅ Failback (birincil bölgeye geri dönüş) prosedürünü test edin
- ✅ Tüm sonuçları dokümante edin ve RPO/RTO hedeflerini karşılayıp karşılamadığını raporlayın
Terraform temelleri için Terraform IaC rehberimizi, yedekleme stratejileri için Snapshot ve Yedekleme rehberimizi, sunucu izleme için Prometheus + Grafana rehberimizi inceleyin. HashiCorp Terraform Tutorials ve AWS Disaster Recovery Whitepaper ek kaynak olarak faydalıdır.
Sıkça Sorulan Sorular
IaC olmadan disaster recovery yapılamaz mı?
Yapılabilir ancak manuel süreçler hata yapma riskini artırır ve kurtarma süresini uzatır. IaC ile altyapınızı dakikalar içinde yeniden oluşturabilirsiniz. Manuel kurulumda saatler hatta günler sürebilecek işlemler otomatikleşir.
DR bölgesi sürekli çalışmak zorunda mı?
Hayır. Warm standby (minimum kaynaklarla çalışan) veya pilot light (sadece veritabanı replikasyonu) stratejileri ile maliyeti düşürebilirsiniz. Felaket anında IaC ile kaynakları hızla ölçeklendirebilirsiniz.
Terraform state dosyası kaybolursa ne olur?
State dosyası kaybolursa Terraform mevcut altyapıyı tanıyamaz. Bu nedenle state'i S3 + DynamoDB gibi remote backend'de saklayın, versiyonlama ve kilitleme aktif olsun. State dosyasının da yedeklenmesi kritiktir.
DR testleri ne sıklıkla yapılmalı?
En az üç ayda bir tam DR testi yapılmalıdır. Kritik sistemler için aylık testler önerilir. Her büyük altyapı değişikliğinden sonra da DR planını doğrulamak gerekir.
Sonuç
Infrastructure as Code ile disaster recovery planınızı versiyonlanabilir, test edilebilir ve tekrarlanabilir hale getirin. Terraform multi-region modülleri ile altyapınızı tanımlayın, otomatik yedekleme ve failover mekanizmalarını kurun ve düzenli DR testleri ile planınızın çalıştığından emin olun.
Felaket Kurtarma İçin Güvenilir Altyapı
Hosted Cloud sunucuları ile DR planınızı güvenle uygulayın.
Bulut Sunucu Planlarını İncele →Ahmet Yılmaz
Kıdemli Altyapı Mühendisi
10 yılı aşkın bulut altyapısı ve DevOps deneyimiyle Hosted Cloud'un teknik ekibinde yer almaktadır. Kubernetes, Terraform ve yüksek erişilebilirlik mimarileri üzerine uzmanlaşmıştır.
Yorumlar yakında