Bir sanal sunucuda işletim sistemi güncellemesi, veritabanı değişikliği veya uygulama dağıtımı yapılmadan önce snapshot oluşturmak yaygın bir uygulamadır. İşlem sonrasında sorun yaşanırsa önceki duruma dönülebileceği düşünülür. Ancak snapshot’ın bulunması, sunucudaki bütün verilerin bağımsız ve güvenli biçimde yedeklendiği anlamına gelmez.
Snapshot ve backup farklı teknik mekanizmalarla çalışır. Her ikisi de veri kurtarma süreçlerinde kullanılabilir; fakat korudukları kapsam, saklama yöntemleri, veri tutarlılığı ve geri yükleme seçenekleri aynı değildir.
Özellikle VDS, VPS ve Cloud sunucularda bu farkın bilinmesi önemlidir. Bir sanal makinenin önceki disk durumuna döndürülmesiyle uygulama verilerinin bağımsız bir yedekten kurtarılması farklı operasyonlardır.
Snapshot Nedir?
Snapshot, bir sistemin veya depolama biriminin belirli bir andaki durumunu temsil eden kurtarma noktasıdır.
Sanal sunucu altyapılarında snapshot genellikle sanal diskin belirli bir andaki blok durumunu kaydetmek amacıyla kullanılır. Ancak snapshot’ın çalışma biçimi sanallaştırma ve depolama platformuna göre değişebilir.
Bazı sistemlerde snapshot, mevcut disk verilerinin üzerine yapılan değişiklikleri ayrı katmanlarda takip eder. Bazılarında ise blok düzeyinde artımlı veri saklama mekanizmaları kullanılır.
Bu nedenle bütün snapshot sistemlerinin aynı depolama yapısına veya geri yükleme davranışına sahip olduğu varsayılmamalıdır.
Örneğin bir Linux sunucusunda uygulama güncellemesi yapılmadan önce snapshot oluşturulabilir. Güncelleme sonrasında işletim sistemi veya uygulama düzgün çalışmazsa uygun koşullarda snapshot üzerinden önceki disk durumuna dönülebilir.
Ancak snapshot oluşturulduktan sonra üretilen veriler geri dönüş sırasında kaybolabilir. Bu nedenle snapshot geri yüklemesi, özellikle aktif veritabanı bulunan sistemlerde dikkatle planlanmalıdır.
Backup Nedir?
Backup, veri kaybı veya sistem arızası durumunda kullanılmak üzere verilerin kurtarılabilir kopyalarının oluşturulmasıdır.
Yedekleme işlemi yalnızca bütün bir sunucuyu kapsamak zorunda değildir. Dosyalar, veritabanları, uygulama yapılandırmaları veya sanal diskler ayrı ayrı yedeklenebilir.
Yedekler farklı depolama sistemlerinde saklanabilir ve belirli sürelerle korunabilir.
Örneğin bir web uygulamasında şu bileşenlerin yedeklenmesi gerekebilir:
- Uygulama dosyaları ve kullanıcı yüklemeleri
- Veritabanı kayıtları
- Web sunucusu ve uygulama yapılandırmaları
- TLS sertifikaları ve gerekli anahtarlar
- Zamanlanmış görev tanımları
- Uygulamanın çalışması için gereken diğer yapılandırma bilgileri
Bir yedeğin gerçekten kullanılabilir olması, yalnızca dosyanın oluşturulmasına değil, bütünlüğünün doğrulanmasına ve gerektiğinde geri yüklenebilmesine bağlıdır.
Bu nedenle yedekleme sürecinin bir parçası olarak düzenli kurtarma testleri yapılmalıdır.
Snapshot ve Backup Arasındaki Temel Farklar
Snapshot ve backup arasındaki ayrım, yalnızca oluşturulma hızından ibaret değildir.
| Özellik | Snapshot | Bağımsız backup |
|---|---|---|
| Temel amaç | Belirli bir sistem veya disk durumuna dönmek | Verileri ayrı bir kurtarma kopyasında korumak |
| Kapsam | Platforma göre disk, sanal makine veya depolama birimi | Dosya, veritabanı, uygulama veya sistem |
| Saklama yeri | Snapshot altyapısına bağlı | Yerel veya bağımsız uzak depolama |
| Geri yükleme | Çoğunlukla disk veya sistem düzeyinde | Yedek türüne göre dosya, veritabanı veya sistem düzeyinde |
| Veri tutarlılığı | Uygulama koordinasyonu gerektirebilir | Kullanılan yedekleme yöntemine bağlı |
| Uzun süreli saklama | Her platformda uygun olmayabilir | Saklama politikasıyla yönetilebilir |
| Altyapı arızasına dayanıklılık | Saklama mimarisine bağlı | Ayrı hata alanlarında saklanırsa güçlenebilir |
Buradaki önemli nokta, snapshot’ın mutlaka güvensiz veya backup’ın her koşulda güvenli olmadığıdır.
Örneğin bağımsız depolama sistemine kopyalanan ve düzenli test edilen snapshot’lar yedekleme stratejisinin parçası olabilir.
Buna karşılık üretim sunucusuyla aynı diskte saklanan bir yedek dosyası, fiziksel disk arızasına karşı yeterli koruma sağlamayabilir.
Asıl değerlendirilmesi gereken konu, kurtarma kopyasının nasıl oluşturulduğu, nerede saklandığı ve hangi arıza senaryolarında kullanılabildiğidir.
Snapshot Neden Tek Başına Yeterli Olmayabilir?
Snapshot’ların önemli sınırlamalarından biri, kullanılan altyapıya bağımlı olabilmeleridir.
Bazı sanallaştırma sistemlerinde snapshot zincirleri, temel sanal diskle ilişkili şekilde tutulur. Temel depolama kaynağının kaybedilmesi, snapshot’ların da kullanılamamasına neden olabilir.
Bu durum bütün snapshot teknolojileri için geçerli değildir. Örneğin bazı bulut depolama platformları snapshot verilerini ayrı ve dayanıklı depolama altyapılarında tutar.
AWS’nin Amazon EBS snapshot belgeleri, blok düzeyinde anlık kopyaların nasıl oluşturulduğunu ve saklandığını açıklar.
Ancak dayanıklı bir snapshot depolama sistemi bile uygulama düzeyinde doğru kurtarma planının yerini otomatik olarak tutmaz.
Yanlışlıkla silme riski
Snapshot yönetim yetkisine sahip bir hesap ele geçirilirse veya hatalı işlem yapılırsa kurtarma noktaları silinebilir.
Bu nedenle yedekleme erişim yetkilerinin üretim sunucusu yönetiminden mümkün olduğunca ayrılması önemlidir.
Uzun süreli saklama gereksinimi
Bazı uygulamalarda haftalar veya aylar önceki verilerin geri getirilmesi gerekebilir.
Snapshot sistemi kısa süreli geri dönüş için tasarlanmışsa uzun dönemli veri saklama ihtiyacını karşılamayabilir.
Kısmi veri kurtarma
Bir sanal makinenin tamamını önceki duruma döndürmek, yalnızca silinen tek bir dosyayı kurtarmak için gereğinden kapsamlı olabilir.
Dosya veya veritabanı düzeyinde yedekler, belirli verilerin seçilerek geri yüklenmesini kolaylaştırabilir.
Canlı Veritabanlarında Snapshot Tutarlılığı
Snapshot kullanırken en önemli teknik konulardan biri veri tutarlılığıdır.
Bir veritabanı çalışırken veriler yalnızca diskte bulunmaz. Bellekte bekleyen değişiklikler, işlem günlükleri ve devam eden yazma işlemleri de olabilir.
Snapshot alındığı anda bütün uygulama işlemleri tutarlı bir noktada değilse geri yükleme sonrasında kurtarma işlemleri gerekebilir.
Bu nedenle iki kavramın ayrılması gerekir.
Crash-consistent snapshot
Crash-consistent snapshot, sistemin beklenmedik biçimde kapanmasına benzer bir andaki disk durumunu temsil eder.
Dosya sistemi ve veritabanı, yeniden başlatıldığında kendi kurtarma mekanizmalarını çalıştırmak zorunda kalabilir.
Bu yaklaşım bazı uygulamalarda yeterli olabilir; ancak bütün veritabanı işlemlerinin uygulama düzeyinde tutarlı olduğunu garanti etmez.
Application-consistent snapshot
Application-consistent snapshot, uygulamanın veri yazma işlemleriyle koordineli olarak oluşturulur.
Örneğin desteklenen mekanizmalar aracılığıyla uygulama yazmaları kısa süreli duraklatılabilir veya veritabanı uygun bir yedekleme durumuna getirilebilir.
Windows ortamlarında bazı uygulamalar Volume Shadow Copy Service (VSS) mekanizmasını destekler.
Linux sistemlerde ise kullanılan dosya sistemi, veritabanı ve sanallaştırma platformuna göre farklı yöntemler gerekebilir.
AWS’nin EC2 yedekleme ve kurtarma rehberi, sanal makine ve disk düzeyinde kurtarma seçeneklerini açıklar.
Önemli olan, kullanılan snapshot aracının uygulama tutarlılığı sağlayıp sağlamadığının belgeler üzerinden doğrulanmasıdır.
VDS ve VPS Sunucularda Snapshot Nasıl Değerlendirilmeli?
VDS ve VPS hizmetlerinde snapshot kullanılabilirliği, kullanılan sanallaştırma platformuna ve hizmet sağlayıcısının sunduğu yönetim özelliklerine bağlıdır.
Bir sunucunun sanal olması, otomatik snapshot veya bağımsız yedekleme özelliğinin mutlaka bulunduğu anlamına gelmez.
Bu nedenle hizmet değerlendirilirken şu soruların yanıtları aranmalıdır:
- Snapshot kullanıcı tarafından oluşturulabiliyor mu?
- Snapshot alınırken sanal makine çalışmaya devam edebiliyor mu?
- Snapshot’lar hangi depolama altyapısında saklanıyor?
- Kaç kurtarma noktası korunabiliyor?
- Snapshot geri yüklemesi mevcut diskin üzerine mi uygulanıyor?
- Snapshot dışarı aktarılabiliyor veya bağımsız yedeğe dönüştürülebiliyor mu?
Özellikle son iki soru kurtarma planı açısından önemlidir.
Mevcut diskin üzerine uygulanan geri dönüş işlemi, snapshot tarihinden sonraki değişiklikleri kaybettirebilir.
Bu nedenle kritik sistemlerde önce ayrı bir test sunucusunda kurtarma yapılması daha güvenli bir yöntemdir.
Cloud Sunucularda Snapshot Daha mı Güvenlidir?
Cloud sunucu kavramı tek bir depolama veya yedekleme mimarisini ifade etmez.
Bazı bulut platformları snapshot’ları dağıtık depolama üzerinde saklarken bazıları belirli bir depolama kümesine veya bölgeye bağımlı olabilir.
Dolayısıyla Cloud sunucunun otomatik olarak daha güvenli snapshot sağladığı söylenemez.
Değerlendirilmesi gereken konular arasında depolama dayanıklılığı, snapshot’ın saklandığı hata alanı, başka bölgeye kopyalanabilmesi, erişim yetkileri ve geri yükleme prosedürü bulunur.
Örneğin aynı veri merkezinde ayrı disklerde saklanan kurtarma noktaları, tek disk arızasına karşı yardımcı olabilir. Ancak veri merkezi genelindeki bir olay için farklı coğrafi konumda tutulan yedekler gerekebilir.
Bu nedenle Cloud veya VDS seçimi yapılırken yalnızca CPU, RAM ve disk kapasitesine değil, veri kurtarma mimarisine de bakılmalıdır.
RPO ve RTO Nedir?
Sunucu yedekleme stratejisinin iki önemli ölçütü Recovery Point Objective (RPO) ve Recovery Time Objective (RTO) kavramlarıdır.
RPO, kabul edilebilir en yüksek veri kaybı süresini ifade eder.
Örneğin bir uygulamanın RPO hedefi 15 dakikaysa, büyük bir arıza sonrasında en fazla 15 dakikalık veri kaybını tolere edebilecek bir kurtarma düzeni hedeflenir.
Bu hedefin karşılanması için yedekleme sıklığı, veri çoğaltma mekanizmaları ve kurtarma noktalarının bütünlüğü birlikte değerlendirilmelidir.
RTO ise hizmetin ne kadar süre içerisinde yeniden çalışır duruma getirilmesinin hedeflendiğini ifade eder.
Örneğin RTO hedefi iki saat olan bir sistemde kurtarma prosedürü, altyapının yeniden hazırlanmasını, verilerin yüklenmesini ve uygulama kontrollerini bu süre içerisinde tamamlamayı amaçlamalıdır.
RPO ve RTO garanti edilen sonuçlar değil, planlama hedefleridir. Gerçek sonuçlar ancak düzenli kurtarma testleriyle ölçülebilir.
RPO ve RTO neden birlikte düşünülmeli?
Çok sık snapshot oluşturmak düşük veri kaybı hedefi için yararlı olabilir. Ancak snapshot’tan geri yükleme uzun sürüyorsa hizmetin yeniden açılması gecikebilir.
Benzer şekilde hızlı geri yüklenebilen bir yedek, çok eski bir kurtarma noktasını temsil ediyorsa kabul edilemeyecek miktarda veri kaybına neden olabilir.
Bu nedenle yedekleme mimarisinde hem kurtarma noktalarının güncelliği hem de geri yükleme süresi dikkate alınmalıdır.
Snapshot ve Uzak Yedekleme Birlikte Nasıl Kullanılmalı?
Snapshot ve bağımsız yedekleme birbirinin alternatifi olmak zorunda değildir.
Örneğin bir uygulama sunucusunda güncelleme öncesinde snapshot oluşturulabilir. Aynı sistemin veritabanı ve dosyaları ise belirli aralıklarla ayrı bir depolama alanına yedeklenebilir.
Bu yaklaşımda snapshot kısa süreli sistem geri dönüşü için, bağımsız yedek ise daha geniş veri kaybı ve altyapı arızası senaryoları için kullanılabilir.
Hostider’ın uzak yedekleme alanı, üretim sunucusundan ayrı bir yerde dosya ve sunucu yedeklerini saklama ihtiyacı için değerlendirilebilecek hizmetlerden biridir.
Bununla birlikte FTP tabanlı bir depolama alanı, tek başına uygulama tutarlılığı, değiştirilemez yedek veya otomatik felaket kurtarma garantisi sağlamaz.
Yedekleme yazılımının oluşturduğu arşivlerin güvenli aktarımı, erişim yetkileri, şifreleme, saklama politikası ve geri yükleme testleri ayrıca planlanmalıdır.
Alternatif olarak nesne depolama hizmetleri, başka bir veri merkezindeki yedekleme sunucuları veya yönetilen yedekleme platformları kullanılabilir.
3-2-1 Yedekleme Yaklaşımı
Yaygın kullanılan 3-2-1 yaklaşımı, birden fazla veri kopyasının farklı saklama ortamlarında korunmasını temel alır.
Geleneksel yorumuyla üç veri kopyası, iki farklı depolama ortamı ve en az bir uzak kopya hedeflenir.
Ancak farklı depolama ortamı kavramı, her senaryoda mutlaka iki farklı fiziksel disk teknolojisi kullanılması gerektiği anlamına gelmez. Önemli olan ortak arıza risklerinin azaltılmasıdır.
Örneğin aynı sunucudaki iki farklı dizinde saklanan dosyalar, fiziksel sunucu kaybına karşı bağımsız koruma sağlamaz.
Benzer şekilde üretim sunucusu ve yedekleme alanı aynı yönetici hesabıyla kontrol ediliyorsa hesap ele geçirilmesi her iki kopyayı da riske atabilir.
Bu nedenle 3-2-1 yaklaşımı erişim kontrolü, ayrı hata alanları ve gerektiğinde değiştirilemez saklama mekanizmalarıyla desteklenmelidir.
Daha geniş yedekleme politikaları için Hostider Blog’daki hosting yedekleme stratejileri rehberi tamamlayıcı bir başlangıç kaynağıdır.
Otomatik Yedekleme Nasıl Planlanmalı?
Otomatik yedekleme sistemleri, belirli aralıklarla kurtarma noktası oluşturmak için kullanılabilir.
Ancak yedekleme sıklığı, yalnızca günlük veya haftalık gibi sabit bir kurala göre belirlenmemelidir.
Bir haber sitesinde içeriklerin güncellenme sıklığı ile yoğun sipariş alan bir e-ticaret uygulamasının veri değişim hızı aynı değildir.
Bu nedenle önce kabul edilebilir veri kaybı süresi belirlenmeli, ardından yedekleme sıklığı buna göre planlanmalıdır.
Otomasyonun güvenilirliği açısından şu kontroller önemlidir:
- Yedekleme görevinin başarı veya başarısızlık durumu kaydedilmeli.
- Eksik veya bozuk arşivler tespit edilebilmeli.
- Depolama alanının dolması izlenmeli.
- Başarısız işlemler için bildirim mekanizması bulunmalı.
- Saklama süresi ve eski yedeklerin temizlenmesi kontrollü yapılmalı.
- Belirli aralıklarla gerçek geri yükleme testi gerçekleştirilmeli.
Zamanlanmış görevin başarıyla çalışması, oluşturulan yedeğin mutlaka geri yüklenebilir olduğunu kanıtlamaz.
Yedekleme Sunucusuna Erişim Nasıl Korunmalı?
Uzak yedekleme alanı, üretim sisteminden ayrı olsa bile uygun erişim güvenliği gerektirir.
Yedekleme hesaplarına yalnızca gerekli dosya ve dizin izinleri verilmelidir.
Mümkünse yedekleri oluşturan hesabın eski kurtarma noktalarını silme yetkisi sınırlandırılmalıdır.
Ayrıca yönetici erişimi ile otomatik yedekleme hesabı birbirinden ayrılabilir.
Özel ağda bulunan yedekleme sistemlerine yönetici erişimi gerektiğinde SSH ProxyJump ve bastion sunucu mimarisi değerlendirilebilir.
Ancak bastion sunucu kullanılması, yedeklerin otomatik olarak şifrelendiği veya yetkisiz silmeye karşı korunduğu anlamına gelmez.
Erişim güvenliği, veri aktarım güvenliği ve yedek saklama politikası ayrı katmanlar olarak ele alınmalıdır.
Snapshot Geri Yükleme Öncesinde Nelere Dikkat Edilmeli?
Snapshot geri yüklemesi canlı sistemde veri kaybına yol açabileceğinden işlem öncesinde mevcut durum korunmalıdır.
Özellikle üretim veritabanı bulunan sunucularda doğrudan eski snapshot’a dönmek yerine mümkünse yeni bir sanal makine veya disk üzerinde test yapılmalıdır.
Geri yükleme öncesinde mevcut verilerin bağımsız bir kopyası alınmalı, snapshot’ın tarihi doğrulanmalı ve kurtarma işleminin hangi diskleri etkileyeceği belirlenmelidir.
Birden fazla diski kullanan uygulamalarda snapshot’ların birbirleriyle tutarlı bir zaman noktasını temsil edip etmediği kontrol edilmelidir.
Geri yükleme sonrasında yalnızca sunucunun açılması yeterli değildir.
Veritabanı bütünlüğü, uygulama servisleri, dosya izinleri, ağ yapılandırması ve gerekli dış entegrasyonlar da doğrulanmalıdır.
Test tamamlanmadan üretim trafiğinin yeni sisteme yönlendirilmesi risk oluşturabilir.
Hangi Durumda Snapshot, Hangi Durumda Backup Tercih Edilmeli?
| Senaryo | Öncelikli yaklaşım |
|---|---|
| İşletim sistemi güncellemesi öncesi kısa süreli geri dönüş | Uygun koşullarda snapshot |
| Yanlışlıkla silinen tek dosyanın kurtarılması | Dosya düzeyinde backup |
| Veritabanında belirli bir zamana dönme | Veritabanına uygun yedekleme ve günlük tabanlı kurtarma |
| Sanal makine yapılandırmasının eski duruma döndürülmesi | Snapshot veya sistem imajı |
| Üretim depolama altyapısının kaybı | Bağımsız depolamadaki backup |
| Uzun süreli veri saklama | Saklama politikası tanımlanmış backup |
| Kritik uygulamanın felaket kurtarması | Test edilmiş, çok katmanlı kurtarma mimarisi |
Bu tablo genel karar çerçevesidir. Gerçek uygulamada platformun snapshot özellikleri, bağımsız yedeklerin türü ve geri yükleme mekanizmaları belirleyici olur.
Sıkça Sorulan Sorular
Snapshot almak yedek almakla aynı şey midir?
Her zaman değildir. Snapshot belirli bir disk veya sistem durumunu temsil eder. Bağımsız backup ise verilerin kurtarılabilir kopyalarının ayrı bir saklama politikasıyla korunmasını amaçlar. Bazı snapshot sistemleri yedekleme çözümünün parçası olabilir.
Snapshot sunucu çalışırken alınabilir mi?
Bazı sanallaştırma ve depolama platformları çalışan sanal makinelerden snapshot alınmasını destekler. Ancak bu özellik, uygulama verilerinin her durumda tutarlı olacağını garanti etmez.
Snapshot geri yüklemek veri kaybına neden olur mu?
Evet. Mevcut diskin eski bir snapshot durumuna döndürülmesi, snapshot sonrasında yapılan değişiklikleri kaybettirebilir. İşlemden önce mevcut verilerin korunması gerekir.
Cloud sunucularda otomatik backup bulunur mu?
Bu durum hizmet sağlayıcısına ve seçilen pakete bağlıdır. Cloud sunucu kullanılması, otomatik yedekleme veya bağımsız kurtarma noktası bulunduğunu tek başına göstermez.
Snapshot ne kadar süre saklanmalı?
Saklama süresi uygulamanın gereksinimlerine, snapshot teknolojisine ve depolama maliyetine bağlıdır. Kısa süreli geri dönüş için oluşturulan snapshot’lar ile uzun dönemli yedekler aynı politikayla yönetilmek zorunda değildir.
Snapshot fidye yazılımına karşı yeterli midir?
Tek başına yeterli kabul edilmemelidir. Saldırganın snapshot yönetim yetkisine erişmesi halinde kurtarma noktaları da risk altında olabilir. Ayrı yetkilendirme, değiştirilemez saklama ve bağımsız yedekler değerlendirilmelidir.
Sonuç
Snapshot ve backup, sunucu veri koruma mimarisinde farklı ihtiyaçlara yanıt verir.
Snapshot, özellikle güncelleme veya yapılandırma değişikliği öncesinde belirli bir sistem durumuna geri dönmek için yararlı olabilir. Bağımsız backup ise veri kaybı, depolama arızası ve daha geniş kurtarma senaryolarında önemli bir rol üstlenir.
Ancak hiçbir yöntem yalnızca adından hareketle güvenli kabul edilmemelidir. Kurtarma noktasının nerede saklandığı, hangi verileri kapsadığı, uygulama tutarlılığı ve geri yükleme prosedürü birlikte değerlendirilmelidir.
VDS ve Cloud sunucularda sürdürülebilir bir veri koruma yaklaşımı; uygun snapshot kullanımı, bağımsız yedekleme, erişim güvenliği, tanımlı RPO/RTO hedefleri ve düzenli kurtarma testlerinin birlikte planlanmasıyla oluşturulur.
