Snapshot Yedek midir? Snapshot ile Yedekleme Arasındaki Fark

Snapshot yedek midir sorusu, VDS panelini ilk açan hemen herkesin aklına aynı sebeple gelir: panelde en görünür yerde duran düğmenin adı "Snapshot Al"dır, bir tıklamada iş biter ve ekranda "başarıyla oluşturuldu" yazar. Bu kadar kolay olan bir şeyin yedekleme sorununu çözdüğünü varsaymak son derece anlaşılır. Ne yazık ki cevap net: snapshot bir yedek değildir, yedek yerine de geçmez. Aynı işi yapmazlar, aynı riskleri karşılamazlar ve birini diğerinin yerine koymak, ihtiyaç duyduğunuz gün elinizde hiçbir şey olmaması demektir.

Bu yazıda snapshot ile yedek arasındaki farkı teknik düzeyde açıklıyoruz: snapshot'ın disk üzerinde nasıl tutulduğunu, neden aynı disk arızasında verilerle birlikte kaybolduğunu, uzun süre tutulan bir anlık görüntünün delta dosyasını şişirerek sunucuyu nasıl durdurabildiğini ve silinmesi unutulan snapshot'ların hangi sürprizleri çıkardığını. Ayrıca snapshot'ın gerçekten doğru araç olduğu senaryoları da tarif ediyoruz — çünkü bu özellik kötü değildir, sadece yanlış işe koşulmaktadır.

Snapshot Nedir ve Diskte Nasıl Durur#

Snapshot, bir sanal makinenin diskinin belirli bir andaki durumunu dondurup, o andan sonraki tüm değişiklikleri ayrı bir katmana yazan bir mekanizmadır. Kelime karşılığı "anlık görüntü"dür ve bu isim aslında ne yaptığını iyi anlatır: fotoğraf çeker, kopya çıkarmaz.

Çalışma mantığı "yazarken kopyala" (copy-on-write) ilkesine dayanır. Snapshot alındığı anda mevcut disk dosyası salt okunur hâle getirilir ve yeni bir delta dosyası açılır. Sunucu çalışmaya devam ederken yapılan her değişiklik — yeni bir log satırı, güncellenen bir veritabanı sayfası, yüklenen bir görsel — asıl diske değil, bu delta dosyasına yazılır. Sistemin gördüğü disk, ana dosya ile deltanın üst üste bindirilmiş hâlidir.

Bunun iki doğrudan sonucu vardır. Birincisi, snapshot almak saniyeler sürer; çünkü ortada kopyalanan bir veri yoktur, yalnızca bir dosya kapatılıp yenisi açılmıştır. İkincisi ve daha önemlisi: snapshot, verinin ikinci bir kopyası değildir. Delta dosyası ana disk dosyasına bağımlıdır ve ikisi de aynı depolama üzerinde durur.

Aynı mantık farklı katmanlarda da karşınıza çıkar: LVM anlık görüntüleri, ZFS ve Btrfs dosya sistemi snapshot'ları, sanallaştırma platformlarının VM snapshot'ları. Blok düzeyinde çalışan LVM tarafını merak ediyorsanız LVM mantıksal birim yönetimi yazısı bu yapıyı ayrıntılandırıyor.

Yedek Nedir ve Snapshot'tan Farkı Nerede Başlar#

Yedek, verinin başka bir yerde duran, kaynağından bağımsız çalışabilen tam bir kopyasıdır. Kritik kelime "bağımsız"dır. Bir yedeğin işe yaraması için kaynak sunucunun, kaynak diskin, hatta kaynak veri merkezinin ayakta olması gerekmez.

Fark buradan itibaren keskinleşir:

Tablonun ilk satırı tek başına tartışmayı bitirir. Snapshot'ın koruduğu şey verinin kendisi değil, verinin belirli bir andaki hâlidir; ve bu hâl, altındaki fiziksel depolama sağlamken anlamlıdır.

Snapshot Yedek Yerine Neden Geçmez#

Snapshot yedek yerine geçmez çünkü bir yedeğin karşılaması gereken risklerin çoğuna karşı hiçbir koruma sağlamaz. Somutlaştıralım.

Disk veya depolama arızasında birlikte gider. Snapshot ile ana disk dosyası aynı depolama havuzunda durur. O havuzda ciddi bir arıza olduğunda ikisi birden kaybolur. Yedekleme literatüründeki "aynı gemide iki kopya, hâlâ tek kopyadır" kuralı tam olarak bunu anlatır.

Sunucu silinirse snapshot da silinir. Ödeme aksaklığı, yanlışlıkla verilen bir "sunucuyu sil" komutu veya hesap kapanması durumunda sanal makineyle birlikte ona bağlı anlık görüntüler de temizlenir. Yedek ayrı bir hesapta ve ayrı bir depoda durduğu için bu senaryoda ayaktadır.

Fidye yazılımı senaryosunda güvenilmez. Sunucuya kök yetkisiyle sızan bir saldırgan, panele erişimi varsa snapshot'ları da silebilir. Yalnızca ekleme yapılabilen (append-only) veya nesne kilidi olan bir yedek deposu bu senaryoda gerçekten korur, snapshot korumaz.

Geçmişe derinlemesine dönüş sağlamaz. Snapshot'lar performans nedeniyle uzun süre tutulmaz. Bir veri kaybı üç hafta sonra fark edilirse — ki mantıksal bozulmalarda çok sık olur — o tarihe ait bir snapshot elinizde olmaz. Yedeklerde ise haftalık ve aylık saklama kolayca kurulur.

Tek dosya kurtarmak zordur. Yanlışlıkla silinen bir müşteri klasörünü geri almak için snapshot'a dönerseniz, o saatten sonraki tüm siparişleri, e-postaları ve log kayıtlarını da geri almış olursunuz. Yedekte tek bir dosyayı seçip çıkarmak mümkündür.

Sağlayıcıdan çıkarılamaz. Snapshot, sağlayıcının sanallaştırma altyapısına özgü bir yapıdır. Başka bir sağlayıcıya taşınmaz, indirilip saklanamaz. Yedek dosyası ise taşınabilir.

Kısacası snapshot, "bir şeyi bozarsam hızlıca geri dönerim" ihtiyacını çok iyi karşılar; "her şeyi kaybedersem elimde ne kalır" sorusuna hiçbir cevap vermez.

Uzun Süre Tutulan Snapshot Sunucuyu Nasıl Durdurur#

Bu, snapshot'ın en az bilinen ve en çok zarar veren yan etkisidir: snapshot'ı silmeyi unutmak sunucuyu durdurabilir.

Sebep delta dosyasının büyümesidir. Snapshot alındığı andan itibaren her disk yazması deltaya gider ve delta durmadan büyür. Yoğun log üreten bir web sunucusunda, veritabanı yazan bir uygulamada ya da düzenli yedek arşivi oluşturan bir makinede bu büyüme hızlıdır. Depolama havuzunda ayrılmış alan dolduğunda sanal makine yeni veri yazamaz hâle gelir; işletim sistemi diski dolu görür ve servisler sırayla durur.

Belirtiler tanıdıktır ve genellikle yanlış yorumlanır:

df -h
# /dev/vda1  40G  40G  0  100% /

tail -5 /var/log/mysql/error.log
# [ERROR] Disk is full writing './site_db/orders.MYD'. Waiting for someone to free space...

Sistem yöneticisi bu tabloyu görünce log temizler, önbellek siler, eski dosyaları kaldırır — ama boşalan alan geri gelmez, çünkü sorun sanal makinenin içinde değil, altındaki delta dosyasındadır. Disk dolma sorununun sunucu içi sebeplerini elemek için disk dolu hatası çözümü yazısındaki adımları uygulayın; sunucunun içi temizken sorun sürüyorsa gözünüzü hipervizör tarafındaki snapshot'a çevirin.

İkinci yan etki performanstır. Her okuma isteği artık ana disk ile delta katmanı arasında çözümlenmek zorundadır. Zincirde ne kadar çok snapshot varsa, gecikme o kadar artar. Üst üste alınmış birkaç anlık görüntüsü olan bir veritabanı sunucusunda bu, gözle görülür bir yavaşlama olarak hissedilir.

Üçüncüsü ise faturaya yansıyandır. Çoğu sağlayıcıda snapshot'lar tuttukları alan kadar depolama tüketir. Test için alınıp unutulan bir görüntü aylarca alan işgal eder ve kimse fark etmez.

Pratik kural: snapshot'ın ömrü saatlerle ölçülmelidir, günlerle değil. Riskli işlemden önce alın, işlem doğrulandıktan sonra hemen silin. Ayda bir panelinizdeki anlık görüntü listesini gözden geçirip yetim kalmışları temizleyin.

Snapshot Ne Zaman Doğru Araçtır#

Snapshot kötü bir özellik değildir; sadece dar ve net bir işi çok iyi yapar. Bu işlerin ortak yanı hepsinin kısa süreli ve geri dönüşü planlı olmasıdır:

1. Büyük sürüm yükseltmesi öncesinde. İşletim sistemi ana sürüm yükseltmesi, çekirdek güncellemesi ya da kontrol paneli yükseltmesi öncesi snapshot alın. Yükseltme kötü giderse dakikalar içinde geri dönersiniz.
2. Kritik yapılandırma değişikliğinden önce. Güvenlik duvarı kurallarını değiştirmek, ağ yapılandırmasını elden geçirmek, disk bölümlemesine dokunmak — bunların hepsi sunucuya erişiminizi kaybettirebilecek işlerdir.
3. Yeni yazılım denemesinde. Bir yığını kurup beğenmezseniz temiz duruma dönmenin en hızlı yolu snapshot'tır; elle kaldırmakla uğraşmazsınız.
4. Şablon oluştururken. Bir sunucuyu istediğiniz gibi yapılandırıp o hâlden yeni makineler türetmek isterseniz snapshot iyi bir başlangıç noktasıdır.
5. Geçici test ortamında. Aynı testi defalarca aynı başlangıç noktasından çalıştırmak gerektiğinde idealdir. Kalıcı test ortamı kuruyorsanız staging ortamı nedir yazısındaki yaklaşımı tercih edin.

Bu beş maddenin hiçbirinde snapshot günlerce tutulmaz. Hepsi "al, işlemi yap, doğrula, sil" ritmine oturur.

VDS Panelinde Snapshot Alma ve Silme#

Panel arayüzleri sağlayıcıya göre değişir ama akış hemen her yerde aynıdır:

1. Müşteri panelinde ilgili sunucunun yönetim ekranını açın.
2. Snapshot (veya Anlık Görüntü) sekmesine geçin.
3. Snapshot Oluştur düğmesine basın ve tanımlayıcı bir ad verin — "test" değil, "php-8-yukseltme-oncesi-11-08" gibi.
4. Oluşturma bitene kadar bekleyin; süre disk boyutuna göre değişir.
5. Riskli işleminizi yapın.
6. Sonuç iyiyse snapshot'ı silin; kötüyse geri yükleyin (deploy/restore).

Snapshot alırken veri tutarlılığı için iki noktaya dikkat edin. Sunucu çalışırken alınan snapshot, o andaki diskin fotoğrafını çeker ama belleğe henüz diske yazılmamış veriler yakalanmaz. Veritabanı bu duruma karşı hassastır. Mümkünse snapshot öncesi tamponları boşaltın:

sync
mysql -e "FLUSH TABLES WITH READ LOCK;" &
# snapshot alındıktan hemen sonra kilidi bırakın

Daha temiz yol, kritik veritabanı sunucularında snapshot'ı makine kapalıyken almaktır. Kısa bir bakım penceresi, tutarsız bir görüntüden iyidir.

Geri yükleme adımı da dikkat ister: snapshot geri yüklendiğinde sunucu o ana döner ve aradaki tüm veriler kaybolur. Snapshot alındıktan sonra gelen siparişler, e-postalar ve kayıtlar geri gelmez. Bu yüzden geri yüklemeden önce, mümkünse mevcut durumdan da bir kopya alın.

Snapshot ve Yedeği Birlikte Kullanan Doğru Kurulum#

Doğru cevap "snapshot mı yedek mi" değil, "snapshot ve yedek"tir. İkisi farklı katmanlarda çalışır ve birbirini tamamlar.

Sağlam bir kurulum şöyle görünür:

• Günlük otomatik yedek. Dosyalar ve veritabanı, sunucu dışında bir depoya. Bu, felaket kurtarmanın temelidir. Kurulum adımları için VDS yedeği nasıl alınır yazısına bakın.
• Haftalık ve aylık saklama. Bir bozulmanın haftalar sonra fark edildiği durumlar için geçmişe dönüş imkânı. Sıklık kararını ne sıklıkta yedek alınmalı yazısı ayrıntılandırıyor.
• Artımlı ve şifreli depo. Aynı veriyi her gün baştan kopyalamamak için Borg ile sunucu yedekleme veya restic ile yedekleme araçları uygundur; ikisi de şifreleme ve tekilleştirme yapar.
• İhtiyaç anında snapshot. Yalnızca riskli işlemlerden önce, alındıktan birkaç saat sonra silinmek üzere.
• Düzenli geri yükleme testi. Ayda bir yedeği gerçekten açıp içeriğini doğrulayın. Test edilmemiş yedek, yedek değildir.

3-2-1 kuralını hatırlamakta fayda var: en az üç kopya, iki farklı ortam, biri tesis dışında. Snapshot bu üçlünün hiçbir basamağını tek başına doldurmaz — çünkü ne ayrı bir kopyadır ne de farklı bir ortamdadır.

Yeni bir sunucu kurduysanız yedekleme, snapshot politikası ve izleme kurulumunu ilk hafta içinde yapın; VDS satın alma sonrası ilk adımlar yazısı bu ilk yapılacaklar listesini sıralıyor. Sağlayıcı değiştiriyorsanız snapshot'ınızı yanınızda götüremeyeceğinizi unutmayın; taşıma için eski hostingden site yedeği alma yazısındaki dosya ve veritabanı temelli yöntem gerekir.

Sıkça Sorulan Sorular#

Snapshot yedek yerine geçer mi#

Geçmez. Snapshot verinin ikinci bir kopyası değil, aynı depolama üzerinde tutulan bir geri dönüş noktasıdır; ana disk dosyası olmadan tek başına bir anlamı yoktur. Bu yüzden disk arızası, sunucunun silinmesi, hesabın kapanması veya sağlayıcı değişikliği gibi durumların hiçbirinde koruma sağlamaz. Snapshot'ın karşıladığı ihtiyaç "yaptığım işlem kötü giderse hızlıca geri döneyim"dir; yedeğin karşıladığı ihtiyaç ise "her şeyi kaybedersem elimde tam bir kopya kalsın"dır. İkisi farklı sorulara cevap verir ve birlikte kullanılmaları gerekir.

Snapshot almak sunucuyu yavaşlatır mı#

Alma anında kısa bir duraklama olabilir, asıl yavaşlama ise snapshot uzun süre tutulduğunda ortaya çıkar. Snapshot aktifken her disk yazması ayrı bir delta katmanına gider ve her okuma isteği ana disk ile delta arasında çözümlenmek zorunda kalır; zincirde ne kadar çok anlık görüntü varsa gecikme o kadar artar. Yoğun yazma yapan veritabanı sunucularında bu etki gözle görülür seviyeye çıkabilir. Bu nedenle snapshot'ı işlemi doğruladıktan hemen sonra silmek, performans açısından da doğru davranıştır.

Snapshot ne kadar süre tutulmalı#

Saatlerle ölçülecek kadar; günlerce tutmak sorun çıkarır. Snapshot aktifken delta dosyası büyümeye devam eder ve depolama havuzundaki alan dolduğunda sanal makine yeni veri yazamaz hâle gelir, bu da servislerin durmasına yol açar. Ayrıca çoğu sağlayıcıda snapshot tuttuğu alan kadar depolama tüketir, dolayısıyla unutulan görüntüler sessizce kaynak harcar. Pratik kural şudur: riskli işlemden hemen önce alın, işlem sonucunu doğrulayın, ardından silin ve ayda bir panelinizdeki anlık görüntü listesini gözden geçirin.

Snapshot geri yükleyince aradaki veriler ne olur#

Kaybolur. Snapshot geri yüklendiğinde sunucu, görüntünün alındığı ana tam olarak geri döner; o andan sonra gelen siparişler, kaydedilen dosyalar, alınan e-postalar ve veritabanı kayıtları silinir. Bu davranış özellikle e-ticaret ve üyelik sitelerinde ciddi kayıp yaratır, çünkü sistem çalışmaya devam ederken saatler geçmiş olabilir. Geri yüklemeden önce mümkünse mevcut durumdan da bir kopya alın; en azından veritabanının dökümünü çıkarıp güvenli bir yere koyun ki sonradan iki kaydı birleştirebilesiniz.

Sunucumu silersem snapshot'larım kalır mı#

Genellikle kalmaz; snapshot'lar bağlı oldukları sanal makineyle birlikte silinir. Bu, snapshot'a yedek muamelesi yapmanın en pahalı sonuçlarından biridir: hesap kapanması, ödeme aksaklığı ya da yanlışlıkla verilen bir silme komutu hem sunucuyu hem de tüm geri dönüş noktalarını aynı anda yok eder. Yedekler ayrı bir depoda, ideal olarak ayrı bir hesapta durduğu için bu senaryoda ayakta kalır. Sunucuyu silmeden önce mutlaka sunucu dışında bir yedeğinizin bulunduğunu doğrulayın.

Snapshot'ı indirip bilgisayarımda saklayabilir miyim#

Çoğu durumda saklayamazsınız. Snapshot, sağlayıcının sanallaştırma altyapısına özgü bir yapıdır ve ana disk dosyasına bağımlı olduğu için taşınabilir tek bir dosya olarak indirilmesi genellikle mümkün değildir. Sunucunun tamamını dışarı almak istiyorsanız disk imajı dışa aktarma özelliği ya da klasik yedekleme araçlarıyla oluşturulmuş bir arşiv gerekir. Bu da snapshot ile yedek arasındaki temel farkı somutlaştırır: yedek dosyası taşınabilir ve başka bir sağlayıcıda geri yüklenebilir, snapshot ise bulunduğu altyapıya bağlıdır.

Fidye yazılımına karşı snapshot koruma sağlar mı#

Sınırlı ve güvenilmez bir koruma sağlar. Sunucuya kök yetkisiyle sızan bir saldırgan panel erişimini de ele geçirmişse snapshot'ları silebilir; dosya sistemi düzeyindeki anlık görüntüler ise doğrudan sunucu içinden silinebilir. Gerçek koruma, yedeğin sunucudan bağımsız bir hesapta ve mümkünse yalnızca ekleme yapılabilen ya da nesne kilidi bulunan bir depoda tutulmasıdır; böylece saldırgan sunucuya tam hâkim olsa bile yedeklere dokunamaz. Yedeklerin şifrelenmesi de bu senaryoda ayrıca önemlidir, çünkü çalınan bir yedek de en az silinen bir yedek kadar sorun yaratır.

Kapanış#

Snapshot ile yedek arasındaki farkı tek cümleye indirmek gerekirse: snapshot zamanda geri dönüş, yedek ise verinin bağımsız kopyasıdır. Snapshot alması saniyeler sürer, aynı depolamada durur, kaynağına bağımlıdır ve uzun tutulduğunda faydadan çok zarar verir. Yedek ise alması uzun sürer, başka bir yerde durur, tek başına ayakta kalır ve aylar öncesine dönmenizi sağlar. Panelde en görünür düğme snapshot olduğu için çok sayıda sunucu yalnızca bu düğmeye güvenerek çalışır; o sunucular bir disk arızasına ya da silinmiş bir hesaba kadar sorunsuz görünür, sonra hiçbir şey kalmaz.

Yedekleme zincirini kurmak, çalıştığını doğrulamak ve düzenli olarak test etmek istemiyorsanız bu işi devretmek de bir seçenek: yedekleme hizmeti yedeklerin sunucu dışına alınmasını ve saklama süresinin yönetilmesini üstlenir. Kendi snapshot ve yedek politikanızı yönetmek için kök erişimine ihtiyacınız varsa sanal sunucu paketleri buna uygundur; anlık görüntü ve kaynak esnekliğini daha çok kullanacaksanız bulut sunucu tarafına bakabilirsiniz. Güncelleme, izleme ve yedek kontrolü gibi rutin işleri de bırakmak isterseniz sunucu yönetimi hizmeti bu bakımı düzenli olarak yürütür.