Bir e-ticaret veritabanında tek bir hatalı sorgu, bir yazılım güncellemesinde bozulan yapılandırma dosyası veya fidye yazılımı saldırısı, aylarca üretilen veriyi dakikalar içinde erişilemez hale getirebilir. Bu nedenle VDS yedekleme stratejileri, yalnızca dosya kopyalamaktan ibaret değildir; hizmetin ne kadar sürede ve hangi veri kaybı sınırıyla geri döneceğini belirleyen operasyon planıdır.

Yüksek CPU gücü, NVMe depolama ve DDoS koruması uygulamanın çalışmasını hızlandırır ve korur. Ancak fiziksel arıza, kullanıcı hatası, uygulama hatası veya yetkisiz erişim sonrası geri dönüş noktası yoksa en güçlü altyapı bile iş sürekliliği açısından eksik kalır. Doğru strateji, performans altyapısını doğrulanmış geri yükleme süreçleriyle tamamlar.

VDS yedekleme stratejileri nereden başlar?

İlk adım, "neyi yedekliyoruz?" sorusunu netleştirmektir. Birçok ekip yalnızca web dosyalarını arşivlerken veritabanını, e-posta verilerini, kullanıcı yüklemelerini, SSL sertifikalarını, cron görevlerini ve sunucu yapılandırmalarını gözden kaçırır. Geri yükleme anında eksik kalan tek bir `.env` dosyası, API anahtarı ya da Nginx yapılandırması, sitenin yedeği var görünse bile servisin ayağa kalkmasını engelleyebilir.

Bu envanteri iş etkisine göre sınıflandırın. Siparişler, müşteri kayıtları, ödeme durumları ve proje kaynak kodu kritik kabul edilir. Geçici önbellek dosyaları, yeniden üretilebilen loglar veya CDN üzerinden tekrar indirilebilen statik içerikler aynı öncelikte olmayabilir. Her veriyi aynı sıklıkta yedeklemek depolama maliyetini yükseltir, geri yükleme süreçlerini de gereksiz biçimde karmaşıklaştırır.

Ardından iki hedef belirlenmelidir: RPO ve RTO. RPO, kabul edilebilir veri kaybı penceresidir. Örneğin bir mağaza için 15 dakikalık RPO, en fazla son 15 dakikanın sipariş veya stok hareketinin kaybedilebileceği anlamına gelir. RTO ise sistemin ne kadar sürede yeniden hizmet vermesi gerektiğini ifade eder. Kritik bir API için dört saatlik geri dönüş süresi kabul edilemezken, arşiv amaçlı bir proje için makul olabilir.

3-2-1 kuralı: Tek kopyaya güvenmeyin

VDS üzerinde alınan yedek, aynı VDS içinde tutuluyorsa gerçek bir felaket senaryosuna karşı koruma sağlamaz. Disk bozulması, yanlışlıkla silme, yetki ele geçirme veya şifreleme saldırısı hem canlı veriyi hem de yedeği etkileyebilir. Bu yüzden temel yaklaşım 3-2-1 kuralıdır: Verinin en az üç kopyası olmalı, bu kopyalar iki farklı ortamda tutulmalı ve en az bir kopya farklı bir lokasyonda bulunmalıdır.

Pratikte bu yapı; canlı VDS üzerindeki üretim verisi, ayrı depolama alanına alınan günlük yedek ve farklı lokasyonda ya da bağımsız bir bulut depolamada saklanan ek kopyadan oluşabilir. Türkiye lokasyonlu hizmet veren bir uygulamada yerel yedekleme, düşük gecikmeli geri dönüş avantajı sağlayabilir. Buna karşılık bölgesel ağ veya veri merkezi seviyesinde bir sorun için coğrafi olarak ayrı bir kopya gerekir. En doğru tercih, işinizin gecikme, regülasyon ve bütçe gereksinimlerine bağlıdır.

Yedeklerin değiştirilemez olması da kritik bir katmandır. Saldırgan sunucuya yönetici yetkisiyle eriştiğinde erişilebilir her kopyayı silmeye veya şifrelemeye çalışabilir. Saklama süresi kilitli, silme korumalı ya da ayrı kimlik bilgileriyle erişilen yedek hedefleri bu riski düşürür. Yedek depolama hesabında üretim sunucusuyla aynı parola ve aynı yetkili kullanıcıyı kullanmak, saldırının etki alanını büyütür.

Dosya ve veritabanı yedeklerini ayırın

Web uygulamalarında dosya yedeği ile veritabanı yedeğinin çalışma biçimi farklıdır. Dosyalar genellikle günlük artımlı veya fark yedekleriyle verimli biçimde korunabilir. Veritabanları ise tutarlılık ister. Çalışan bir MySQL, MariaDB veya PostgreSQL veritabanının yalnızca veri dizinini kopyalamak, bazı senaryolarda geri dönülemeyen bir bütünlük sorununa neden olabilir.

Veritabanı için mantıksal dump, fiziksel yedek veya replikasyon tabanlı yaklaşım seçilebilir. Mantıksal dump işlemi okunabilir ve taşınabilir çıktılar üretir, ancak büyük veritabanlarında geri yükleme süresi uzayabilir. Fiziksel yedekler daha hızlı geri dönüş sunabilir fakat sürüm uyumluluğu ve depolama düzeni daha fazla dikkat gerektirir. Yüksek işlem hacimli projelerde ikili günlükler veya zaman noktasına dönüş kabiliyeti, hatalı bir işlemin gerçekleştiği dakikadan hemen önceki duruma dönmek için değerli olabilir.

Yedekleme sırasında uygulama ile veritabanı arasındaki zaman farkını da yönetin. Saat 02.00'de veritabanı, 02.30'da dosyalar yedekleniyorsa iki veri seti farklı anları temsil edebilir. Özellikle sipariş, dosya yükleme ve kullanıcı üretimli içerik barındıran uygulamalarda tutarlılık kontrolleri gerekir. Kısa bakım modu, snapshot desteği veya uygulama seviyesinde yedekleme kancaları bu farkı azaltabilir.

Sıklık ve saklama politikasını iş yüküne göre kurun

Her gece tek tam yedek almak, düşük trafikli kurumsal bir web sitesi için yeterli olabilir. Ancak gün boyunca sipariş alan mağaza, oyun sunucusu, SaaS uygulaması veya ajansın aktif müşteri projesi için yeterli olmayabilir. Veri ne kadar sık değişiyorsa, yedekleme aralığı o kadar kısalmalıdır.

Etkili bir saklama planı, yalnızca son yedeği tutmaz. Son yedi günlük günlük kopyalar, son dört haftalık haftalık kopyalar ve son birkaç aylık aylık kopyalar, yaygın bir başlangıç modelidir. Bu yapı, yeni fark edilen bir hatanın eski ve temiz sürümüne ulaşmayı kolaylaştırır. Saklama süresini belirlerken KVKK kapsamındaki yükümlülükleri, sözleşmesel taahhütleri ve depolama maliyetini birlikte değerlendirin.

Tam yedekler geri yüklemeyi sadeleştirir ama ağ ve depolama tüketimini artırır. Artımlı yedekler daha az alan kullanır, ancak geri dönüşte birden fazla yedek zincirine ihtiyaç duyabilir. Kritik sistemlerde haftalık tam yedek ile gün içi artımlı yedeklerin birleşimi dengeli bir yaklaşım olabilir. Burada doğru cevap tek değildir: En iyi model, belirlediğiniz RPO ve RTO değerlerini gerçekten karşılayan modeldir.

Yedek almak değil, geri yüklemek belirleyicidir

Başarısız yedeklerin büyük bölümü kriz anına kadar fark edilmez. Bozuk arşiv, eksik izinler, yanlış şifreleme anahtarı, dolu depolama alanı veya tamamlanmamış veritabanı dump'ı, "başarılı" görünen bir job'ın arkasında saklanabilir. Bu nedenle yedekleme otomasyonunun yalnızca çalıştığını değil, ürettiği çıktının kullanılabilir olduğunu doğrulamak gerekir.

En az üç ayda bir kontrollü geri yükleme tatbikatı yapın. İzole bir test VDS üzerinde dosyaları, veritabanını ve yapılandırmaları geri alın; ardından uygulamayı açın, giriş akışını deneyin, son kayıtları kontrol edin ve kritik API çağrılarını test edin. Ölçtüğünüz süre gerçek RTO'nuzu gösterir. On dakikalık hedefe karşı iki saat süren geri dönüş, teknik olarak başarılı olsa da operasyonel olarak başarısızdır.

Tatbikat sonucunu kısa bir çalışma prosedürüne dönüştürün. Hangi yedek seçilecek, kim geri yükleme yetkisine sahip, DNS veya yük dengeleyici yönlendirmesi nasıl yapılacak, uygulama hangi sırayla açılacak ve müşterilere kim bilgi verecek? Bu doküman, gece saatlerinde yaşanan bir kesintide ekip içi belirsizliği azaltır. Yetki tek bir kişideyse, o kişinin ulaşılabilir olmadığı senaryo da planın parçası olmalıdır.

Güvenlik katmanlarını yedek sürecine dahil edin

Yedekler çoğu zaman üretim verisinden daha hassastır çünkü geniş kapsamlı müşteri kaydı, finansal veri veya kaynak kod içerir. Aktarım sırasında TLS gibi şifreli bağlantılar, saklama sırasında güçlü şifreleme ve erişimde çok faktörlü kimlik doğrulama kullanılmalıdır. Şifreleme anahtarlarının yalnızca yedeklenen sunucuda tutulması ise ters etki yaratabilir; anahtar yönetimi ayrı ve erişimi denetlenmiş olmalıdır.

İzleme tarafında yedek boyutu, işlem süresi, hata kodu, depolama kapasitesi ve son başarılı yedek zamanı takip edilmelidir. Normalde 40 GB olan günlük yedeğin aniden 2 GB'a düşmesi, eksik veri ya da hatalı bir dışlama kuralına işaret edebilir. Anlık monitöring ve anlamlı uyarılar, sorunu geri yükleme ihtiyacı doğmadan yakalamanın en hızlı yoludur.

VDS altyapısında snapshot kullanımı da değerlidir, ancak snapshot tek başına yedekleme değildir. Aynı depolama katmanında kalıyorsa altyapı seviyesindeki risklere karşı sınırlı koruma sunar. Snapshot'ı güncelleme öncesi hızlı geri dönüş noktası, bağımsız ve farklı konumda tutulan yedekleri ise felaket kurtarma katmanı olarak konumlandırın.

Vode Host gibi Tier III veri merkezi, NVMe tabanlı altyapı ve 7/24 gerçek insan desteği sunan bir sağlayıcı, üretim sisteminizin erişilebilirlik katmanını güçlendirir. Yine de sağlayıcı altyapısının güvenilirliği, uygulama veriniz için sizin belirlemeniz gereken RPO, saklama politikası ve geri dönüş testlerinin yerini tutmaz.

Bugün yapabileceğiniz en değerli işlem, son yedeğinizden rastgele bir dosya ve veritabanı kaydını test ortamına geri yüklemektir. Sonucun çalıştığını gördüğünüz anda yedekleme planınız varsayım olmaktan çıkar, ölçülmüş bir iş sürekliliği kabiliyetine dönüşür.

VDS Yedekleme Stratejileriyle Kesintiyi Azaltın