VDS’de Snapshot, İmaj ve Yedek Arasındaki Fark

VDS snapshot, sunucunuzun diskinin belirli bir andaki durumunun kopyasıdır; yedek ise o verinin sunucudan tamamen dışarı çıkarılmış hâli. Aradaki fark teknik bir ayrıntı gibi görünür ama sunucu kaybedildiğinde tüm sonucu belirler: snapshot, koruduğu sunucuyla aynı altyapının üzerinde durur. Altyapı giderse snapshot da gider. İşte bu yüzden snapshot bir geri alma aracıdır, felaket kurtarma çözümü değil.

Bu sayfada üç kavramı — snapshot, imaj ve yedek — yan yana koyup hangisinin neyi çözdüğünü netleştiriyoruz. Ardından snapshot’ın gerçekten işe yaradığı anlar, geri dönüş süresi ile veri kaybı penceresi hesabı, veritabanı açıkken alınan snapshot’ın neden riskli olduğu ve 3-2-1 kuralında snapshot’ın tam olarak nereye oturduğu var. Sunucunuz yeni teslim edildiyse önce ilk ayarlar kontrol listesini bitirmeniz mantıklı olur.

Snapshot Nedir, Nasıl Çalışır?#

Snapshot, sanallaştırma katmanının diski belirli bir anda “dondurup” o andan sonraki yazmaları ayrı tutmasıdır. Sistem çalışmaya devam eder; yeni yazılan bloklar başka bir yere gider, eski bloklar snapshot için korunur. Bu yüzden alınması saniyeler sürer — koca diski kopyalamaz, sadece bir çizgi çeker.

Sonuç şudur: geri döndüğünüzde sunucu, snapshot alındığı andaki hâline döner. Kurulum yaptıysanız kurulum yok olur, dosya sildiyseniz dosya geri gelir, yapılandırmayı bozduysanız düzelir. Tek düğme, tek adım.

Bu mekanizmanın önemli bir yan etkisi var. Snapshot durduğu sürece depolama katmanı iki sürümü birden takip eder ve yazma yoğun sistemlerde performansa yük biner. Ayrıca snapshot ne kadar uzun durursa değişen blok miktarı büyür, dolayısıyla kapladığı alan da büyür. Kısacası snapshot geçici bir araçtır; kalıcı bir depo değil.

# Sunucunun mevcut disk durumunu snapshot öncesi kaydedin
df -hT
lsblk -f
uname -r
dpkg -l | wc -l          # kurulu paket sayısı
systemctl list-units --type=service --state=running | head -20

# Değişikliği sonradan karşılaştırabilmek için not düşün
date +"%F %T" | sudo tee /root/snapshot-oncesi.txt
df -h | sudo tee -a /root/snapshot-oncesi.txt

Sağlayıcı paneli üzerinden alınan snapshot’lar hipervizör seviyesinde çalışır; sunucunun içine hiçbir şey kurmanız gerekmez. Sunucu içinde LVM kullanıyorsanız işletim sistemi seviyesinde de snapshot alabilirsiniz, ama bu ayrı bir konudur ve panel snapshot’ının yerine geçmez.

Snapshot, İmaj ve Yedek Arasındaki Fark#

Üç kavram sürekli birbirine karışıyor. Aslında farkları tek cümleyle özetlenebilir: snapshot geri döner, imaj çoğaltır, yedek kurtarır.

İmaj kısmını biraz açalım, çünkü en az bilinen kavram o. Diyelim ki Ubuntu 24.04 üzerine Nginx, PHP-FPM, güvenlik duvarı kuralları ve izleme aracınızı kurdunuz. Bu sistemden bir imaj çıkarırsanız, sonraki her yeni sunucuyu sıfırdan kurmak yerine o imajdan başlatabilirsiniz. Kurulum adımlarını tekrar tekrar yapmazsınız. Ama imaj felaket anında sizi kurtarmaz: içinde müşteri verisi, veritabanı içeriği ya da son yüklenen dosyalar yoktur. Web sunucusu kurulumunu bir kez yapıp imaj almak, aynı yığını tekrar kuracaklar için ciddi zaman kazandırır.

Snapshot neden yedeğin yerine geçmez?#

Bu bölümü atlamayın, çünkü sayfanın asıl mesajı burada. Snapshot’ın koruma alanı, sunucunun kendi içindeki hatalarla sınırlıdır:

• Korur: yanlış komut, bozulan güncelleme, kırılan yapılandırma, başarısız sürüm yükseltmesi, silinen dosya (disk bütün olarak dönerse).
• Korumaz: depolama altyapısındaki ciddi arıza, sunucunun silinmesi, hesabın kapanması, sağlayıcı tarafındaki bölgesel kesinti, fidye yazılımının erişebildiği her şey.

Fark, kopyanın nerede durduğuyla ilgilidir. Yedeğin tanımı gereği verinin, onu üreten sistemden bağımsız bir yerde bulunması gerekir. Snapshot bu şartı sağlamaz; sunucuyla aynı kaderi paylaşır. Aynı mantık RAID için de geçerli: RAID disk arızasına karşı süreklilik sağlar, yanlışlıkla silinen dosyayı geri getirmez. Konunun ayrıntısı RAID seviyeleri sayfasında.

Bir kopya, kopyaladığı şeyle aynı yerde duruyorsa yedek değildir.

Pratikte doğru kurgu şu: snapshot’ı riskli işlemler için hızlı geri alma düğmesi olarak kullanın, yedeği ise her gün otomatik çalışan ve çıktısını sunucu dışına taşıyan bir süreç olarak kurun. İkisi farklı sorunları çözer ve birlikte kullanıldığında maliyeti de makul kalır.

Ne Zaman Snapshot Alınır?#

Snapshot’ın değeri zamanlamasında. Doğru anda alınmış tek bir snapshot, saatlerce süren bir kurtarma çalışmasını beş dakikaya indirir. Şu durumlarda snapshot almadan işleme başlamayın:

1. İşletim sistemi güncellemesi ve çekirdek yükseltmesi öncesi#

   apt full-upgrade çoğu zaman sorunsuz geçer. Çoğu zaman. Yeni çekirdeğin açılmadığı ya da bir sürücünün kırıldığı durumlarda snapshot, sizi kurtarma konsoluyla uğraşmaktan kurtarır.

2. Uygulama sürüm yükseltmesi öncesi#

   PHP 8.2’den 8.3’e, MySQL’den MariaDB’ye, panel sürümü değişimi... Bu işlemler veritabanı şemasını değiştirir ve geri alınmaları elle neredeyse imkânsızdır. Oyun sunucusu tarafında aynı mantık için sürüm yükseltme rehberine bakın.

3. Panel, kontrol paneli veya büyük bir yazılım yığını kurarken#

   cPanel, Plesk ya da Pterodactyl gibi kurulumlar sistemin her yerine dokunur; “kaldırma” betikleri geride izler bırakır. Kurulum yarıda bozulursa temiz duruma dönmenin en hızlı yolu snapshot’tır.

4. Güvenlik duvarı ve SSH yapılandırmasını değiştirirken#

   Kendinizi sunucudan kilitlemenin en klasik yolu budur. Kurallar için güvenlik duvarı yapılandırması sayfasına bakın; ama önce snapshot alın.

5. Kaynak yükseltmesi ve sunucu taşıma öncesi#

   RAM, CPU veya disk büyütmesi genellikle sorunsuzdur, yine de dosya sistemi genişletme adımı risk taşır. Ne zaman yükseltmeniz gerektiğini kaynak yükseltme rehberi anlatıyor.

6. Ne yaptığınızdan tam emin olmadığınız her seferde#

   İnternetten bulduğunuz bir betiği çalıştırmadan önce, bir dizini toplu silmeden önce, izinleri özyinelemeli değiştirmeden önce. Bu madde diğerlerinin hepsinden daha çok işe yarar.

Geri Dönüş Süresi ve Veri Kaybı Penceresi#

Yedekleme konuşmalarında iki soru vardır ve ikisi de sayıyla cevaplanır. Birincisi: sistem ne kadar sürede geri gelir? İkincisi: geri geldiğinde ne kadarlık veri kaybolmuş olur? Snapshot birinci soruda çok iyi, ikincisinde kötüdür.

Şöyle düşünün: sabah 09.00’da snapshot aldınız, gün boyu sipariş geldi, akşam 21.00’de bir sorun yüzünden snapshot’a döndünüz. Sunucu beş dakikada ayağa kalkar. On iki saatlik sipariş kaydı ise gitmiştir. Bu yüzden snapshot’a dönmek, saatler önce alınmış bir snapshot söz konusu olduğunda hiç de masum bir işlem değildir.

Uygulama Tutarlılığı: Veritabanı Açıkken Snapshot Almak#

Snapshot diskin ham hâlini kopyalar. Ama çalışan bir veritabanının verisinin bir kısmı o anda bellektedir ve henüz diske yazılmamıştır. Snapshot bu belleği görmez.

Sonuç: geri yüklediğinizde veritabanı, elektriği aniden kesilmiş bir sunucu gibi açılır. Buna “çökme tutarlı” (crash consistent) durum denir. InnoDB gibi günlük tabanlı motorlar çoğu zaman kendi kendini toparlar, ama “çoğu zaman” bir garanti değildir; özellikle MyISAM tabloları, dosya bazlı sayaçlar ve arama indeksleri bu senaryodan hasarlı çıkabilir.

Doğru yaklaşım üç seçenekten biridir. En basitinden en ideale:

# SEÇENEK 1 — En güvenli: servisi durdurup snapshot al
sudo systemctl stop nginx php8.3-fpm
sudo systemctl stop mariadb
sync            # bellekteki yazmaları diske indir
# ... panelden snapshot al ...
sudo systemctl start mariadb nginx php8.3-fpm

# SEÇENEK 2 — Kesinti istemiyorsanız: tutarlı döküm + snapshot
sudo mysqldump --single-transaction --quick --routines \
  --all-databases > /root/db-$(date +%F-%H%M).sql
sync
# ... panelden snapshot al ...

# SEÇENEK 3 — Dosya sistemini kısa süre dondur (deneyimli kullanıcı)
sudo fsfreeze --freeze /var
# ... snapshot al ...
sudo fsfreeze --unfreeze /var

--single-transaction parametresi InnoDB tablolarını kilitlemeden tutarlı bir kesit almanızı sağlar; sitedeki trafik devam eder. Uygulamanız MyISAM kullanıyorsa bu parametre yetmez, tabloları kilitlemeniz gerekir. Veritabanı bağlantısı ve yapılandırma tarafında ayrıntı isterseniz MySQL ve MariaDB tarafında motor tipini önceden bilmek işinizi kolaylaştırır.

Kaç Snapshot Tutmalı ve Saklama Maliyeti#

Snapshot bedava değildir çünkü gerçek disk alanı işgal eder. İlk snapshot kabaca kullanılan disk kadar yer kaplar; sonrakiler yalnızca değişen blokları tuttuğu için daha ucuzdur. Ama burada sinsi bir durum var: snapshot ne kadar uzun durursa, üzerine biriken değişen blok miktarı o kadar büyür. Bir ay duran snapshot, alındığı gün kapladığı alanın kat kat üstüne çıkabilir.

Pratik kural: aynı anda iki snapshot yeter. Biri az önce yaptığınız riskli işlemden hemen önce alınan, diğeri bilinen son sağlam durum. Üçüncüsü genellikle “silmeyi unuttuğum” snapshot’tır ve faturayı büyütmekten başka iş görmez.

# Diskin ne kadarı gerçekten dolu? Snapshot maliyetini bu belirler
df -h /
du -h --max-depth=1 / 2>/dev/null | sort -hr | head -8

# Snapshot almadan önce çöpü temizleyin — hem küçük hem ucuz olur
sudo apt clean
sudo journalctl --vacuum-time=7d
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo rm -rf /tmp/*
df -h /

Snapshot almadan önce beş dakikalık bir temizlik, hem alma süresini hem saklama maliyetini düşürür. Disk sürekli dolu kalıyorsa sorun snapshot değildir; kalıcı çözüm temizlik değil disk büyütmesidir.

3-2-1 Kuralında Snapshot’ın Yeri#

3-2-1 kuralı yedekleme dünyasının en kısa özeti: verinin 3 kopyası olsun, 2 farklı ortamda dursun, 1 tanesi sunucunun bulunduğu yerin dışında olsun. Kural basit ama snapshot bu üç şartın hiçbirini tek başına karşılamaz.

1. kopya

Sunucunun kendisi — canlı veri. Snapshot bu kopyanın hızlı geri alma katmanıdır, ayrı bir kopya sayılmaz.

2. kopya

Farklı bir ortam: başka bir sunucu, nesne depolama, NAS ya da yedekleme servisi. Otomatik ve günlük olmalı.

3. kopya

Farklı lokasyon. Aynı veri merkezinde duran ikinci kopya, o merkezle ilgili bir olayda işe yaramaz.

Yani snapshot, 3-2-1 tablosunun içinde değil kenarında durur: kuralı hızlandırır, yerine geçmez. Kurulumun tam şablonu, saklama süreleri ve geri yükleme testi takvimi için 3-2-1 kuralı sayfasına bakın. Aşağıdaki betik ise “2. kopya” kısmının en yalın hâli:

#!/bin/bash
# /usr/local/bin/disari-yedek.sh — yedeği sunucu DIŞINA taşır
set -e
TARIH=$(date +%F)
GECICI=/var/backups/$TARIH
UZAK="yedek@203.0.113.50:/depo/web01"

mkdir -p "$GECICI"
mysqldump --single-transaction --quick --all-databases \
  | gzip > "$GECICI/veritabani.sql.gz"
tar -czf "$GECICI/site.tar.gz" /var/www /etc/nginx

# Uzak makineye aktar (SSH anahtarıyla, parolasız)
rsync -az --delete "$GECICI/" "$UZAK/$TARIH/"

# Yereldeki geçici kopyayı 3 gün sonra sil
find /var/backups -maxdepth 1 -type d -mtime +3 -exec rm -rf {} +

sudo chmod +x /usr/local/bin/disari-yedek.sh
# Her gece 02:45'te çalıştır
( sudo crontab -l 2>/dev/null; echo "45 2 * * * /usr/local/bin/disari-yedek.sh" ) | sudo crontab -
sudo crontab -l

Zamanlanmış görev sözdizimine yabancıysanız cron job rehberi alan alan açıklıyor. Aktarım için parolasız SSH anahtarı gerekir; kurulumunu bir kez yapıp betikte parola sormasını tamamen kaldırın.

Güncelleme Öncesi Güvenli Snapshot Prosedürü#

Aşağıdaki sıra, riskli bir işlemi mümkün olan en düşük riskle yapmanın standart yoludur. Yedi adım, yaklaşık on dakika.

1. Bakım penceresini seçin ve duyurun#

   Trafiğin en düşük olduğu saati seçin. Kullanıcı tarafı olan bir sistemse önceden haber verin; habersiz kesinti, kesintinin kendisinden fazla şikâyet üretir.

2. Tutarlı bir veritabanı dökümü alın#

   mysqldump --single-transaction ile başlayın ve çıktıyı sunucu dışına kopyalayın. Snapshot bu adımın yerine geçmez.

3. Servisleri düzgün durdurun#

   Süreçleri öldürmeyin, systemctl stop kullanın ve ardından sync çalıştırın. Bellekteki yazmalar diske inmeden alınan snapshot yarım kalır.

4. Snapshot’ı anlamlı bir adla alın#

   Tarih ve gerekçe yazın. Panelde snapshot’ın “tamamlandı” durumuna geçmesini bekleyin; işlem sürerken sunucuya dokunmayın.

5. Güncellemeyi yapın#

   Tek seferde tek değişiklik yapın. Aynı bakım penceresinde hem çekirdek güncelleyip hem PHP sürümü değiştirirseniz, bir şey bozulduğunda hangisinin yaptığını bilemezsiniz.

6. Doğrulayın#

   Servislerin ayağa kalktığını, sitenin açıldığını ve günlüklerde yeni hata olmadığını kontrol edin. Kontrol listesi: systemctl --failed, journalctl -p err -b, curl -I https://alanadiniz.com.

7. Snapshot’ı silin#

   Sistem 24–48 saat sorunsuz çalıştıysa snapshot’ın görevi bitmiştir. Silin. Duran snapshot hem yer tutar hem yazma performansına yük bindirir.

# 6. adımın komutları
systemctl --failed
sudo journalctl -p err -b --no-pager | tail -30
curl -I https://alanadiniz.com
ss -tulpn | grep -E ':(80|443|3306)\b'
df -h /

Kaçınılması gereken dört alışkanlık#

Snapshot’ı yedek sanmak. Sayfanın ana mesajı bu. Aynı altyapıda duran kopya, altyapıyla birlikte kaybolur.

Geri yükleme testini hiç yapmamış olmak. Yedeği alıp bir kenara koymak yetmez; yılda en az bir kez o yedekten gerçekten dönebildiğinizi test edin. Test edilmemiş yedek, yedek değil temennidir.

Aylarca duran snapshot bırakmak. Performansı düşürür, faturayı büyütür ve zamanla o kadar eskir ki geri dönmek bile mantıklı olmaktan çıkar.

Snapshot’a dönmeden önce mevcut durumu kaydetmemek. Geri dönüş tek yönlü bir kapıdır; ikinci bir snapshot o kapıyı çift yönlü hâle getirir.

Batihost Tarafında Nasıl Çalışır?#

Sağlayıcı paneli üzerinden snapshot alma ve geri yükleme birkaç tıklamalık bir iştir; sunucunun içine bir ajan kurmanız gerekmez. Panelde göremiyorsanız ya da yükseltme öncesi güvenli bir geri dönüş noktası istiyorsanız destek talebi açmanız yeterli — işlem yapılmadan önce hangi durumun dondurulacağını birlikte netleştirmek en sağlıklısı.

Sunucu tarafında ise sorumluluk paylaşımını baştan netleştirin: altyapının sürekliliği sağlayıcının, veri kopyalarının sunucu dışına çıkarılması sizin işinizdir. 156 TL’den başlayan VDS paketlerinde disk alanı NVMe üzerindedir; yedek hedefi olarak başka bir sunucu, nesne depolama ya da ofisinizdeki bir makine kullanabilirsiniz. Önemli olan hedefin nerede olduğu değil, üretim sunucusuyla aynı kaderi paylaşmaması.

Sunucunuzun genel sağlığını izlemiyorsanız yedeklerin çalışıp çalışmadığını da fark edemezsiniz; sessizce başarısız olan bir cron görevi aylarca kimsenin dikkatini çekmez. En azından yedek dosyasının boyutunu ve tarihini kontrol eden basit bir uyarı kurun. Araç seçenekleri sunucu izleme rehberinde anlatılıyor. Sanallaştırma katmanının ne olduğu ve snapshot’ın neden bu kadar hızlı çalıştığı konusunda temel bilgi için VDS nedir sayfası iyi bir başlangıç.

Özetle#

Snapshot, sunucunun o andaki disk durumunun aynı altyapı üzerinde tutulan kopyasıdır: saniyeler içinde alınır, dakikalar içinde geri yüklenir, ama altyapı kaybolduğunda o da kaybolur. İmaj çoğaltmak içindir, felaket kurtarma aracı değildir. Yedek ise verinin sunucudan dışarı çıkarılmış hâlidir ve gerçekten koruyan tek kopyadır.

Uygulamaya dökülmüş hâli şu: riskli her işlemden önce adlandırılmış bir snapshot alın, snapshot öncesi veritabanı için tutarlı bir döküm çıkarın, işlem başarılı olduktan 24–48 saat sonra snapshot’ı silin ve bunların hepsinden bağımsız olarak her gece sunucu dışına yedek atan bir görev çalıştırın. Bir de yılda bir kez o yedekten gerçekten dönebildiğinizi test edin — hala en çok atlanan adım budur. Yedekleme planınızı baştan kurmak isterseniz 3-2-1 kuralı sayfasındaki şablon işinizi görür.