Bulut Ortamında Snapshot Yönetimi: AWS EBS ve Azure Disk Anlık Görüntüleri

Yazar:komut.io ekibi Snapshot ve Disk Klonlama
0 Yorum

Bulut ortamında çalışan bir sistemi yönetirken en çok korktuğunuz şey nedir? Büyük ihtimalle “bir şeyleri batırıp geri dönememe” korkusudur. İşte snapshot’lar tam da bu noktada devreye girer. Hem AWS EBS hem de Azure Disk anlık görüntüleri, sistem yöneticilerinin gece rahat uyumasını sağlayan o kritik güvenlik ağıdır. Ama bu araçları doğru kullanmak, sadece “snapshot al” demekten çok daha fazlasını gerektirir. Retention politikaları, maliyet optimizasyonu, cross-region replikasyon ve otomasyonu bir arada düşünmeniz gerekiyor. Bu yazıda her iki platformu da gerçek dünya senaryolarıyla ele alacağız.

Snapshot Nedir ve Neden Bu Kadar Önemlidir?

Snapshot, bir disk biriminin belirli bir andaki tutarlı kopyasıdır. Sanal makine çalışırken bile alınabilir olması, onu geleneksel yedekleme yöntemlerinden ayıran en önemli özelliktir. Ancak snapshot’ları tam yedekleme yerine geçen bir çözüm olarak düşünmek büyük bir hata olur.

Snapshot’ların sağladığı avantajlar:

  • Hızlı geri dönüş imkanı (dakikalar içinde)
  • Incremental yapı sayesinde düşük depolama maliyeti
  • Uygulama tutarlılığı (uygun yapılandırmayla)
  • Cross-region ve cross-account kopyalama imkanı
  • Test ortamları için hızlı disk klonlama

Dikkat edilmesi gereken kısıtlamalar:

  • Snapshot, tam bir DR (Disaster Recovery) çözümü değildir
  • Uygulama tutarlılığı için ek önlemler gerekebilir
  • Çok sayıda snapshot birikmesi maliyetleri artırır
  • Büyük disklerde ilk snapshot uzun sürebilir

AWS EBS Snapshot Temelleri

AWS’de EBS snapshot’ları Amazon S3 üzerinde saklanır, ancak bu S3 bucket’larına doğrudan erişemezsiniz. AWS bu süreci tamamen kendi içinde yönetir. İlk snapshot tam kopyadır, sonrakiler incremental çalışır. Yani 500 GB’lık bir disk için ikinci snapshot’ta yalnızca değişen bloklar kopyalanır.

AWS CLI ile Temel Snapshot Operasyonları

Önce basit bir snapshot alma işlemiyle başlayalım:

# Belirli bir EBS volume'ün snapshot'ını al
aws ec2 create-snapshot 
  --volume-id vol-0a1b2c3d4e5f67890 
  --description "Production DB - $(date +%Y-%m-%d)" 
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=prod-db-snapshot},{Key=Environment,Value=production},{Key=CreatedBy,Value=manual}]'

Snapshot durumunu takip etmek için:

# Snapshot tamamlanma durumunu kontrol et
aws ec2 describe-snapshots 
  --snapshot-ids snap-0abc123def456789 
  --query 'Snapshots[0].{State:State,Progress:Progress,StartTime:StartTime}' 
  --output table

# Hesabınızdaki tüm snapshot'ları listele
aws ec2 describe-snapshots 
  --owner-ids self 
  --query 'Snapshots[*].{ID:SnapshotId,Volume:VolumeId,Size:VolumeSize,State:State,Date:StartTime}' 
  --output table

Otomatik Snapshot Politikası: AWS Data Lifecycle Manager

AWS’nin sunduğu Data Lifecycle Manager (DLM) servisi, snapshot otomasyonu için en temiz çözümdür. Elle script yazmak yerine DLM politikaları tanımlamanızı öneririm.

# DLM politikası oluştur
aws dlm create-lifecycle-policy 
  --description "Daily EBS Snapshots - Production" 
  --state ENABLED 
  --execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole 
  --policy-details '{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "Backup", "Value": "true"}],
    "Schedules": [{
      "Name": "Daily-Snapshots",
      "CreateRule": {
        "Interval": 24,
        "IntervalUnit": "HOURS",
        "Times": ["02:00"]
      },
      "RetainRule": {
        "Count": 7
      },
      "TagsToAdd": [{"Key": "ManagedBy", "Value": "DLM"}],
      "CopyTags": true
    }]
  }'

Bu politika, Backup=true etiketine sahip tüm EBS volume’ler için gece saat 02:00’de otomatik snapshot alır ve son 7 tanesini saklar. Retention politikasını doğru kurmak, aylık faturanızı kontrol altında tutmanın en kritik adımıdır.

Cross-Region Snapshot Kopyalama

Tek bölgede snapshot saklamak gerçek bir DR senaryosu için yeterli değildir. Snapshot’larınızı farklı bir region’a kopyalamanız gerekir:

#!/bin/bash
# cross-region-snapshot-copy.sh
# Production snapshot'larını DR region'a kopyala

SOURCE_REGION="eu-west-1"
DEST_REGION="eu-central-1"
KMS_KEY_ID="arn:aws:kms:eu-central-1:123456789012:key/mrk-abc123"

# Son 24 saat içinde oluşturulan snapshot'ları bul
SNAPSHOTS=$(aws ec2 describe-snapshots 
  --owner-ids self 
  --region "$SOURCE_REGION" 
  --filters 
    "Name=tag:Environment,Values=production" 
    "Name=tag:ManagedBy,Values=DLM" 
  --query 'Snapshots[?StartTime>=`'"$(date -u -d '24 hours ago' '+%Y-%m-%dT%H:%M:%S')"'`].SnapshotId' 
  --output text)

for SNAP_ID in $SNAPSHOTS; do
  echo "Kopyalanıyor: $SNAP_ID -> $DEST_REGION"
  
  NEW_SNAP=$(aws ec2 copy-snapshot 
    --source-region "$SOURCE_REGION" 
    --source-snapshot-id "$SNAP_ID" 
    --destination-region "$DEST_REGION" 
    --description "DR Copy from $SOURCE_REGION - $(date +%Y-%m-%d)" 
    --encrypted 
    --kms-key-id "$KMS_KEY_ID" 
    --region "$DEST_REGION" 
    --query 'SnapshotId' 
    --output text)
  
  echo "DR snapshot oluşturuldu: $NEW_SNAP"
  
  # Tag ekle
  aws ec2 create-tags 
    --resources "$NEW_SNAP" 
    --tags Key=SourceSnapshot,Value="$SNAP_ID" Key=CopiedFrom,Value="$SOURCE_REGION" 
    --region "$DEST_REGION"
done

Azure Disk Snapshot Yönetimi

Azure tarafında managed disk snapshot’ları biraz farklı bir yaklaşım gerektirir. Azure’da snapshot’lar disk kaynakları olarak yönetilir ve bir resource group’a bağlıdır. Incremental snapshot özelliği Azure’da da mevcuttur ve --incremental parametresiyle etkinleştirilir.

Azure CLI ile Snapshot Operasyonları

# Azure'da incremental snapshot oluştur
az snapshot create 
  --name "prod-db-snapshot-$(date +%Y%m%d)" 
  --resource-group rg-production 
  --source /subscriptions/sub-id/resourceGroups/rg-production/providers/Microsoft.Compute/disks/prod-db-disk 
  --incremental true 
  --sku Standard_ZRS 
  --tags Environment=production CreatedBy=sysadmin BackupDate=$(date +%Y-%m-%d)

# Mevcut snapshot'ları listele
az snapshot list 
  --resource-group rg-production 
  --query '[].{Name:name, DiskSize:diskSizeGb, State:provisioningState, Time:timeCreated}' 
  --output table

# Belirli bir snapshot'ın detaylarını gör
az snapshot show 
  --name prod-db-snapshot-20241201 
  --resource-group rg-production

Azure’da Otomatik Snapshot: PowerShell ile Zamanlama

Azure’da snapshot otomasyonu için Azure Automation veya PowerShell script’leri kullanabilirsiniz. Aşağıdaki script bir Azure Automation runbook olarak çalışacak şekilde tasarlanmıştır:

# Azure CLI ile toplu snapshot alma scripti
#!/bin/bash
# azure-auto-snapshot.sh

RESOURCE_GROUP="rg-production"
RETENTION_DAYS=7

echo "=== Azure Disk Snapshot Başlatılıyor ==="
echo "Tarih: $(date)"

# Backup tag'i olan tüm diskleri bul
DISKS=$(az disk list 
  --resource-group "$RESOURCE_GROUP" 
  --query '[?tags.Backup==`true`].{name:name, id:id}' 
  --output tsv)

while IFS=$'t' read -r DISK_NAME DISK_ID; do
  SNAPSHOT_NAME="${DISK_NAME}-$(date +%Y%m%d-%H%M)"
  
  echo "Snapshot alınıyor: $DISK_NAME"
  
  az snapshot create 
    --name "$SNAPSHOT_NAME" 
    --resource-group "$RESOURCE_GROUP" 
    --source "$DISK_ID" 
    --incremental true 
    --tags 
      SourceDisk="$DISK_NAME" 
      CreatedDate="$(date +%Y-%m-%d)" 
      RetentionDays="$RETENTION_DAYS" 
      ManagedBy=automation 
    --output none
    
  if [ $? -eq 0 ]; then
    echo "Basarili: $SNAPSHOT_NAME"
  else
    echo "HATA: $DISK_NAME icin snapshot alinamadi!"
  fi
done <<< "$DISKS"

# Eski snapshot'ları temizle
echo "=== Eski Snapshot'lar Temizleniyor ==="
CUTOFF_DATE=$(date -d "$RETENTION_DAYS days ago" +%Y-%m-%d)

az snapshot list 
  --resource-group "$RESOURCE_GROUP" 
  --query "[?tags.ManagedBy=='automation' && timeCreated<='${CUTOFF_DATE}'].name" 
  --output tsv | while read SNAP_NAME; do
    echo "Siliniyor: $SNAP_NAME"
    az snapshot delete 
      --name "$SNAP_NAME" 
      --resource-group "$RESOURCE_GROUP" 
      --yes
  done

echo "=== Islem Tamamlandi ==="

Azure Cross-Region Kopyalama

Azure’da snapshot’ları başka bir region’a kopyalamak için kaynak snapshot’ı hedef region’da yeniden oluşturmanız gerekir:

# Azure snapshot'ı farklı region'a kopyala
SOURCE_REGION="westeurope"
DEST_REGION="northeurope"
SOURCE_SNAPSHOT="prod-db-snapshot-20241201"
SOURCE_RG="rg-production"
DEST_RG="rg-dr"

# Kaynak snapshot ID'sini al
SOURCE_SNAPSHOT_ID=$(az snapshot show 
  --name "$SOURCE_SNAPSHOT" 
  --resource-group "$SOURCE_RG" 
  --query 'id' 
  --output tsv)

# Hedef region'da snapshot oluştur
az snapshot create 
  --name "dr-${SOURCE_SNAPSHOT}" 
  --resource-group "$DEST_RG" 
  --location "$DEST_REGION" 
  --source "$SOURCE_SNAPSHOT_ID" 
  --incremental false 
  --sku Standard_ZRS 
  --tags 
    SourceSnapshot="$SOURCE_SNAPSHOT" 
    CopiedFrom="$SOURCE_REGION" 
    CopyDate="$(date +%Y-%m-%d)"

echo "DR snapshot olusturuldu: dr-${SOURCE_SNAPSHOT} -> $DEST_REGION"

Gerçek Dünya Senaryosu: Veritabanı Sunucusu Geri Yükleme

Diyelim ki production ortamında bir PostgreSQL sunucusunun diski bozuldu veya kritik bir veri silinmesi yaşandı. İşte bu durumda nasıl hareket edersiniz:

AWS üzerinde senaryo:

#!/bin/bash
# ebs-restore-from-snapshot.sh
# Production veritabanını snapshot'tan geri yükle

SNAPSHOT_ID="snap-0abc123def456789"
AVAILABILITY_ZONE="eu-west-1a"
VOLUME_TYPE="gp3"
IOPS=3000
THROUGHPUT=125

echo "Snapshot'tan yeni volume oluşturuluyor..."

NEW_VOLUME_ID=$(aws ec2 create-volume 
  --snapshot-id "$SNAPSHOT_ID" 
  --availability-zone "$AVAILABILITY_ZONE" 
  --volume-type "$VOLUME_TYPE" 
  --iops "$IOPS" 
  --throughput "$THROUGHPUT" 
  --encrypted 
  --tag-specifications "ResourceType=volume,Tags=[{Key=Name,Value=restored-db-volume},{Key=RestoredFrom,Value=$SNAPSHOT_ID},{Key=RestoreDate,Value=$(date +%Y-%m-%d)}]" 
  --query 'VolumeId' 
  --output text)

echo "Yeni volume ID: $NEW_VOLUME_ID"

# Volume'ün available durumuna gelmesini bekle
echo "Volume hazirlanıyor..."
aws ec2 wait volume-available --volume-ids "$NEW_VOLUME_ID"
echo "Volume hazir!"

# Eski volume'ü instance'dan ayır
# aws ec2 detach-volume --volume-id vol-OLD_VOLUME_ID

# Yeni volume'ü attach et
# aws ec2 attach-volume 
#   --volume-id "$NEW_VOLUME_ID" 
#   --instance-id i-INSTANCE_ID 
#   --device /dev/sdf

echo "Geri yukleme tamamlandi. Volume: $NEW_VOLUME_ID"
echo "Instance'a attach etmeyi unutmayin!"

Bu script’i çalıştırdıktan sonra yapmanız gerekenler sırasıyla şunlardır: Eski volume’ü instance’dan detach edin, yeni volume’ü attach edin, sudo mount /dev/nvme1n1 /var/lib/postgresql komutuyla mount edin ve servisinizi ayağa kaldırın. Tüm bu süreç, iyi bir altyapıda 10-15 dakikayı geçmez.

Maliyet Optimizasyonu: Snapshot’lar Cebinizi Yakmasın

Snapshot maliyetleri kontrol edilmezse ciddi fatura şoklarına yol açabilir. AWS’de EBS snapshot’ları GB başına aylık yaklaşık 0.05 USD’dir. 1 TB’lık bir disk için aylık 7 snapshot saklamanız, incremental yapı sayesinde çok daha az yer kaplamasına rağmen dikkatli olunması gerekir.

AWS’de eski ve kullanılmayan snapshot’ları temizleme:

#!/bin/bash
# cleanup-orphan-snapshots.sh
# Silinmiş volume'lere ait snapshot'ları bul ve raporla

echo "=== Orphan Snapshot Tarama Raporu ==="
echo "Tarih: $(date)"
echo ""

ORPHAN_COUNT=0
TOTAL_SIZE=0

aws ec2 describe-snapshots 
  --owner-ids self 
  --query 'Snapshots[*].{ID:SnapshotId,Volume:VolumeId,Size:VolumeSize,Desc:Description,Date:StartTime}' 
  --output json | jq -c '.[]' | while read SNAP; do
  
  SNAP_ID=$(echo $SNAP | jq -r '.ID')
  VOL_ID=$(echo $SNAP | jq -r '.Volume')
  SIZE=$(echo $SNAP | jq -r '.Size')
  DATE=$(echo $SNAP | jq -r '.Date')
  
  # Volume hala mevcut mu kontrol et
  VOL_EXISTS=$(aws ec2 describe-volumes 
    --volume-ids "$VOL_ID" 2>/dev/null 
    --query 'Volumes[0].VolumeId' 
    --output text 2>/dev/null)
  
  if [ -z "$VOL_EXISTS" ] || [ "$VOL_EXISTS" == "None" ]; then
    echo "ORPHAN: $SNAP_ID | Volume: $VOL_ID | Size: ${SIZE}GB | Date: $DATE"
    # Silmek için asagidaki satiri aktif edin:
    # aws ec2 delete-snapshot --snapshot-id "$SNAP_ID"
  fi
done

echo ""
echo "Tarama tamamlandi. Silmek icin scripti guncelleyin."

Azure’da maliyet optimizasyonu için öneriler:

  • Standard_LRS yerine Standard_ZRS kullanın (zone-redundant ama daha pahalı, buna göre değerlendirin)
  • Incremental snapshot’ları her zaman tercih edin
  • Eski snapshot’lar için lifecycle policy tanımlayın
  • Farklı ortamlar (dev, test, prod) için farklı retention süreleri belirleyin

Snapshot Doğrulama: Aldığınız Snapshot Gerçekten Çalışıyor mu?

En sık yapılan hatalardan biri snapshot almanın yeterli olduğunu düşünmektir. Oysa snapshot’ın geri yüklenebilir olduğunu da düzenli olarak test etmeniz gerekir. Şöyle bir doğrulama akışı öneririm:

  • Haftalık: Snapshot listesini gözden geçir, eksik olanları tespit et
  • Aylık: Rastgele bir snapshot’tan test volume oluştur ve veri bütünlüğünü kontrol et
  • Çeyreklik: Tam DR tatbikatı yap, gerçek bir geri yükleme senaryosunu simüle et

Snapshot doğrulamasını otomatize etmek için şu yaklaşımı kullanabilirsiniz:

#!/bin/bash
# verify-snapshot-integrity.sh
# Snapshot'tan volume oluştur, mount et, temel kontrolleri yap

SNAPSHOT_ID="${1:-snap-0abc123def456789}"
TEST_INSTANCE_ID="i-0testinstance123"
AZ="eu-west-1a"

echo "Snapshot dogrulama basliyor: $SNAPSHOT_ID"

# Test volume oluştur
TEST_VOL=$(aws ec2 create-volume 
  --snapshot-id "$SNAPSHOT_ID" 
  --availability-zone "$AZ" 
  --volume-type gp3 
  --tag-specifications "ResourceType=volume,Tags=[{Key=Purpose,Value=snapshot-verification},{Key=SnapshotId,Value=$SNAPSHOT_ID}]" 
  --query 'VolumeId' 
  --output text)

echo "Test volume olusturuldu: $TEST_VOL"
aws ec2 wait volume-available --volume-ids "$TEST_VOL"

# Test instance'a attach et
aws ec2 attach-volume 
  --volume-id "$TEST_VOL" 
  --instance-id "$TEST_INSTANCE_ID" 
  --device /dev/sdg

sleep 15

# Instance'da dogrulama komutları çalıştır (SSM aracılığıyla)
aws ssm send-command 
  --instance-ids "$TEST_INSTANCE_ID" 
  --document-name "AWS-RunShellScript" 
  --parameters 'commands=["sudo mount /dev/nvme2n1 /mnt/verify && ls -la /mnt/verify && df -h /mnt/verify && sudo umount /mnt/verify"]' 
  --query 'Command.CommandId' 
  --output text

echo "Dogrulama komutu gonderildi. Sonuclari SSM konsoledan kontrol edin."

# Temizlik (dogrulama sonrası)
# aws ec2 detach-volume --volume-id "$TEST_VOL"
# aws ec2 wait volume-available --volume-ids "$TEST_VOL"
# aws ec2 delete-volume --volume-id "$TEST_VOL"

Tagging Stratejisi: Kaosu Önlemenin Anahtarı

Yüzlerce snapshot biriktiğinde hangi snapshot’ın ne için alındığını bulmak gerçek bir kabus olabilir. Başından sağlam bir tagging stratejisi kurmak hayat kurtarır.

AWS için önerilen tag yapısı:

  • Name: Snapshot’ın okunabilir adı (örn: prod-db-daily-20241201)
  • Environment: production, staging, development
  • Application: hangi uygulamaya ait (postgres, webserver, etc.)
  • BackupType: daily, weekly, manual, pre-deployment
  • RetentionDate: snapshot’ın silinebileceği tarih
  • ManagedBy: dlm, automation, manual
  • CostCenter: hangi ekip veya proje

Azure için tag yapısı:

  • environment: production, staging, development
  • application: uygulama adı
  • backup-type: daily, weekly, pre-change
  • retention-days: kaç gün saklanacak
  • created-by: automation veya kişi adı
  • source-disk: kaynak disk adı

Güvenlik: Snapshot’larınız Şifreli mi?

Snapshot güvenliği çoğu zaman göz ardı edilen bir konudur. Özellikle hassas veri içeren disklerin snapshot’larının şifrelenmesi zorunludur.

AWS’de snapshot şifreleme:

  • EBS default encryption’ı account seviyesinde etkinleştirin: aws ec2 enable-ebs-encryption-by-default
  • KMS CMK kullanarak şifreleyin, AWS managed key yetmez
  • Cross-account paylaşımlarda KMS key politikalarına dikkat edin
  • Şifresiz volume’lerin snapshot’larını şifreli kopyaya dönüştürün

Azure’da snapshot şifreleme:

  • Platform-managed key varsayılan olarak aktiftir
  • Hassas veriler için customer-managed key (CMK) kullanın
  • Azure Key Vault entegrasyonunu mutlaka konfigüre edin
  • Disk Encryption Set oluşturarak snapshot’lara uygulayın

Sonuç

Snapshot yönetimi, “al ve unut” mantığıyla çalışmaz. AWS EBS ve Azure Disk anlık görüntüleri güçlü araçlardır ancak doğru yapılandırılmadığında sizi hem maddi hem de operasyonel açıdan zora sokabilir. Özetlemek gerekirse, otomasyon olmadan snapshot yönetimi yapılamaz. DLM veya Azure Automation kullanmadan manuel snapshot almak uzun vadede sürdürülebilir değildir. Retention politikanızı iyi kurun, gereksiz snapshot birikimine izin vermeyin. En önemlisi snapshot doğrulamasını ihmal etmeyin; almadığınız değil geri yükleyemediğiniz snapshot’ın hiçbir değeri yoktur. Cross-region replikasyonu DR stratejinizin temel parçası yapın ve her snapshot’ı düzgünce etiketleyin. Bunları hayata geçirdiğinizde, o “bir şeyleri batırıp geri dönememe” korkusu büyük ölçüde ortadan kalkar. Ve gece saatlerindeki o acil telefon aramaları da.

Bir yanıt yazın

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