GCP Compute Engine Snapshot Alma ve Geri Yükleme

Tarafındankomut
0 Comments

Veri kaybı her sistem yöneticisinin korkulu rüyasıdır. GCP Compute Engine üzerinde çalışan bir VM’in diskini yanlışlıkla silmek, bir uygulama güncellemesinin her şeyi patlatması ya da fidye yazılımı saldırısına maruz kalmak… Bunların hepsinin ortak çözümü düzenli ve güvenilir snapshot stratejisidir. Bu yazıda GCP snapshot mekanizmasını derinlemesine ele alacağız, hem manuel hem otomatik yöntemleri inceleyeceğiz, geri yükleme senaryolarını gerçek dünya örnekleriyle işleyeceğiz.

Snapshot Nedir ve GCP’de Nasıl Çalışır?

GCP’deki snapshot’lar, Persistent Disk’lerin belirli bir andaki görüntüsüdür. İlk snapshot tam bir kopyadır, sonraki snapshot’lar ise yalnızca değişen blokları içerir. Bu incremental yapı hem depolama maliyetini düşürür hem de snapshot alma süresini kısaltır.

Snapshot’lar bölgeden bağımsızdır. Yani us-central1-a zone’unda çalışan bir VM’in diskinden aldığınız snapshot’ı europe-west1-b‘de yeni bir disk oluşturmak için kullanabilirsiniz. Bu özellik, felaket kurtarma (disaster recovery) senaryolarında kritik önem taşır.

Snapshot’lar Google Cloud Storage altyapısında saklanır. Ancak standart GCS bucket’larında göremezsiniz, bunlar özel bir dahili lokasyonda tutulur. Snapshot’lar için ayrıca bölge (regional) ya da çok bölgeli (multi-regional) depolama seçeneği belirleyebilirsiniz.

Ön Hazırlık: Gerekli İzinler ve Araçlar

Snapshot işlemleri için gcloud CLI aracının kurulu ve yapılandırılmış olması gerekiyor. Bunun yanı sıra servis hesabınızın veya kullanıcınızın şu rollere sahip olması lazım:

  • compute.snapshots.create: Snapshot oluşturma
  • compute.snapshots.delete: Snapshot silme
  • compute.snapshots.list: Snapshot listeleme
  • compute.disks.createSnapshot: Diskten snapshot alma
  • compute.instances.stop: VM durdurma (opsiyonel, tutarlı snapshot için)

Compute Storage Admin rolü bu izinlerin hepsini kapsar. Üretim ortamında daha granüler izin yapısı kurmak daha doğrudur.

# gcloud kurulumu sonrası proje ayarı
gcloud config set project YOUR_PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

# Mevcut yapılandırmayı kontrol et
gcloud config list

# Servis hesabına Compute Storage Admin rolü ver
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID 
  --member="serviceAccount:backup-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" 
  --role="roles/compute.storageAdmin"

Manuel Snapshot Alma

gcloud CLI ile Snapshot Alma

En temel kullanım şekli gcloud compute disks snapshot komutudur. Çalışan bir VM’den snapshot alabilirsiniz, ancak özellikle veritabanı diskleri için VM’i durdurmak veya uygulamayı quiesce etmek daha sağlıklı sonuç verir.

# Tek bir diskten snapshot alma
gcloud compute disks snapshot my-production-disk 
  --snapshot-names=my-production-disk-snapshot-$(date +%Y%m%d-%H%M%S) 
  --zone=us-central1-a 
  --description="Uygulama güncellemesi öncesi alınan snapshot"

# Birden fazla diski aynı anda snapshot'lama
gcloud compute disks snapshot my-disk-1 my-disk-2 
  --snapshot-names=snap-disk1-$(date +%Y%m%d),snap-disk2-$(date +%Y%m%d) 
  --zone=us-central1-a

# Multi-regional snapshot (felaket kurtarma için önerilen)
gcloud compute disks snapshot my-production-disk 
  --snapshot-names=prod-disk-multiregional-$(date +%Y%m%d) 
  --zone=us-central1-a 
  --storage-location=us

VM’i Durdurup Tutarlı Snapshot Alma

Özellikle MySQL, PostgreSQL gibi veritabanı sunucularında çalışan diskler için snapshot alma öncesinde VM’i durdurmak en güvenli yoldur. Evet, downtime oluşur ama tutarsız bir snapshot’tan daha iyidir.

#!/bin/bash
# consistent-snapshot.sh
# Veritabanı VM'i için güvenli snapshot scripti

INSTANCE_NAME="db-production-01"
DISK_NAME="db-production-01"
ZONE="us-central1-a"
PROJECT="my-project-id"
SNAPSHOT_NAME="db-prod-$(date +%Y%m%d-%H%M%S)"

echo "[$(date)] VM durduruluyor: $INSTANCE_NAME"
gcloud compute instances stop $INSTANCE_NAME 
  --zone=$ZONE 
  --project=$PROJECT

# VM'in tamamen durmasını bekle
echo "[$(date)] VM durması bekleniyor..."
gcloud compute instances wait-until-status $INSTANCE_NAME 
  --status=TERMINATED 
  --zone=$ZONE

echo "[$(date)] Snapshot alınıyor: $SNAPSHOT_NAME"
gcloud compute disks snapshot $DISK_NAME 
  --snapshot-names=$SNAPSHOT_NAME 
  --zone=$ZONE 
  --project=$PROJECT 
  --description="Scheduled consistent snapshot - $(date)"

echo "[$(date)] VM yeniden başlatılıyor: $INSTANCE_NAME"
gcloud compute instances start $INSTANCE_NAME 
  --zone=$ZONE 
  --project=$PROJECT

echo "[$(date)] Snapshot tamamlandı: $SNAPSHOT_NAME"

Uygulama Tutarlı Snapshot (Application-Consistent)

Linux sistemlerde fsfreeze komutu ile dosya sistemini dondurarak tutarlı snapshot alabilirsiniz. Bu yöntem VM’i durdurmadan tutarlılık sağlar.

#!/bin/bash
# app-consistent-snapshot.sh
# fsfreeze kullanarak uygulama tutarlı snapshot

DISK_NAME="app-disk-01"
ZONE="us-central1-a"
MOUNT_POINT="/var/lib/mysql"
SNAPSHOT_NAME="app-consistent-$(date +%Y%m%d-%H%M%S)"

echo "MySQL servisini flush ediyoruz..."
mysql -u root -p'SIFRE' -e "FLUSH TABLES WITH READ LOCK; FLUSH LOGS;"

echo "Dosya sistemi donduruluyor..."
sudo fsfreeze -f $MOUNT_POINT

echo "Snapshot alınıyor..."
gcloud compute disks snapshot $DISK_NAME 
  --snapshot-names=$SNAPSHOT_NAME 
  --zone=$ZONE

echo "Dosya sistemi çözülüyor..."
sudo fsfreeze -u $MOUNT_POINT

echo "MySQL kilidi kaldırılıyor..."
mysql -u root -p'SIFRE' -e "UNLOCK TABLES;"

echo "Tamamlandı: $SNAPSHOT_NAME"

Otomatik Snapshot Politikaları

Snapshot Schedule Oluşturma

GCP, Snapshot Schedules özelliği ile otomatik snapshot alma imkanı sunar. Bu politikaları oluşturup disklere bağlayabilirsiniz.

# Günlük snapshot politikası oluştur
# Her gün 02:00 UTC'de snapshot al, 7 gün sakla
gcloud compute resource-policies create snapshot-schedule daily-backup-policy 
  --region=us-central1 
  --max-retention-days=7 
  --on-source-disk-delete=keep-auto-snapshots 
  --daily-schedule 
  --start-time=02:00 
  --description="Günlük otomatik backup politikası"

# Saatlik snapshot politikası (kritik sistemler için)
gcloud compute resource-policies create snapshot-schedule hourly-critical-policy 
  --region=us-central1 
  --max-retention-days=3 
  --on-source-disk-delete=keep-auto-snapshots 
  --hourly-schedule=4 
  --start-time=00:00 
  --description="4 saatte bir kritik sistem snapshot politikası"

# Politikayı bir diske bağla
gcloud compute disks add-resource-policies my-production-disk 
  --resource-policies=daily-backup-policy 
  --zone=us-central1-a

# Politikayı diskten çıkar
gcloud compute disks remove-resource-policies my-production-disk 
  --resource-policies=daily-backup-policy 
  --zone=us-central1-a

Snapshot’ları Listeleme ve Yönetme

# Tüm snapshot'ları listele
gcloud compute snapshots list

# Belirli bir filtreyle listele (son 7 günün snapshot'ları)
gcloud compute snapshots list 
  --filter="creationTimestamp > $(date -d '7 days ago' +%Y-%m-%dT%H:%M:%S)" 
  --format="table(name, sourceDisk, diskSizeGb, creationTimestamp, status)"

# Belirli bir diske ait snapshot'ları bul
gcloud compute snapshots list 
  --filter="sourceDisk:my-production-disk" 
  --sort-by=~creationTimestamp

# Snapshot detaylarını görüntüle
gcloud compute snapshots describe my-snapshot-20240115

# Eski snapshot'ları temizleme scripti
# 30 günden eski snapshot'ları sil
gcloud compute snapshots list 
  --filter="creationTimestamp < $(date -d '30 days ago' +%Y-%m-%dT%H:%M:%S) AND name:manual-" 
  --format="value(name)" | 
  xargs -I {} gcloud compute snapshots delete {} --quiet

Snapshot’tan Disk ve VM Geri Yükleme

Snapshot’tan Yeni Disk Oluşturma

# Snapshot'tan yeni disk oluştur
gcloud compute disks create restored-disk-01 
  --source-snapshot=my-production-disk-snapshot-20240115 
  --zone=us-central1-a 
  --type=pd-ssd 
  --size=100GB

# Farklı bölgede disk oluştur (felaket kurtarma senaryosu)
gcloud compute disks create dr-restored-disk-01 
  --source-snapshot=my-production-disk-snapshot-20240115 
  --zone=europe-west1-b 
  --type=pd-balanced

# Oluşturulan diski mevcut bir VM'e bağla
gcloud compute instances attach-disk my-vm-instance 
  --disk=restored-disk-01 
  --zone=us-central1-a 
  --mode=rw

Tam VM Geri Yükleme Senaryosu

Gerçek hayatta en çok karşılaştığımız senaryo: Bir uygulama güncellemesi her şeyi patlattı, önceki kararlı versiyona dönmemiz lazım.

#!/bin/bash
# full-vm-restore.sh
# Snapshot'tan tam VM geri yükleme

PROJECT="my-project-id"
ZONE="us-central1-a"
REGION="us-central1"
SNAPSHOT_NAME="prod-vm-snapshot-20240115-020000"
NEW_DISK_NAME="restored-prod-disk-$(date +%Y%m%d)"
NEW_VM_NAME="restored-prod-vm-$(date +%Y%m%d)"
MACHINE_TYPE="n2-standard-4"
NETWORK="default"
SUBNET="default"

echo "=== GCP VM Geri Yükleme Başlıyor ==="
echo "Snapshot: $SNAPSHOT_NAME"
echo "Hedef VM: $NEW_VM_NAME"

# 1. Adım: Snapshot'tan yeni boot disk oluştur
echo "[1/4] Boot disk oluşturuluyor..."
gcloud compute disks create $NEW_DISK_NAME 
  --source-snapshot=$SNAPSHOT_NAME 
  --zone=$ZONE 
  --type=pd-ssd 
  --project=$PROJECT

if [ $? -ne 0 ]; then
  echo "HATA: Disk oluşturulamadı!"
  exit 1
fi

# 2. Adım: Yeni VM oluştur ve disk'i boot disk olarak bağla
echo "[2/4] Yeni VM oluşturuluyor..."
gcloud compute instances create $NEW_VM_NAME 
  --zone=$ZONE 
  --machine-type=$MACHINE_TYPE 
  --disk=name=$NEW_DISK_NAME,boot=yes,auto-delete=yes 
  --network=$NETWORK 
  --subnet=$SUBNET 
  --no-address 
  --project=$PROJECT 
  --tags=http-server,https-server

if [ $? -ne 0 ]; then
  echo "HATA: VM oluşturulamadı!"
  exit 1
fi

# 3. Adım: VM'in başlamasını bekle
echo "[3/4] VM başlaması bekleniyor..."
sleep 30

# VM durumunu kontrol et
VM_STATUS=$(gcloud compute instances describe $NEW_VM_NAME 
  --zone=$ZONE 
  --format="value(status)")

echo "VM Durumu: $VM_STATUS"

# 4. Adım: Özet bilgi
echo "[4/4] Geri yükleme tamamlandı!"
echo "Yeni VM: $NEW_VM_NAME"
echo "Zone: $ZONE"
gcloud compute instances describe $NEW_VM_NAME 
  --zone=$ZONE 
  --format="table(name, status, machineType, networkInterfaces[0].networkIP)"

Mevcut VM’in Boot Diskini Snapshot’tan Değiştirme

Bu senaryo biraz daha karmaşık ama sık karşılaşılan bir durum: Çalışan VM’in bozulan boot diskini snapshot’tan geri yüklemek istiyorsunuz, aynı IP ve konfigürasyonu koruyarak.

#!/bin/bash
# replace-boot-disk.sh
# Mevcut VM'in boot diskini snapshot'tan değiştir

INSTANCE_NAME="production-web-01"
ZONE="us-central1-a"
SNAPSHOT_NAME="prod-web-snapshot-20240115"
OLD_DISK_NAME=$(gcloud compute instances describe $INSTANCE_NAME 
  --zone=$ZONE 
  --format="value(disks[0].source)" | awk -F'/' '{print $NF}')

NEW_DISK_NAME="${INSTANCE_NAME}-restored-$(date +%Y%m%d)"

echo "Mevcut boot disk: $OLD_DISK_NAME"
echo "Yeni disk adı: $NEW_DISK_NAME"

# VM'i durdur
echo "VM durduruluyor..."
gcloud compute instances stop $INSTANCE_NAME --zone=$ZONE

# Boot diski detach et
echo "Boot disk ayırılıyor..."
gcloud compute instances detach-disk $INSTANCE_NAME 
  --disk=$OLD_DISK_NAME 
  --zone=$ZONE

# Snapshot'tan yeni disk oluştur
echo "Snapshot'tan yeni disk oluşturuluyor..."
gcloud compute disks create $NEW_DISK_NAME 
  --source-snapshot=$SNAPSHOT_NAME 
  --zone=$ZONE 
  --type=pd-ssd

# Yeni diski boot disk olarak bağla
echo "Yeni disk boot disk olarak bağlanıyor..."
gcloud compute instances attach-disk $INSTANCE_NAME 
  --disk=$NEW_DISK_NAME 
  --zone=$ZONE 
  --boot

# VM'i başlat
echo "VM yeniden başlatılıyor..."
gcloud compute instances start $INSTANCE_NAME --zone=$ZONE

echo "İşlem tamamlandı. Eski disk ($OLD_DISK_NAME) silinmedi, elle kontrol edin."

Cloud Functions ile Otomatik Snapshot Yönetimi

Snapshot politikaları çoğu durumda yeterli olsa da, daha özelleştirilmiş senaryolar için Cloud Functions kullanabilirsiniz. Örneğin yalnızca belirli etiketlere sahip VM’lerin disklerini yedeklemek:

# main.py - Cloud Function: Tagged VM'leri otomatik snapshot'la
import googleapiclient.discovery
from datetime import datetime
import os

def snapshot_tagged_vms(event, context):
    """Belirli etiketlere sahip VM disklerini snapshot'lar"""
    
    compute = googleapiclient.discovery.build('compute', 'v1')
    project = os.environ.get('PROJECT_ID')
    backup_tag = os.environ.get('BACKUP_TAG', 'auto-snapshot')
    
    # Tüm zone'lardaki instance'ları listele
    zones_result = compute.zones().list(project=project).execute()
    
    for zone in zones_result.get('items', []):
        zone_name = zone['name']
        
        # Zone'daki instance'ları al
        instances = compute.instances().list(
            project=project,
            zone=zone_name,
            filter=f'labels.backup={backup_tag}'
        ).execute()
        
        for instance in instances.get('items', []):
            instance_name = instance['name']
            
            # Her diske snapshot al
            for disk_info in instance.get('disks', []):
                disk_name = disk_info['source'].split('/')[-1]
                timestamp = datetime.now().strftime('%Y%m%d-%H%M%S')
                snapshot_name = f"auto-{disk_name}-{timestamp}"
                
                # 63 karakter sınırını aşma
                snapshot_name = snapshot_name[:63]
                
                snapshot_body = {
                    'name': snapshot_name,
                    'description': f'Auto snapshot from {instance_name} - {disk_name}',
                    'labels': {
                        'instance': instance_name,
                        'automated': 'true',
                        'source-disk': disk_name
                    }
                }
                
                compute.disks().createSnapshot(
                    project=project,
                    zone=zone_name,
                    disk=disk_name,
                    body=snapshot_body
                ).execute()
                
                print(f"Snapshot alındı: {snapshot_name} ({instance_name}/{disk_name})")

Maliyet Optimizasyonu ve En İyi Pratikler

Snapshot maliyetleri özellikle büyük ve sık değişen disklerde ciddi boyutlara ulaşabilir. Bazı önemli noktalara dikkat etmek gerekiyor:

  • Retention politikası belirleyin: Sonsuz saklama hem maliyetli hem de gereksizdir. Çoğu senaryo için 30 günlük retention yeterlidir.
  • Multi-regional dikkatli kullanın: Multi-regional snapshot’lar regional snapshot’lara göre çok daha pahalıdır. Yalnızca kritik sistemler için tercih edin.
  • Snapshot label’ları kullanın: Snapshot’larınıza anlamlı etiketler ekleyin. Maliyet takibi ve eski snapshot’ları temizleme işlemi çok kolaylaşır.
  • Incremental yapıyı anlayın: İlk snapshot büyük olur, sonrakiler küçük. Çok sık snapshot almak her zaman büyük maliyet demek değildir.
  • Snapshot zincirini bozmayın: Bir snapshot’ı silerken GCP otomatik olarak referans bütünlüğünü yönetir ama yine de en eski snapshot’tan başlayarak silmek daha sağlıklıdır.
  • Storage location seçin: Varsayılan depolama konumu bazen beklenmedik maliyetler çıkarabilir. Hangi region’da saklandığını kontrol edin.

Snapshot maliyetini takip etmek için:

# Snapshot boyutlarını listele
gcloud compute snapshots list 
  --format="table(name, storageBytes, creationTimestamp)" 
  --sort-by=~storageBytes

# Toplam snapshot storage kullanımı (GB cinsinden)
gcloud compute snapshots list 
  --format="value(storageBytes)" | 
  awk '{sum += $1} END {printf "Toplam: %.2f GBn", sum/1073741824}'

# Label'a göre maliyet analizi için snapshot'ları etiketle
gcloud compute snapshots add-labels my-snapshot-20240115 
  --labels=env=production,team=backend,retention=30days

Gerçek Dünya Senaryosu: E-ticaret Sitesi Geri Yükleme

Diyelim ki Cuma gecesi saat 23:00’de uyarı aldınız: Yazılım ekibi yanlış bir migration çalıştırmış, veritabanı tutarsız durumda, site cevap vermiyor. Sabah 08:00’de iş günü başlayacak.

İşte bu durumda yapmanız gerekenler:

  1. Paniği bırakın, son kararlı snapshot’u bulun.
  2. Etkilenen VM’i hemen durdurun, daha fazla hasar görmesin.
  3. Snapshot’tan yeni bir disk oluşturun (eski diski saklamanız gerekiyor, sorun tespiti için).
  4. Yeni VM başlatıp test edin, doğrulayın.
  5. Siteyi yeni VM’e yönlendirin.
# Acil durum geri yükleme - hızlı kontrol listesi

# Son 3 snapshot'u listele
gcloud compute snapshots list 
  --filter="sourceDisk:db-production AND status=READY" 
  --sort-by=~creationTimestamp 
  --limit=3 
  --format="table(name, creationTimestamp, diskSizeGb, status)"

# Seçilen snapshot bilgilerini doğrula
gcloud compute snapshots describe db-production-20240119-020000

# Felaket kurtarma diski oluştur
gcloud compute disks create emergency-restore-db 
  --source-snapshot=db-production-20240119-020000 
  --zone=us-central1-a 
  --type=pd-ssd

# Acil VM başlat
gcloud compute instances create emergency-db-vm 
  --zone=us-central1-a 
  --machine-type=n2-highmem-8 
  --disk=name=emergency-restore-db,boot=yes 
  --no-address 
  --tags=db-server

Bu senaryoda önceden hazırlanmış bir runbook’unuzun olması hayat kurtarır. Snapshot var ama nerede olduğunu bilmiyorsanız veya geri yükleme adımlarını canlı ortamda ilk kez deniyorsanız, gece yarısı çok daha uzun sürer.

Sonuç

GCP Compute Engine snapshot mekanizması doğru yapılandırıldığında son derece güvenilir bir yedekleme katmanı sunar. Önemli olan sadece snapshot almak değil, bu snapshot’ları düzenli olarak test etmek ve geri yükleme sürecini pratikte denemektir.

Asgari önerilen strateji şudur: Her gün otomatik snapshot al, 7 gün sakla. Kritik sistemler için haftanın her günü çekilmiş bir snapshot’ı en az 30 gün saklayın. Ayda bir geri yükleme tatbikatı yapın, bir test ortamında gerçekten restore edin ve uygulamanızın çalıştığını doğrulayın.

Snapshot politikalarını diskler oluşturulduğunda hemen bağlamak, Terraform veya Deployment Manager ile altyapı tanımlarınıza eklemek en doğru yaklaşımdır. “Sonra eklerim” dediğiniz şey genellikle hiç eklenmiyor ve o gece yanında olmak istemeyeceğiniz durumlarla karşılaşıyorsunuz.

Yedek almak bir sigortadır; primsiz sigorta olmaz. Snapshot maliyetinden kaçınmak için yedek almamak, yangın riskinden kaçınmak için sigorta yaptırmamak gibidir.

Bir yanıt yazın

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