Kritik bir kalp ameliyatına giren bir cerrahın masadaki hastanın EKG monitörünün, tansiyon eğrisinin ve açık göğüs kafesinin cep telefonuyla yüksek çözünürlüklü bir fotoğrafını (Snapshot) çektiğini düşünün. Cerrah arkasına yaslanır ve asistanına gururla şunu söyler: "Hastanın tam bir anlık kopyasını (snapshot) aldım. Artık hiçbir şeyden korkmamıza gerek yok; hasta masada ölse bile bu fotoğraf elimizde olduğu sürece her şey güvendedir!" Bir saat sonra hastanın ana damarı patlayıp hasta masada kardiyak arrest geçirdiğinde cerrah cep telefonunu çıkarır, fotoğrafı ölmekte olan hastanın yüzüne tutar ve hastanın ayağa kalkmasını bekler! Elbette hasta canlanmaz ve ölür; çünkü bir anlık fotoğraf, yaşayan bir organın yedeği değildir. Fotoğraf sadece o milisaniyedeki durumun statik bir gölgesidir; ana beden öldüğünde o gölgenin tek başına hiçbir hükmü kalmaz.
Sistem mühendisliğinde ve bulut altyapılarında her genç geliştiricinin kariyerinde en az bir kez düştüğü o ölümcül yanılgı tam olarak budur:
"Snapshot (Anlık Görüntü) almak bir YEDEKLEME değildir!"
Bulut yönetim panelinde (Proxmox, VMware vCenter, OpenStack) tek bir tıkla "Take Snapshot" butonuna basan ve "Artık yedeğim var, veritabanım güvende" diyerek mışıl mışıl uyuyan mühendislerin, ana depolama havuzu (SAN / Ceph / ZFS) çöktüğü sabah yaşadıkları uyanış, bilişim dünyasının en acı tecrübelerinden biridir.
Snapshot Nedir ve Dosya Sisteminde Nasıl Çalışır?
Birçok acemi yönetici "Snapshot" aldığında, hipervizörün o 100 GB'lık diskin tam bir fiziksel kopyasını alıp başka bir kasaya kaldırdığını zanneder. Oysa gerçekte olan şey sadece bir İşaretçi (Pointer) Hilesidir.
KVM (QCOW2), VMware (VMDK) veya Ceph RBD üzerinde bir Snapshot aldığınızda işletim sistemi şunları yapar:
- O ana kadar yazılmış olan ana disk imajını salt-okunur (Read-Only) olarak dondurur.
- Sisteme Copy-on-Write (CoW) veya Redirect-on-Write mekanizmasıyla çalışan minik bir delta (fark) dosyası ekler.
- O andan itibaren sanal makinenin yaptığı tüm yeni yazma işlemleri bu delta dosyasına yazılır.
+------------------------------------------------------------------------+
| SNAPSHOT MİMARİSİ |
| |
| [Ana Disk İmajı: base.qcow2 (100 GB)] <─── DONDURULDU (Read-Only) |
| │ |
| ▼ Bağımlılık Zinciri ⛓️ |
| [Delta Dosyası: snap1.delta (2 GB)] <─── YALNIZCA DEĞİŞEN BLOKLAR! |
| |
| AYNI FİZİKSEL DEPOLAMA HAVUZUNDA (Ceph Pool / SAN LUN) YAŞARLAR! |
+------------------------------------------------------------------------+
Snapshot bağımsız bir varlık değildir! Snapshot, altındaki ana disk bloğuna göbekten bağımlı kırılgan bir uzantıdır.
Eğer ana disk bloğu bozulursa, Snapshot anlamsız bir çöp yığınına dönüşür.
Patolojinin Gelişimi: Ana Depolama Havuzu Çöktüğünde Ne Olur?
Bir Cuma gecesi yerli bulut sağlayıcısının veya kendi şirketinizin ana depolama havuzunda (SAN Storage / Ceph Kümesi) donanımsal bir felaket yaşanır:
- 3 adet kontrolcü diski aynı anda ölür.
- Ceph OSD düğümleri senkronizasyonunu kaybedip döngüsel kilitlenmeye (split-brain) girer.
- Sanal makinelerin barındığı
/dev/mapper/storage-pooltamamen silinir veya dosya sistemi geri dönülemez şekilde bozulur (Metadata corruption).
Mühendis panikle sağlayıcıya yazar:
"Ana diskler bozulmuş olabilir ama benim panelde dün akşam aldığım 3 adet Snapshot'ım vardı! Lütfen Snapshot'ımdan sunucumu geri dönün (Revert to Snapshot)!"
Sağlayıcının sistem mimarı acı gerçeği açıklar:
"Ahmet Bey, Snapshot'larınız başka bir fiziksel sunucuda veya harici bir kasada saklanmıyordu. Snapshot'larınız da o çöken ana depolama havuzunun içindeki delta bloklarıydı. Ana havuz öldüğü için ana disklerinizle birlikte tüm snapshot'larınız da kalıcı olarak silindi ve yok oldu."
Mühendisin dünyası başına yıkılır: "Yedek aldım" zannettiği şey, sadece batmakta olan geminin güvertesine çizilmiş tebeşir resmidir; gemi battığında tebeşir de suyun dibine gömülmüştür.
Snapshot'ın İkinci Tehlikesi: Sunucuyu Yavaşlatan Canavar
Snapshot'ı yedek zanneden kullanıcıların yaptığı ikinci vahim hata, aldıkları Snapshot'ı aylarca silmeden sunucuda unutmaktır:
- Geliştirici 6 ay önce "Sistem güncellemesi öncesi" bir snapshot almıştır.
- Aradan 6 ay geçmiştir; o snapshot hala oradadır.
Peki arka planda ne olmuştur?
- Delta dosyası 6 ay içinde 80 Gigabayta ulaşmıştır!
- Sanal makine diskten bir veri okumak istediğinde, hipervizör önce delta dosyasına bakar, bulamazsa ana dosyaya bakar, oradan oraya zıplar (Chain Traversal).
- Disk gecikmesi (I/O Latency) 2 milisaniyeden 85 milisaniyeye fırlar!
- Sunucu donmaya başlar; geliştirici ise "Bu sunucu neden yavaşladı" diye ağlar.
En sonunda snapshot'ı silmek (Consolidate / Merge) istediğinizde, hipervizör 80 GB'lık delta dosyasını ana diske yazmak için diski saatlerce %100 yük altına sokar ve canlı e-ticaret sitenizi saatlerce kilitler!
Gerçek Yedekleme Nedir? (3-2-1 Kuralının Tavizsiz Disiplini)
Sistem mühendisliğinde bir verinin "yedeklenmiş" sayılabilmesi için 3-2-1 Yedekleme Kuralına uyması şarttır:
[3-2-1 YEDEKLEME KANUNU]
3: Verinin en az 3 KOPYASI olmalıdır (1 Canlı + 2 Yedek).
2: Bu kopyalar en az 2 FARKLI MEDYA türünde saklanmalıdır (SSD + Nesne Depolama / Teyp).
1: Kopyalardan EN AZ 1 TANESİ FARKLI BİR COĞRAFİ KONUMDA (Off-site) olmalıdır!
Eğer aldığınız kopya:
- Aynı sunucunun içindeyse,
- Aynı veri merkezinin aynı depolama havuzundaysa,
- Ana sunucu kapandığında tek başına bağımsız olarak ayağa kaldırılamıyorsa;
O BİR YEDEK DEĞİLDİR. O sadece geçici bir geri dönüş noktasıdır (Restore Point).
Snapshot Ne Zaman Kullanılır? (Doğru Cerrahi Reçete)
Peki Snapshot tamamen gereksiz bir teknoloji midir? Kesinlikle hayır. Snapshot harika bir kısa vadeli güvenlik kemeridir:
- Kullanım Amacı: Canlı sistemde riskli bir işlem yapacaksınızdır (Örn: Ubuntu 22.04 -> 24.04 OS yükseltmesi veya büyük bir veritabanı migration'ı).
- Adım 1: Snapshot alırsınız.
- Adım 2: Güncellemeyi yaparsınız.
- Adım 3 (Test): Sistem çalıştıysa, SNAPSHOT'I HEMEN O AN SİLERSİNİZ (Merge)!
- Adım 3 (Hata): Sistem çöktüyse, 10 saniyede
Revertedip eski haline dönersiniz. - Kural: Bir Snapshot'ın ömrü en fazla 24 saat olmalıdır! 24 saatten uzun yaşayan her snapshot, sisteme saplanmış bir hançerdir.
Gerçek ve Bağımsız Yedekleme Nasıl Yapılır?
# Snapshot'a güvenmeyin! Veritabanını bağımsız bir arşive dökün:
mysqldump -u root -p --single-transaction --quick db_adi | gzip > /tmp/db_$(date +%F).sql.gz
# Bu dosyayı FARKLI BİR VERİ MERKEZİNDEKİ S3/MinIO havuzuna fırlatın:
aws --endpoint-url https://izmir-storage.yerlibulut.com s3 cp /tmp/db_*.sql.gz s3://bagimsiz-yedek/Bu dosya artık ana sunucudan, ana depolama havuzundan ve o veri merkezinden tamamen bağımsızdır. Veri merkezi yansa bile veriniz İzmir'deki başka bir depolama ünitesinde güvendedir.
Sonuç
Monitörün fotoğrafını çekip hastayı kurtardığını sanan cerrah cinayet işlemiştir; Snapshot alıp tüm şirketin yedeğini aldığını sanan sistem mühendisi de şirketin geleceğini ateşe atmıştır.
Snapshot bir ameliyat sırasında elinizin altında tuttuğunuz geçici bir hemostatik pens gibidir; işiniz bittiğinde pensi gevşetip yarayı kapatmak zorundasınız. Kalıcı şifa pens takmakta değil, organı tedavi edip güvenli bir odaya taşımaktadır. Altyapınızı snapshot yanılgısına kurban etmeyin; gerçek yedeklerinizi bağımsız havuzlara, farklı coğrafyalara taşıyın ve kriz anında masada sadece küllerle baş başa kalmayın.