Yaygın bir yanılgı vardır: "Azure'dayız, o yüzden verilerimiz güvende." Gerçekte Azure altyapıyı sağlar, ancak yedekleme ve felaket kurtarmayı yapılandırmak kuruma aittir. Bir silme hatası, fidye yazılımı veya bölge kesintisi karşısında hazırlıklı olmak için Azure Backup ve Azure Site Recovery'yi doğru kurmak gerekir. İşte rehberi.
Önce Kavramlar: RPO ve RTO
Tüm yedekleme ve DR planı iki hedefe dayanır:
- RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı. Yedekleme/çoğaltma sıklığını belirler.
- RTO (Recovery Time Objective): Sistemin yeniden ayağa kalkması gereken süre. Kurtarma mimarisini belirler.
Azure Backup: Veri Kaybına Karşı
Azure Backup; sanal makineleri, dosyaları, SQL ve diğer iş yüklerini Recovery Services Vault'ta yedekler. Yedekleme politikalarıyla sıklık ve saklama süresi tanımlanır. Önemli nokta: Azure varsayılan olarak yedek almaz — bu yapılandırılmalıdır. Fidye yazılımına karşı, yedeklerin değiştirilemez (immutable) ve silmeye karşı korumalı (soft delete) yapılandırılması kritiktir.
Azure Site Recovery: İş Sürekliliğine Karşı
Azure Site Recovery (ASR), iş yüklerini ikincil bir bölgeye sürekli çoğaltır. Birincil bölge erişilemez olduğunda, ikincil bölgede hızlı failover ile sistem devreye alınır. ASR yalnızca Azure'daki iş yükleri için değil, on-premises sistemlerin Azure'a felaket kurtarması için de kullanılabilir.
Backup ve Site Recovery: Birlikte Kullanım
| Kriter | Azure Backup | Azure Site Recovery |
|---|---|---|
| Amaç | Veri kaybı koruması | İş sürekliliği / failover |
| Çözdüğü senaryo | Silme, bozulma, fidye | Bölge/sunucu felaketi |
| Tipik RTO | Orta (geri yükleme süresi) | Düşük (hızlı failover) |
| Test imkânı | Geri yükleme testi | Test failover |
En Sık Hata: Test Etmemek
Yedekleme ve DR planının en kritik adımı, düzenli test yapmaktır. Azure Site Recovery'nin test failover özelliği, üretimi etkilemeden gerçek bir felaket senaryosunu denemenizi sağlar. Test edilmemiş bir DR planı, gerçek bir krizde çalışmama riski taşır — ve bu en kötü anda ortaya çıkar.
SSS
