VPS Snapshot Nedir? Anlık Yedekleme Rehberi

VPS snapshot, sanal sunucunun belirli bir andaki disk ve yapılandırma durumunu kaydeden anlık görüntüdür. Güncelleme veya yapılandırma değişikliği öncesinde hızlı geri dönüş sağlar; ancak sağlayıcı altyapısına bağlı olduğu için tek başına yedek kabul edilmemelidir. Kritik veriler ayrıca ve farklı bir depolamada korunmalıdır.

VPS snapshot nedir ve nasıl çalışır?

VPS snapshot, sanal sunucunun belirli bir andaki disk ve yapılandırma durumunu kaydeden anlık görüntüdür. Sağlayıcının kullandığı sanallaştırma katmanına göre sanal diskleri, makine ayarlarını ve isteğe bağlı olarak RAM durumunu içerebilir. Hatalı bir güncellemeden sonra önceki duruma dönmeyi kolaylaştırır; tek başına uzun süreli ve bağımsız bir yedekleme planının yerini tutmaz.

Snapshot işlemi çoğunlukla copy-on-write mantığıyla çalışır. Mevcut bloklar ilk anda tamamen ikinci kez kopyalanmaz; sanal makine yeni veri yazdığında eski blok snapshot tarafından korunur. Bu nedenle işlem hızlı başlayabilir. Snapshot uzun süre saklanırsa değişen bloklar birikir ve depolama kullanımı artar.

Sağlayıcı panelindeki snapshot al düğmesi, işletim sistemi içindeki dosyaların uygulama açısından tutarlı olduğu anlamına gelmez. Sanal makine çalışırken veritabanı yazma işlemi devam ediyorsa farklı dosyalar farklı işlem noktalarında kalabilir. Dosya sistemi tutarlılığı ile uygulama tutarlılığı aynı şey değildir.

Ne yapılmalı – Snapshot’ı hızlı geri dönüş noktası, bağımsız yedekleri ise asıl kurtarma planı olarak tasarlayın.

Snapshot ile yedekleme arasındaki fark nedir?

Snapshot çoğunlukla aynı sağlayıcının depolama altyapısına bağlıdır. VPS hesabı, depolama kümesi veya sağlayıcı erişilemez hale gelirse snapshot’a da erişilemeyebilir. Yedek ise farklı bir depolama alanına, farklı bir bölgeye ya da farklı bir sağlayıcıya kopyalanabilir. 3-2-1 yaklaşımında verinin en az üç kopyası, iki farklı medya türü ve bir kopyası ana sistemden ayrı tutulur.

Snapshot’ın güçlü yanı hızdır. İşletim sistemi paketlerini güncellemeden önce alınan snapshot, bütün sanal diski eski durumuna döndürmeyi sağlayabilir. Bir dosya yanlışlıkla silindiğinde birkaç yüz gigabaytlık makineyi geri almak gereksizdir; rsync, borgbackup veya veritabanına özel yedek bu durumda daha doğru seçimdir.

Snapshot silinmiş dosyayı her zaman kolayca göstermez. Bazı paneller yalnızca tüm diski geri döndürür; tek dosya çıkarmak için snapshot’tan geçici bir disk veya yeni VPS oluşturmak gerekebilir. Bu işlem zaman ve ek depolama maliyeti doğurur.

Sağlayıcı dokümantasyonunda snapshot’ın nerede tutulduğunu, silinen snapshot’ın geri getirilebilip getirilemediğini ve depolama ücretini kontrol edin. Aynı isim farklı hizmetlerde farklı kapsam taşıyabilir: bazı platformlar yalnızca root diskini, bazıları bağlı veri disklerini de görüntüye dahil eder.

Ne yapılmalı – Bir dosyayı kurtarmak için tüm VPS’i geri almak yerine önce dosya ve veritabanı yedeklerini değerlendirin.

Snapshot almadan önce hangi hazırlıklar yapılmalı?

En güvenli snapshot, mümkünse uygulama yazma işlemlerinin kontrol edildiği snapshot’tır. Web sunucusu için trafiği kısa süre azaltmak, veritabanı için yazma işlemlerini durdurmak veya veritabanına uygun flush yöntemini kullanmak tutarlılığı artırır. VPS’i tamamen kapatmak en basit yöntemdir. Üretim trafiğinde bu her zaman uygulanamaz.

Çalışan VPS için temel hazırlık

• Snapshot öncesinde sağlayıcı panelinde doğru VPS kimliğini ve hostname’i doğrulayın.
• Disk kullanımını kontrol edin; snapshot büyümesi için boş alan bırakın.
• Aktif veritabanı yazmalarını ve uzun süren deployment işlemlerini gözden geçirin.
• Snapshot açıklamasına tarih, amaç ve geri dönüş sebebi yazın.
• Geri dönüşten önce DNS, kuyruk ve dış API etkilerini not edin.

Linux tarafında hızlı bir kontrol için şu komutlar yeterli bir başlangıç sağlar:

hostnamectl
findmnt /
df -hT
free -h
systemctl --failed

df -hT disk doluluğunu, findmnt ise bağlı dosya sistemini gösterir. Bu kontroller snapshot almaz; üzerinde işlem yapılacak makinenin doğru makine olduğunu ve kaynakların durumunu görmenizi sağlar.

Veritabanı kullanan bir WordPress VPS’inde snapshot öncesi ayrıca veritabanı dışa aktarımı alın. VPS’te WordPress Kurulumu: Adım Adım Rehber içindeki kurulum adımları uygulama katmanını hazırlar; kurtarma planı ayrıca sınanmalıdır. Snapshot’ın başarılı görünmesi, uygulamanın geri dönüşten sonra açılacağını kanıtlamaz.

Ne yapılmalı – Snapshot’tan önce hostname, disk kullanımı, çalışan işlemler ve veritabanı yazma durumunu kayda geçirin.

Proxmox üzerinde VPS snapshot nasıl alınır?

Proxmox VE kullanan ortamlarda snapshot işlemi panelden veya qm komut satırı aracından yapılabilir. Aşağıdaki örnekte sanal makine kimliği 101 olarak varsayılmıştır. Gerçek ortamda VM kimliğini panelden veya qm list çıktısından doğrulayın.

qm list
qm snapshot 101 before-kernel-update --description "2026-09-24 kernel update oncesi"
qm listsnapshot 101

İlk komut çalışan sanal makineleri listeler. İkinci komut before-kernel-update adlı snapshot’ı oluşturur; üçüncü komut snapshot ağacını gösterir. Açıklama alanı, aylar sonra görüntünün neden alındığını anlamayı kolaylaştırır.

RAM durumunu da kaydetmek isterseniz Proxmox tarafındaki --vmstate seçeneği kullanılabilir. Snapshot depolamasının RAM görüntüsünü taşıyacak kapasiteyi desteklemesi gerekir. Disk snapshot’ı ile RAM snapshot’ı aynı şey değildir; RAM kaydı alınmadan yapılan geri dönüş, makineyi normal bir açılış gibi başlatabilir.

qm snapshot 101 before-upgrade --description "Paket guncellemesi oncesi" --vmstate

Snapshot’ın geri dönüşü daha yıkıcı bir işlemdir. Snapshot alındıktan sonra yazılan veriler kaybolabilir. Kritik logları, yeni yüklenen dosyaları ve veritabanı yedeklerini önce koruyun.

qm rollback 101 before-upgrade

Proxmox yönetim kılavuzunda snapshot ve rollback davranışları depolama türüyle birlikte açıklanır. ZFS, LVM-thin ve Ceph gibi seçeneklerin snapshot kapasitesi, silme süresi ve bağımlılıkları farklı olabilir. Komutu çalıştırmadan önce hedef VM kimliğini ikinci kez kontrol edin.

Çalışan VPS’te snapshot almak güvenli mi?

“Çalışan sunucuda snapshot alınmaz” ifadesi fazla keskindir; “her zaman güvenlidir” demek de yanlıştır. İşletim sistemi ve dosya sistemi açısından görüntü alınabilirken uygulama verisi yazılma ortasında kalabilir. Web dosyalarında risk düşük olabilir, fakat MySQL, PostgreSQL, Redis veya yoğun dosya kuyruğu kullanan uygulamalarda tutarlılık ayrıca ele alınmalıdır.

En güvenli seçenek, bakım penceresinde VPS’i düzgün biçimde kapatıp snapshot almaktır. Kapatma mümkün değilse uygulamanın kendi yedekleme veya flush mekanizmasını kullanın. MySQL için mantıksal dump, PostgreSQL için pg_dump ya da fiziksel yedek araçları snapshot’tan bağımsız bir katman sağlar.

QEMU Guest Agent etkinse sanallaştırma platformu işletim sistemiyle daha kontrollü iletişim kurabilir. Bu, her veritabanı işleminin otomatik olarak güvenli biçimde duracağı anlamına gelmez; yalnızca guest işletim sistemiyle koordinasyon için ek bir kanal sağlar. Agent kurulumu ve etkinleştirilmesi kullanılan dağıtıma göre değişir.

Snapshot sonrasında uygulama loglarını, servis durumlarını ve veri bütünlüğünü kontrol edin. Web sunucusu active görünürken PHP-FPM soketi veya veritabanı servisi çalışmıyor olabilir. WordPress Veritabanı Bağlantı Hatası Nasıl Çözülür? başlığındaki belirtiler, rollback sonrasında bağlantı bilgilerinin veya socket dosyasının eski duruma dönmesiyle de görülebilir.

Ne yapılmalı – Üretim veritabanı çalışan VPS’lerde snapshot’ı uygulama yedeğiyle birlikte ve mümkünse kısa bakım penceresinde alın.

Snapshot saklama süresi ve depolama maliyeti nasıl hesaplanır?

Snapshot maliyeti yalnızca VPS’in toplam disk boyutuna bakılarak hesaplanmaz. Copy-on-write yapıda snapshot’ın tuttuğu alan, görüntü alındıktan sonra değişen bloklara ve snapshot zincirinin uzunluğuna bağlıdır. Sağlayıcılar bu alanı ayrılmış kapasite, kullanılan depolama miktarı veya sabit görüntü ücreti gibi farklı modellerle fiyatlandırabilir.

Basit bir tahmin için günlük değişen veri miktarını ve saklama süresini izleyin. 100 GB diskli bir sunucunun her gün 8 GB benzersiz blok değiştirmesi, 7 snapshot’ın tam olarak 700 GB kullanacağı anlamına gelmez; blokların tekrar yazılması, sıkıştırma, deduplikasyon ve sağlayıcının snapshot mimarisi hesabı değiştirir. Panelde görünen gerçek snapshot kullanımını düzenli kontrol edin.

Çok sayıda snapshot performans ve yönetim sorunu yaratabilir. “Her deploy için bir snapshot” yaklaşımı, silinmeyen eski görüntülerle depolamayı büyütebilir. Daha kontrollü bir politika; üretim için son 2-3 değişiklik noktasını, kritik yükseltme için geçici görüntüyü, uzun süreli saklama içinse harici yedeği ayırır.

Snapshot silme işlemi bazen arka planda uzun sürer. Zincirdeki eski bir görüntü başka snapshot’ların referans verdiği blokları tutuyor olabilir. Panelde silindi görünse bile depolama kullanımının hemen düşmemesi bu nedenle mümkündür.

Ne yapılmalı – Snapshot saklama politikasını süre, kullanım amacı ve gerçek depolama tüketimiyle birlikte belirleyin.

Snapshot geri yükleme sırasında nelere dikkat edilir?

Rollback, sunucuyu yalnızca eski dosyalara döndürmez; snapshot kapsamındaki tüm disk ve yapılandırma değişikliklerini etkileyebilir. Snapshot’tan sonra oluşturulan kullanıcılar, yüklenen paketler, veritabanı kayıtları ve loglar kaybolabilir. Önce kurtarılması gereken verileri ayrı bir alana kopyalayın.

Geri dönüş öncesi kontrol

• Hedef VPS’in hostname ve IP adresini doğrulayın.
• Snapshot tarihini ve açıklamasını kontrol edin.
• Snapshot sonrasında oluşan verileri harici depolamaya alın.
• DNS TTL değerlerini, kuyrukları ve dış servis bağlantılarını not edin.
• Rollback sırasında hizmet kesintisi olacağını kullanıcılara bildirin.

Rollback sonrasında servisleri rastgele yeniden başlatmak yerine önce temel durumu inceleyin:

hostnamectl
systemctl --failed
journalctl -b -p err..alert --no-pager
df -hT
ss -lntup

journalctl -b mevcut açılışın loglarını, ss -lntup ise dinleyen portları gösterir. Web sunucusu 80 ve 443 numaralı portlarda dinlemiyor, veritabanı 3306 veya 5432 üzerinde başlamıyorsa uygulama testine geçmeden bu katmanı düzeltin.

Rollback sonrasında DNS değişikliği gerekmeyebilir. Sağlayıcı ağ yapılandırmasını eski duruma aldıysa kayıtları yine doğrulayın. dig +short example.com ile dışarıdan görünen adresi kontrol etmek, paneldeki varsayımı sınamaktan daha hızlıdır.

VPS snapshot’ı işletim sistemi yükseltmelerinde kullanışlıdır. Kernel değişikliği, bootloader veya disk düzeniyle ilgili işlemlerde sağlayıcının snapshot geri dönüş garantisini ayrıca inceleyin. Kritik bir yükseltme öncesinde rescue erişiminin ve konsol bağlantısının çalıştığını görmek, başarısız açılışta seçenekleri artırır.

Ne yapılmalı – Rollback öncesi yeni verileri ayırın, sonrasında logları ve dinleyen portları kontrol etmeden uygulamayı trafiğe açmayın.

Snapshot yedekleme planına nasıl eklenir?

İyi bir plan, snapshot’ı tek kurtarma yöntemi yapmaz. Bir WordPress VPS’i için günlük veritabanı dump’ı, dosyalar için sürümlü harici yedek, haftalık tam yedek ve paket güncellemesi öncesi geçici snapshot birlikte kullanılabilir. Yedeklerin başka bir sağlayıcıya veya ayrı bir depolama hesabına kopyalanması VPS hesabı kaybı riskini azaltır.

Geri dönüş hedeflerini iki ölçüyle yazın: RPO, kabul edilebilir veri kaybı süresidir; RTO, hizmetin yeniden açılması için kabul edilebilir süredir. Snapshot 15 dakika önceki duruma hızlıca dönmeyi sağlayabilir, fakat son 15 dakikadaki siparişleri korumaz. Veritabanı yedeği daha fazla veri koruyabilir; geri yükleme süresi daha uzun olabilir.

Yedekleme işlerinin tamamlandığını yalnızca cron çıktısına bakarak varsaymayın. Dosya boyutu, checksum, yedekleme logu ve geri yükleme denemesi kontrol edilmelidir. Test edilmemiş yedek, pratikte yalnızca umut taşır.

Buluta Geçiş Rehberi: 10 Adımda Taşıma Planı içinde taşıma öncesi doğrulamanın önemi görülür; snapshot bu planın tamamı değil, geçiş öncesi emniyet kemerlerinden biridir. Nginx yapılandırması değişiyorsa Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma adımlarına ek olarak mevcut yapılandırma dosyalarını da ayrı yedekleyin.

Depolama ve kaynak izleme için snapshot görevlerini monitoring sistemine bağlayın. Başarısız snapshot, dolan depolama veya beklenenden uzun süren silme işlemi alarm üretmelidir. Yalnızca son başarılı yedek tarihini gösteren panel, silinmiş ya da doğrulanmamış kopyayı başarı saymamalıdır.

Ne yapılmalı – Snapshot, uygulama yedeği ve harici kopyayı farklı arıza senaryolarını karşılayacak şekilde birlikte test edin.

Snapshot Almadan Önce Şunları Kontrol Edin

• Doğru VPS hostname'ini ve VM kimliğini doğrulayın.
• Disk kullanımını ve snapshot için ayrılan depolama limitini kontrol edin.
• Çalışan veritabanı yazmalarını ve uzun süren deployment işlemlerini gözden geçirin.
• Kritik dosya ve veritabanı yedeğini ayrı depolamaya kopyalayın.
• Snapshot açıklamasına tarih, amaç ve sürüm bilgisini yazın.
• Rollback sırasında kaybolabilecek yeni verileri önceden ayırın.
• Geri yükleme sonrasında servis ve veri doğrulaması yapacağınız adımları kaydedin.

Snapshot hızlı bir geri dönüş noktası sunsa da dosya, System State ve bare-metal kapsamı için ayrıca planlı yedek almak gerekir. Windows Server Yedekleme Nasıl Yapılır? rehberimde Windows Server Backup ve wbadmin ile bu süreci nasıl kurduğumu anlattım.

Sık Sorulan Sorular

Kaynaklar

• Proxmox VE Administration Guide — pve.proxmox.com
• NIST Contingency Planning Guide — csrc.nist.gov
• Proxmox qm Manual — pve.proxmox.com