Azure Backup ile Merkezi Yedekleme Yönetimi

Tarafındankomut
0 Comments

Yedekleme konusu her zaman “sonra yaparım” diye ertelenen, ta ki bir felaket anında “keşke yapmış olsaydım” diye pişman olunana kadar. Azure ortamında çalışıyorsanız ve hâlâ her VM için ayrı ayrı yedekleme stratejisi oluşturuyorsanız, bu yazı tam size göre. Azure Backup servisi ile merkezi bir yedekleme altyapısı kurmak hem düşündüğünüzden daha kolay hem de uzun vadede hayat kurtarıcı oluyor.

Azure Backup Nedir ve Neden Önemli?

Azure Backup, Microsoft’un tamamen yönetilen yedekleme servisidir. On-premises sunuculardan Azure VM’lerine, SQL Server veritabanlarından Azure File Share’lerine kadar pek çok kaynağı merkezi bir noktadan yönetmenizi sağlar. Klasik yedekleme çözümlerinden farkı şu: altyapı kurmanıza, tape yönetmenize ya da ayrı bir backup sunucusu ayağa kaldırmanıza gerek yok.

Gerçek dünya senaryosuna bakalım. 50 VM’den oluşan bir ortamı yönettiğinizi düşünün. Her VM için ayrı script yazıp cron job kurmak yerine, Azure Backup ile Recovery Services Vault oluşturuyor, bir Backup Policy tanımlıyor ve tüm VM’leri bu policy’ye bağlıyorsunuz. Merkezi monitoring, raporlama ve restore işlemleri tek bir yerden yönetilir hale geliyor.

Azure Backup’ın öne çıkan özellikleri:

  • Uygulama tutarlı (application-consistent) yedeklemeler
  • Coğrafi yedeklilik seçenekleri (LRS, GRS, ZRS)
  • Otomatik şifreleme (Azure Key Vault entegrasyonu)
  • Soft delete özelliği ile kazara silmelere karşı koruma
  • Cross-region restore imkânı
  • Azure Policy ile otomatik yedekleme zorunluluğu

Recovery Services Vault Oluşturma

Her şeyin başladığı yer Recovery Services Vault. Bunu yedekleme verilerinizin ve konfigürasyonlarınızın yaşadığı merkezi depo olarak düşünebilirsiniz. Hadi PowerShell ile oluşturalım:

# Az PowerShell modülü ile Recovery Services Vault oluşturma
az group create --name rg-backup-prod --location westeurope

az backup vault create 
  --resource-group rg-backup-prod 
  --name rsv-prod-westeurope 
  --location westeurope

# Vault'un storage redundancy tipini ayarla
az backup vault backup-properties set 
  --resource-group rg-backup-prod 
  --name rsv-prod-westeurope 
  --backup-storage-redundancy GeoRedundant

Storage redundancy seçenekleri:

  • LocallyRedundant (LRS): Veriler aynı bölgedeki 3 kopya olarak saklanır. Daha ucuz, daha az koruma.
  • GeoRedundant (GRS): Veriler farklı bir coğrafi bölgede de çoğaltılır. Üretim ortamları için önerilen.
  • ZoneRedundant (ZRS): Availability Zone’lar arasında dağıtım. Kritik iş yükleri için ideal.

Üretim ortamları için GRS tercih edin. “Bölge çöktü, ne yapacağız?” sorusunun cevabı GRS ile çok daha kolay oluyor.

Backup Policy Tasarımı

Policy, ne zaman yedek alınacağını ve ne kadar süre saklanacağını tanımlar. İyi tasarlanmış bir policy, hem RPO (Recovery Point Objective) hem de RTO (Recovery Time Objective) hedeflerinizi karşılamalı. Şöyle bir senaryo: kritik bir ERP sisteminiz var ve maksimum 4 saatlik veri kaybını tolere edebiliyorsunuz. Bu durumda günlük yedek yetmez, saatlik yedekleme gerekir.

# Standart bir backup policy oluşturma
az backup policy create 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --name policy-vm-daily 
  --policy '{
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2023-01-01T02:00:00Z"],
      "scheduleWeeklyFrequency": 0
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2023-01-01T02:00:00Z"],
        "retentionDuration": {
          "count": 30,
          "durationType": "Days"
        }
      },
      "weeklySchedule": {
        "daysOfTheWeek": ["Sunday"],
        "retentionTimes": ["2023-01-01T02:00:00Z"],
        "retentionDuration": {
          "count": 12,
          "durationType": "Weeks"
        }
      },
      "monthlySchedule": {
        "retentionScheduleFormatType": "Weekly",
        "retentionScheduleWeekly": {
          "daysOfTheWeek": ["Sunday"],
          "weeksOfTheMonth": ["First"]
        },
        "retentionTimes": ["2023-01-01T02:00:00Z"],
        "retentionDuration": {
          "count": 12,
          "durationType": "Months"
        }
      }
    },
    "timeZone": "Turkey Standard Time",
    "backupManagementType": "AzureIaasVM"
  }' 
  --workload-type VM

Bu policy şunu yapar: Her gece saat 02:00’de yedek alır, günlük yedekleri 30 gün, haftalık yedekleri 12 hafta, aylık yedekleri 12 ay saklar. GDPR veya yasal düzenlemeler nedeniyle daha uzun saklama gerektiren ortamlar için yıllık retention da eklenebilir.

Azure VM’leri Yedekleme Kapsamına Alma

Vault ve policy hazır olduğunda sıra VM’leri koruma altına almaya geliyor. Tek tek yapmak yerine script ile otomatize etmek çok daha verimli:

# Belirli bir resource group'taki tüm VM'leri yedekleme kapsamına alma
VAULT_NAME="rsv-prod-westeurope"
RG_BACKUP="rg-backup-prod"
POLICY_NAME="policy-vm-daily"
VM_RG="rg-prod-vms"

# VM listesini al
VM_LIST=$(az vm list --resource-group $VM_RG --query "[].name" -o tsv)

for VM in $VM_LIST; do
  echo "Enabling backup for VM: $VM"
  az backup protection enable-for-vm 
    --resource-group $RG_BACKUP 
    --vault-name $VAULT_NAME 
    --vm $VM 
    --vm-resource-group $VM_RG 
    --policy-name $POLICY_NAME
  
  echo "Backup enabled for $VM"
done

echo "Tum VM'ler yedekleme kapsamina alindi."

Büyük ortamlarda bu scripti çalıştırmadan önce bir test VM’i ile denemenizi öneririm. Özellikle çapraz subscription senaryolarında ek parametreler gerekiyor.

İlk Yedeklemeyi Manuel Tetikleme

Policy uygulandıktan sonra ilk yedekleme bir sonraki schedule’a kadar beklemez, manuel tetikleyebilirsiniz. Bu özellikle “sistemi devreye aldık, hemen bir yedek alalım” senaryolarında işe yarıyor:

# Manuel yedekleme başlatma
az backup protection backup-now 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --container-name "iaasvmcontainer;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --item-name "vm;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --retain-until 2024-12-31 
  --backup-management-type AzureIaasVM

# Job durumunu takip et
az backup job list 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --status InProgress 
  --output table

Container name formatına dikkat edin, bu Azure CLI’nın en sinir bozucu taraflarından biri. VM’in tam yolunu doğru formatta yazmak gerekiyor. Portal üzerinden yaparsanız bu detayları Azure otomatik doldurur.

SQL Server Yedeklemeleri

Sadece VM değil, VM içindeki SQL Server veritabanlarını da uygulama tutarlı şekilde yedekleyebilirsiniz. Bu, Volume Shadow Copy Service (VSS) kullanımıyla transaction-consistent snapshot almak anlamına geliyor:

# SQL Server workload için backup container kaydetme
az backup container register 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --backup-management-type AzureSql 
  --workload-type SQLDataBase 
  --resource-id "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-prod-vms/providers/Microsoft.Compute/virtualMachines/prod-sql-vm01"

# SQL veritabanlarını keşfet
az backup protectable-item list 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --workload-type SQLDataBase 
  --output table

# Belirli bir DB için yedekleme etkinleştir
az backup protection enable-for-azurewl 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --policy-name policy-sql-prod 
  --protectable-item-type SQLDataBase 
  --protectable-item-name "sqldatabase;mssqlserver;adventureworks" 
  --server-name prod-sql-vm01 
  --workload-type SQLDataBase

SQL yedeklemelerinde önemli bir nokta: log backup frequency’si. Saatlik full backup’a ek olarak her 15-30 dakikada bir log backup alabilirsiniz. Bu, point-in-time recovery için kritik.

Restore İşlemleri

Yedek almak önemli ama restore yapabilmek daha da önemli. En iyi test, gerçek bir restore denemesidir. Ayda bir “fire drill” yapmanızı ve restore süreçlerinizi test etmenizi öneririm. Alternatif konum restore örneği:

# Recovery point listesini al
az backup recoverypoint list 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --container-name "iaasvmcontainer;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --item-name "vm;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --backup-management-type AzureIaasVM 
  --output table

# Belirli bir diski alternatif konuma restore et
az backup restore restore-disks 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --container-name "iaasvmcontainer;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --item-name "vm;iaasvmcontainerv2;rg-prod-vms;prod-web-vm01" 
  --rp-name "DefaultBackupPolicy-prod-web-vm01-2024-01-15T0200" 
  --storage-account prod-restore-staging 
  --restore-to-staging-storage-account true 
  --target-resource-group rg-restore-staging

Restore sonrasında staging ortamında VM’i test edin, her şeyin düzgün çalıştığından emin olun, ardından production’a geçiş yapın. “Restore yaptık ama veriler eksikti” senaryosunu yaşamamak için bu adım çok önemli.

Monitoring ve Alerting

Yedekleme alındı mı, alınmadı mı nasıl anlayacaksınız? Azure Monitor ve Backup Reports burada devreye giriyor. Ama benim tercihim kritik alertleri e-posta ile almak:

# Backup failure alertleri için action group oluştur
az monitor action-group create 
  --resource-group rg-backup-prod 
  --name ag-backup-alerts 
  --short-name bkpalerts 
  --email-receiver name="SysAdmin" email-address="[email protected]"

# Backup job failure için alert kuralı
az monitor metrics alert create 
  --resource-group rg-backup-prod 
  --name "Backup-Job-Failure-Alert" 
  --scopes "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-backup-prod/providers/Microsoft.RecoveryServices/vaults/rsv-prod-westeurope" 
  --condition "count BackupJobsFailed > 0" 
  --window-size 1h 
  --evaluation-frequency 30m 
  --action "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-backup-prod/providers/microsoft.insights/actionGroups/ag-backup-alerts" 
  --description "Yedekleme islemi basarisiz oldu"

# Log Analytics workspace ile entegrasyon
az monitor diagnostic-settings create 
  --resource "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-backup-prod/providers/Microsoft.RecoveryServices/vaults/rsv-prod-westeurope" 
  --name "diag-backup-vault" 
  --logs '[{"category": "AzureBackupReport","enabled": true}]' 
  --workspace "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-prod"

Log Analytics entegrasyonu sağlandıktan sonra Workbooks ile özelleştirilmiş dashboard’lar oluşturabilirsiniz. Backup Reports özelliği de bunu görsel olarak sunuyor; hangi VM’lerin yedeklenmediğini, storage tüketimini ve trend analizlerini raporlayabiliyor.

Soft Delete ve Güvenlik Yapılandırması

Azure Backup’ın en değerli özelliklerinden biri Soft Delete. Birisi yanlışlıkla (ya da kötü niyetle) yedeklemeyi silmeye çalışırsa, veriler 14 gün daha korunuyor. Ransomware senaryolarında bu özellik hayat kurtarıyor:

# Soft delete durumunu kontrol et (varsayılan olarak açık gelir)
az backup vault backup-properties show 
  --resource-group rg-backup-prod 
  --name rsv-prod-westeurope 
  --query "softDeleteFeatureState"

# Immutable vault özelliğini etkinleştir (geri alınamaz!)
az backup vault resource-guard-mapping create 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --name VaultProxy 
  --resource-guard-id "/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-security/providers/Microsoft.DataProtection/resourceGuards/rg-prod-guard"

Soft Delete davranışı:

  • Silme işlemi tetiklendiğinde yedek “softdeleted” durumuna geçer
  • 14 gün boyunca geri getirilebilir
  • Bu süre zarfında storage ücreti tahakkuk etmeye devam eder
  • Süre sonunda veriler kalıcı olarak silinir

Kritik vault’lar için Multi-User Authorization (MUA) özelliğini de aktif etmenizi tavsiye ederim. Bu sayede vault üzerindeki kritik işlemler için ikinci bir yetkili onayı gerekiyor.

Azure Policy ile Otomatik Yedekleme Zorunluluğu

Büyük organizasyonlarda “bu VM’in yedeği var mı?” sorusunu her seferinde sormak yerine, Azure Policy ile yedekleme olmayan VM’leri otomatik olarak tespit edip raporlayabilir ya da uyumluluğu zorunlu kılabilirsiniz:

# Yedekleme olmayan VM'leri tespit eden policy ataması
az policy assignment create 
  --name "require-vm-backup" 
  --display-name "VM'lerde Azure Backup Zorunlu" 
  --policy "/providers/Microsoft.Authorization/policyDefinitions/9daedab3-fb2d-461e-b861-71790eead4f6" 
  --scope "/subscriptions/SUBSCRIPTION_ID" 
  --params '{
    "vaultLocation": {
      "value": "westeurope"
    },
    "inclusionTagName": {
      "value": "BackupRequired"
    },
    "inclusionTagValue": {
      "value": ["true"]
    }
  }' 
  --assign-identity 
  --location westeurope 
  --role "Backup Contributor"

# Uyumsuz kaynakları listele
az policy state list 
  --filter "policyAssignmentName eq 'require-vm-backup' and complianceState eq 'NonCompliant'" 
  --query "[].{Resource:resourceId, State:complianceState}" 
  --output table

Bu yaklaşım özellikle DevOps ekipleriyle çalışırken işe yarıyor. Geliştirici yeni bir VM açtığında, policy otomatik olarak yedeklemeyi etkinleştiriyor ya da uyarı gönderiyor. “Habersizce açılmış ve yedeği olmayan VM” vakasının önüne geçiliyor.

Maliyet Optimizasyonu

Azure Backup’ın en sık gözden kaçan kısmı maliyet tarafı. Yanlış yapılandırılmış retention policy’ler beklenmedik faturalara yol açabiliyor. Şu noktalara dikkat edin:

Retention sürelerini workload’a göre ayarlayın:

  • Test/geliştirme ortamları: 7 günlük günlük retention yeterli. Aylık veya yıllık backup’a gerek yok.
  • Üretim ortamları: 30 günlük günlük, 12 haftalık haftalık, 12 aylık aylık şeklinde katmanlı retention.
  • Yasal zorunluluk olan sistemler: 7 yıla kadar yıllık retention gerekebilir (finans, sağlık sektörü).

Instance ücreti vs storage ücreti:

  • Azure Backup, her korunan instance başına + kullanılan storage miktarına göre ücret alır
  • 500 GB altı VM’ler için ücretlendirme farklı hesaplanır
  • Cross-region restore özelliği ek maliyet oluşturur
# Vault'taki korunan itemleri ve tahmini maliyeti listele
az backup item list 
  --resource-group rg-backup-prod 
  --vault-name rsv-prod-westeurope 
  --backup-management-type AzureIaasVM 
  --query "[].{Name:properties.friendlyName, Status:properties.protectionStatus, LastBackup:properties.lastBackupTime, PolicyName:properties.policyName}" 
  --output table

Cost Management + Billing üzerinden “Azure Backup” resource tag’i ile filtreleme yaparak aylık harcamanızı takip edebilirsiniz. Bunu aylık rutin haline getirmenizi öneririm.

Gerçek Dünya Senaryosu: Çok Bölgeli Yedekleme Stratejisi

Hem Batı Avrupa hem de Kuzey Avrupa bölgelerinde VM’leriniz olduğunu düşünelim. Her bölgede ayrı vault oluşturmak ve bu vault’ları Azure Policy ile yönetmek en iyi pratik:

Önerilen mimari:

  • rsv-prod-westeurope: Batı Avrupa üretim kaynakları, GRS ile Kuzey Avrupa’ya çoğaltılır
  • rsv-prod-northeurope: Kuzey Avrupa üretim kaynakları, GRS ile Batı Avrupa’ya çoğaltılır
  • rsv-dev-westeurope: Geliştirme ortamları, LRS, 7 günlük retention
  • Tüm vault’lar merkezi Log Analytics workspace’e bağlanır
  • Backup Center dashboard’u tüm vault’ları birleşik görünümde sunar

Bu mimari sayesinde Batı Avrupa bölgesi tamamen kullanılamaz hale gelse bile, Cross-Region Restore özelliği ile Kuzey Avrupa’dan recovery başlatılabiliyor.

Backup Center ile Merkezi Yönetim

Birden fazla vault yönetiyorsanız Backup Center’ı mutlaka kullanın. Portal üzerinden erişebildiğiniz bu merkezi kontrol paneli, tüm vault’ların yedekleme durumunu, başarısız işleri ve uyum raporlarını tek ekranda gösteriyor:

# Backup Center üzerinden tüm vault'lardaki başarısız işleri sorgula
az backup job list 
  --use-secondary-region false 
  --status Failed 
  --output table 
  --query "[?properties.entityFriendlyName != null].{VM:properties.entityFriendlyName, Operation:properties.operation, StartTime:properties.startTime, Error:properties.errorDetails[0].errorMessage}"

Backup Center ayrıca “Backup Readiness Report” oluşturmanıza da imkan tanıyor. Bu raporu haftalık olarak yönetime sunmak, “yedekleme durumunuz nasıl?” sorusuna görsel ve anlaşılır bir cevap vermek açısından çok değerli.

Sonuç

Azure Backup, doğru yapılandırıldığında büyük bir yük alıyor omuzlarınızdan. Recovery Services Vault ile başlıyor, Backup Policy ile devam ediyor, Azure Policy entegrasyonu ile hiç yedeklenmemiş kaynak kalmamasını garanti altına alıyorsunuz. Monitoring tarafını Log Analytics ile kapatıp Soft Delete ve MUA ile güvenliği sağlıyorsunuz.

En önemli hatırlatma: Yedek almak kadar restore test etmek de kritik. Ayda bir test restore yapın, RTO sürenizi gerçek koşullarda ölçün ve ekibin restore prosedürlerine hâkim olduğundan emin olun. “Yedek var ama nasıl restore edeceğimizi bilmiyoruz” vakasıyla karşılaşmak, hiç yedek olmamaktan farklı değil.

Vault maliyet takibini ihmal etmeyin. Özellikle politikasız büyüyen ortamlarda backup storage maliyetleri sürpriz faturalara dönüşebilir. Retention policy’leri workload kritikliğine göre segmente edin, dev ortamları üretim standardında yedeklemek gereksiz maliyet yaratır.

Bu adımları uyguladıktan sonra gece uyurken “acaba yedekler alınıyor mu?” diye endişelenmek yerine, alarmların sizi uyandıracağından emin bir şekilde dinlenebilirsiniz. Ve bu, her sysadmin için paha biçilmez bir huzurdur.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir