Sıcak, Soğuk ve Arşiv Yedekleme: NVMe, SATA ve Object Storage

Yedekleme tarafında asıl zor olan, “kaç kopyam var?” sorusundan çok “hangi yedeğe kaç saniyede ulaşabiliyorum ve bu bana kaça mal oluyor?” sorusudur. Aynı altyapıda hem çok hızlı geri dönüş yapabilen, hem de aylarca hatta yıllarca saklanabilen yedekler tutmak istiyorsanız; sıcak, soğuk ve arşiv depolama katmanlarını bilinçli şekilde kurgulamanız gerekir. İşte burada NVMe, SATA ve Object Storage doğru rolü üstlendiğinde hem maliyet hem de kurtarma süreleri tarafında kazanım sağlayabilir.

Bu yazıda, örnek bir sıcak–soğuk–arşiv yedekleme stratejisini parçalara bölerek anlatacağız. NVMe diskleri nerede kullanmalıyım, SATA tabanlı yedek sunucular ne işe yarar, Object Storage tam olarak hangi katmanda devreye girmeli, 3‑2‑1 kuralını bu mimarinin neresine oturtabilirim gibi sorulara net, uygulamaya dönük cevaplar bulacaksınız. Ayrıca RPO/RTO hedeflerinizi depolama katmanlarıyla nasıl hizalayacağınızı, hangi iş yükü için hangi sıklıkta yedek almanız gerektiğini ve bu yedekleri seçtiğiniz altyapıda konumlandırırken hangi koşulları değerlendirmeniz gerektiğini adım adım ele alacağız.

Yedeklerde Sıcak, Soğuk ve Arşiv Ne Demek?

Önce kavramları netleştirelim. Aynı verinin birden fazla kopyasını tutabilirsiniz; ancak her kopyanın erişim hızı, saklama süresi ve maliyeti farklı olur. Bu yazıda sıcak, soğuk ve arşiv ayrımı depolama katmanlarını ifade eder; yedeğin sistem çalışırken mi yoksa durdurularak mı alındığını belirtmez. Aşağıdaki süreler ve disk seçimleri örnektir; gerçek RTO, veri hacmi, aktarım hızı ve geri yükleme işlemlerine bağlıdır.

Sıcak Depolama Katmanındaki Yedekler

Sıcak yedek; en hızlı erişmek istediğiniz, genellikle son saatler veya son birkaç günle sınırlı, performans açısından güçlü depolamada tuttuğunuz yedeklerdir. Özellikleri:

• RTO (geri dönüş süresi) hedefi çok düşüktür; dakikalar mertebesi.
• Genellikle NVMe SSD gibi yüksek IOPS sağlayan disklerde tutulur.
• Daha kısa saklama süresi vardır (örneğin 24 saat – 7 gün).
• Aynı fiziksel sunucudaki kopya yerel geri dönüşü hızlandırabilir, ancak o sunucunun kaybına karşı koruma sağlamaz; bağımsız bir kopya da gerekir.

Soğuk Depolama Katmanındaki Yedekler

Soğuk yedek; erişim hızının çok kritik olmadığı ama saklama süresinin daha uzun tutulduğu yedek katmanıdır.

• Örnek RTO hedefi saatler mertebesindedir; gerçek süre geri yükleme testiyle ölçülmelidir.
• SATA SSD/HDD gibi kapasite başına maliyet avantajı sağlayabilecek disklerde saklanabilir; NVMe ile hız ve fiyat farkı disk modeline, iş yüküne ve altyapıya bağlıdır.
• Günlük veya haftalık periyotlarla alınabilir; saklama süresi haftalar – aylar olabilir.
• Ayrı bir yedek sunucuda veya aynı veri merkezinde farklı bir depolama havuzunda konumlandırılabilir; bu katman zorunlu olarak çevrimdışı değildir.

Arşiv Yedek (Archive Backup)

Arşiv; nadiren erişilen ama hukuki, regülasyon veya kurumsal gereksinimler sebebiyle uzun süre saklanan yedeklerdir.

• Daha uzun bir RTO kabul edilebilir; hedefi seçilen depolama sınıfının geri çağırma gecikmesi ve tam geri yükleme süresiyle karşılaştırın.
• Object Storage uygun bir seçenek olabilir; düşük maliyetli arşiv sınıflarının bulunması ve toplam maliyet avantajı seçilen hizmete bağlıdır.
• Saklama süresi aylar – yıllar olabilir.
• Denetim, belirli yasal saklama yükümlülükleri veya uzun vadeli analitik ihtiyaçları için kullanılabilir. KVKK/GDPR kapsamındaki kişisel veriler için saklama süresi amaç ve hukuki dayanakla sınırlandırılmalıdır; bu düzenlemeler tek başına uzun süreli arşiv gerekçesi değildir.

RPO, zaman cinsinden kabul edilebilir veri kaybı hedefidir; RTO ise hizmetin yeniden çalışır hale gelmesi için hedeflenen süredir. Sıcak–soğuk–arşiv ayrımını, RPO/RTO hedeflerini anlatırken detaylandırdığımız yedekleme stratejisi planlama rehberiyle birlikte düşünmek önemli. Çünkü hangi katmanda ne kadar veri tutacağınızı RPO/RTO hedefleriyle birlikte saklama yükümlülükleri, bütçe ve riskler belirler. Planlanan yedek sıklığı tek başına RPO’nun karşılandığını göstermez; son başarılı, tutarlı ve ilgili arızadan etkilenmeden erişilebilir kalan kurtarma noktasını esas alın.

Depolama Katmanları: NVMe, SATA ve Object Storage’ın Rolü

Şimdi de depolama seçeneklerine bakalım: NVMe ve SATA disk erişim teknolojileridir; Object Storage ise bir depolama modelidir. Bu seçenekleri ihtiyaçlarınıza göre birlikte çalışacak katmanlar olarak tasarlayabilirsiniz.

NVMe: Sıcak Yedeklerin Evi

NVMe SSD’ler, SATA SSD’lere göre daha yüksek IOPS ve daha düşük gecikme sağlayabilir; fark disk modeli, iş yükü ve altyapı sınırlarına bağlıdır. Bu yüzden:

• Veritabanı sunucuları
• Yoğun PHP uygulamaları (WordPress, Laravel, Magento vb.)
• Log yoğun, gerçek zamanlı uygulamalar

gibi iş yüklerinde zaten tercih sebebidir. Ancak burada sadece canlı veri için değil, sıcak yedekler için de kritik rol oynar.

Örneğin NVMe depolama seçilmiş bir VPS üzerinde çalışan WooCommerce sitesi düşünelim. Altyapı ve yedekleme aracı destekliyorsa saatlik snapshot’lar veya dosya/veritabanı yedekleri planlanabilir. Yedekleri NVMe üzerinde tutmak depolama kaynaklı geri yükleme süresini azaltabilir; dakikalar düzeyinde RTO garantilemez. RPO, disk hızından değil, son başarılı ve tutarlı kurtarma noktasının yaşından etkilenir. Dosya ve veritabanı kopyalarının birlikte tutarlı olması sağlanmalı; aynı depodaki snapshot bağımsız yedek yerine sayılmamalıdır.

Disk tipi hakkında daha derin teknik karşılaştırma görmek isterseniz, NVMe SSD, SATA SSD ve HDD karşılaştırması rehberimizde karşılaştırma ve kullanım senaryolarını ele alıyoruz.

SATA SSD/HDD: Soğuk Yedek Sunucuları

SATA SSD/HDD katmanı, özellikle HDD kullanıldığında, kapasite başına maliyet avantajı sağlayabilir; performans ve fiyat farkı seçilen disk veya hizmete bağlıdır. Bu nedenle:

• Günlük veya haftalık tam yedekler
• Uzun saklama süreli ama yine de veri merkezine yakın olması istenen kopyalar
• Ransomware riskine karşı çevrimdışı tutulacak veya üretim ortamından ayrı erişim yetkileriyle korunacak yedek depoları

için değerlendirilebilir.

Örnek bir tasarımda, NVMe üzerinde çalışan üretim VPS’inizden her gece alınan tam yedekler ve gün içinde alınan artımlı yedekler ayrı bir SATA tabanlı yedekleme sunucusuna aktarılabilir. Yedek yazma yükü ayrı depoya taşınır; ancak üretim disklerinden veri okuma yükü sürer. Üretim depolaması arızalandığında, yedek sunucusu etkilenmemişse ve gerekli tam/artımlı yedek zinciri sağlamsa buradan geri dönüş yapılabilir. Aynı veri merkezindeki kopya, veri merkezi genelindeki arızalar için uzak kopyanın yerini tutmaz.

Object Storage: Arşiv ve Uzak Kopya

Object Storage, blok veya dosya depolamadan farklı olarak verileri nesne olarak saklayan ve HTTP/S3 benzeri protokollerle erişilen bir yapıdır. Yedekleme tarafında özellikle şu avantajları sunar:

• Ölçeklenebilirlik: Kapasite, hizmetin kotaları ve bütçe sınırları içinde artırılabilir.
• Farklı sıcaklık katmanları: Hizmete bağlı olarak standard, infrequent access ve arşiv sınıfları bulunabilir; erişim süreleri ve ücretleri değişir.
• Versiyonlama ve silme koruması: Desteklenip uygun yapılandırıldığında koruma sağlayabilir; versiyonlama tek başına değiştirilemezlik değildir.
• Coğrafi esneklik: Ayrı lokasyon seçilerek veya replikasyon yapılandırılarak uzak kopya tutulabilir; bu kendiliğinden gerçekleşmez.

Uzak lokasyonda seçilen S3 uyumlu bir Object Storage hizmetine, uyumlu bir yedekleme aracıyla yedek sunucularından veya VPS/cPanel ortamlarından şifreli ve artımlı yedekler gönderilebilir; araç ve hesap yetkileri bu iş akışını desteklemelidir. Hizmet destekliyorsa lifecycle policy (yaşam döngüsü politikaları) ile örneğin 30 günden eski nesneler arşiv sınıfına taşınabilir, 365 günden eskiler silinebilir. Bu süreler örnektir: Kurallar yedekleme aracının saklama ve temizleme mantığıyla uyumlu olmalı, gerekli tam/artımlı yedekleri veya metadata’yı silerek zinciri bozmamalıdır. Arşivden erişim gecikmeleri ve ücretleri de hesaba katılmalıdır. Bu konuyu Object Storage maliyet optimizasyonu rehberimizde detaylı şekilde anlattık.

Neden Katmanlı Yedekleme Mimarisi Kurmalısınız?

Sadece “günlük yedek alıyorum” demek, günümüz senaryolarında maalesef yeterli değil. Fidye yazılımları, insan hataları, yazılım bug’ları ve donanım arızaları karşısında yalnızca yedek sıklığı değil, kopyaların tutarlılığı, izolasyonu ve geri yüklenebilirliği de önemlidir. Katmanlı mimarinin size sağladığı başlıca faydalar şunlar:

3‑2‑1 Kuralını Gerçekçi Şekilde Uygulamak

Yedeklemede altın standartlardan biri 3‑2‑1 kuralıdır:

• Verinizin üretim verisi dahil en az 3 kopyası olsun.
• Bu kopyalar en az 2 farklı depolama medyasında bulunsun.
• Kopyalardan en az 1 tanesi saha dışında (offsite) tutulmuş olsun.

Sıcak–soğuk–arşiv mimarisi 3‑2‑1 tasarımını destekleyebilir; ancak üç katman tek başına bu kuralı sağlamaz. NVMe ve SATA farklı arayüzlerdir; Object Storage da fiziksel medya türünü belirtmez. Medya çeşitliliği, bağımsız arıza alanları ve uzak kopya ayrıca değerlendirilmelidir. Örnek yerleşim:

• Sıcak yedek: NVMe üzerinde, üretime çok yakın.
• Soğuk yedek: Ayrı SATA tabanlı yedek sunucusunda.
• Arşiv yedek: Farklı bir bölgede veya veri merkezinde Object Storage üzerinde.

Bu katmanlı yaklaşımın fidye yazılımlara karşı nasıl güç kattığını ransomware’a dayanıklı yedekleme stratejisi rehberimizde adım adım ele alıyoruz.

Maliyet – Performans Dengesini Kurmak

Tüm yedekleri NVMe üzerinde tutmak, veri hacmi ve saklama süresi büyüdükçe maliyeti artırabilir. Buna karşılık yalnızca daha yavaş bir depoya dayanmak, geri yükleme süresinin RTO hedefini aşmasına yol açabilir. Seçimi kapasite, toplam maliyet ve geri yükleme ölçümleriyle yapmak gerekir.

Katmanlı mimari ile:

• En kritik ve “hemen geri dönmem gereken” verinin son sürümlerini NVMe üzerinde tutarak RTO hedefini destekleyebilirsiniz; gerçek süreyi geri yükleme testiyle ölçmelisiniz.
• Daha az kritik veya daha eski yedekleri SATA tabanlı depoda daha uzun süre tutmayı, kapasite ve toplam maliyete göre değerlendirebilirsiniz.
• Yasal veya kurumsal gereksinimler için gereken uzun süreli arşivleri Object Storage üzerinde, desteklenen lifecycle politikalarını ve erişim/aktarım ücretlerini dikkate alarak yönetebilirsiniz.

Riskleri Ayrıştırmak

Farklı depolama katmanları, bağımsız hata alanlarına yerleştirildiklerinde birlikte kayıp riskini azaltır. Canlı veriyle tüm yedekleri tek NVMe diskte tutmak, disk arızasında hepsini kaybetme riski yaratır. Örneğin:

• Canlı veri NVMe’de,
• Günlük tam yedekler SATA tabanlı yedek sunucuda,
• Haftalık/aylık arşivler Object Storage üzerinde başka bir lokasyonda

olduğunda, tek bir disk veya sunucu arızasının tüm kopyaları etkileme riskini azaltırsınız. Ortak erişim hesapları, yönetim sistemi ve lokasyon gibi bağımlılıklar da ayrıca ayrıştırılmalıdır.

Örnek Bir Sıcak–Soğuk–Arşiv Mimarisi

Varsayımsal bir mimari üzerinden ilerleyelim. Senaryomuz şöyle olsun:

• Bir adet NVMe VPS üzerinde çalışan WooCommerce + blog (WordPress).
• Ayrı bir VPS’te çalışan CRM/ERP (örneğin Odoo veya ERPNext).
• cPanel üzerinde barınan birkaç kurumsal web sitesi.

Bu yapıyı hem performanslı hem de güvenli şekilde yedeklemek için aşağıdaki katmanları tasarlıyoruz.

Sıcak Katman: NVMe Üzerinde Sık Alınan Yedekler

• Saatlik mantıksal veritabanı yedekleri: MySQL için mysqldump, PostgreSQL için pg_dump gibi ilgili motora uygun araçlarla. Aşağıdaki PITR örneklerinin temel yedek gereksinimi ayrıca karşılanmalıdır.
• Dosya sistemi snapshot’ları: Altyapı destekliyorsa LVM/ZFS veya hypervisor snapshot’ları. Snapshot almak tek başına uygulama tutarlılığını garanti etmez; veritabanının desteklediği yedekleme yöntemiyle dosya ve veritabanı durumunu uyumlu hale getirin.
• Kısa saklama süresi: 24 saat – 72 saat.

Buradaki amaç, son bir deploy hatası, yanlış SQL sorgusu, bir eklenti güncellemesi veya küçük çaplı veri bozulmasında veri kaybını birkaç saatle sınırlamayı hedefleyerek hızlıca geri dönebilmektir. Bunun gerçekleşmesi, hatadan önce alınmış kullanılabilir bir yedeğin saklama penceresinde bulunmasına bağlıdır.

Örneğin WooCommerce sipariş tablosunu yanlışlıkla sildiğinizi varsayalım. Kullanılabilir son yedek bir saat önce alınmışsa, son 24 saat yerine yaklaşık bir saatlik değişiklik kaybolabilir; bunun kabul edilebilirliği RPO hedefinize bağlıdır. Canlı mağazayı geri almadan önce mevcut veriyi koruyun ve yedekten sonra oluşan siparişlerle diğer değişikliklerin nasıl uzlaştırılacağını planlayın; tüm veritabanını geri almak bu değişiklikleri de geri alır. NVMe hızlı geri yüklemeye yardımcı olabilir, ancak süre veri hacmine ve geri yükleme sürecine bağlıdır.

Soğuk Katman: Ayrı Yedek VPS/Dedicated Üzerinde SATA Havuzu

• Her gece tam dosya ve veritabanı yedekleri.
• Gün içinde 3–4 saatte bir artımlı (incremental) yedekler.
• Saklama süresi: 14–30 gün.

Bu örnekte önce hazırlama, sonra yedekleme modeli kullanılır: Kaynak sunucuda veritabanı motoruna uygun, tutarlı yedek çıktıları ve bunlarla uyumlu uygulama dosyaları hazırlanır; işlemlerin başarıyla tamamlandığı doğrulanır. Yedek sunucusu bu tamamlanmış dosyaları rsync ile SSH üzerinden yerel hazırlama dizinine çeker. Ardından yedek sunucusunda çalışan restic veya Borg, bu yerel dizinden okuyarak ayrı bir yerel yedek deposunda tarihli geri dönüş noktaları oluşturur. Aktarım veya kaynak yedek hazırlama işlemi başarısızsa yeni nokta başarılı sayılmamalıdır; yedekleme sürerken hazırlama dosyaları değiştirilmemelidir.

Restic ve Borg’un uzak depo desteği, uzak kaynak dosyalarını doğrudan okuyabildikleri anlamına gelmez. Alternatif olarak yedekleme işlemi kaynak sunucuda çalıştırılıp desteklenen uzak depoya yazabilir veya kaynak dosya sistemi yedekleme işleminin çalıştığı makineye bağlanabilir; her modelde tutarlı kaynak hazırlama koşulu korunmalıdır. Çalışan veritabanının veri dizinini sıradan dosyalar gibi kopyalamayı tutarlı veritabanı yedeği saymayın.

Böylece NVMe üzerindeki sıcak snapshot’lar silinmiş olsa bile, saklama planına uygun 14–30 günlük geçmişi ayrı depoda koruyabilirsiniz. Ayrı bir VPS, tek başına ayrı bir fiziksel sunucu garantisi değildir; fiziksel ayrımı doğrulayın. rsync ile yalnızca güncel kopyayı eşitlemek geçmiş sürümleri korumaz; tarihli sürümleri yedek deposunun saklama mekanizmasıyla yönetin.

Bu yapıyı özellikle cPanel/VPS yedeklerinizin otomatikleştirilmesi için rclone, restic ve Cron ile otomatik yedek alma rehberimizde pratik komutlarla gösteriyoruz. Aynı mantığı SATA tabanlı yedek sunucusuna da uygulayabilirsiniz.

Arşiv Katmanı: S3 Uyumlu Object Storage

• Haftalık veya 15 günlük tam yedek arşivleri.
• Aylık veya üç aylık arşiv kopyaları; değiştirilemezlik (immutable) gerekiyorsa bunu destekleyen ve uygun yapılandırılmış depolama.
• Örnek saklama süresi: 6–24 ay; gerçek süre veri türü, saklama amacı, uygulanabilir mevzuat ve şirket politikasına göre belirlenir.

S3 uyumlu arşiv hedefi için, örneğin restic’in S3 arka ucunu kullanarak şifreli yedek deposu oluşturabilir ve aktarımı HTTPS ile koruyabilirsiniz. Depo parolasını/kurtarma anahtarını yalnızca yedeklenen sunucuda tutmayın; geri yükleme erişimini ayrıca güvenceye alın. Bu örnekte Borg 1.4, yerel veya SSH üzerinden erişilen yedek sunucusu katmanında kullanılır; doğrudan S3 desteği bakımından restic ile eşdeğer sayılmaz. Seçilen Object Storage hizmeti gerekli lifecycle kurallarını ve depolama sınıflarını destekliyorsa, bağımsız arşiv nesneleri için örneğin:

• İlk 30 gün sık erişime uygun sınıfta,
• 30–180 gün arası, erişim ve asgari saklama ücretleriyle birlikte daha ekonomikse “infrequent access” sınıfında,
• 180 günden sonra, saklama yükümlülüğü sürüyorsa arşiv sınıfında; süre dolduysa silinmiş

gibi bir politika kurgulayabilirsiniz. Geri çağırma sürelerini RTO hedefinizle karşılaştırın. Bu yaş kurallarını artımlı veya deduplikasyonlu bir yedek deposunun nesnelerine körlemesine uygulamayın: eski nesneler yeni geri dönüş noktaları için gerekli olabilir. Temizliği yedekleme aracının saklama mekanizmasıyla uyumlu planlayın.

Bu yaklaşımın maliyet tarafını optimize etmek için, tekrar hatırlatmakta fayda var: Object Storage maliyet optimizasyonu yazımızda lifecycle politikalarının gerçek senaryolarda nasıl kurgulanacağını örneklerle paylaştık.

Farklı İş Yükleri İçin Örnek Yedekleme Senaryoları

Her projenin RPO/RTO hedefi farklıdır. Aşağıdaki üç varsayımsal senaryoda sıcak–soğuk–arşiv mimarisini uyarlayalım. Veri hacimleri, hedefler ve saklama süreleri örnektir; kişisel veriler için süreleri saklama amacı ve uygulanabilir mevzuatla ayrıca gerekçelendirin.

Hedefleri arıza senaryosuna göre değerlendirin: Saatlik sıcak yedek, bulunduğu depolama kaybedilirse bir saatlik RPO sağlamaz. Uzak lokasyonda yalnızca haftalık veya aylık arşiv varsa, yerel kopyaların tamamının kaybında veri kaybı penceresi de buna göre büyür. Veri merkezi kaybında da dakikalar veya saatler düzeyinde RPO gerekiyorsa, gerekli tutarlı yedekleri ve varsa PITR günlüklerini o hedefe uygun sıklıkta uzak depoya aktarın. Uzak kopya sıklığını uzun vadeli arşiv saklama takviminden ayrı planlayın.

1) WordPress Blog ve Kurumsal Site

Tipik özellikler:

• İçerik güncellemeleri günlük veya haftalık.
• Veri hacmi nispeten düşük (10–20 GB).
• RTO hedefi birkaç saat kabul edilebilir.

Önerilen strateji:

• Sıcak: NVMe üzerinde günlük veritabanı dump’ı + 2–3 günlük saklama.
• Soğuk: SATA yedek sunucusunda her gece tam yedek + 30 günlük saklama.
• Arşiv: Object Storage üzerinde aylık tam yedek + 12 ay saklama.

WordPress özelinde otomatik yedekleme ve geri yükleme senaryolarını merak ediyorsanız, WordPress yedekleme stratejileri rehberimiz bu yapıyı daha ayrıntılı ele alıyor.

2) WooCommerce ve E‑Ticaret Siteleri

Burada iş daha kritik, çünkü sipariş ve ödeme verisi var.

• Veri sürekli güncelleniyor.
• Veri kaybına tolerans çok düşük (RPO dakikalar – 1 saat).
• RTO da mümkünse 1 saatten az olmalı.

Önerilen strateji:

• Sıcak: Örneğin 15–30 dakikada bir uygulama açısından tutarlı veritabanı yedeği ve 24–48 saat saklama. MySQL 8.4 ile daha sık geri dönüş noktaları hedefleniyorsa, uygun tam yedeğe ek olarak o yedeğin ardından gelen kesintisiz binary log zincirini arşivleyin. Tam yedek ve gerekli günlükleri canlı sunucudan bağımsız depoda birlikte koruyup hedef zamana geri dönüşü test edin. Replika tek başına bu geçmişi koruyan bir yedek değildir.
• Soğuk: Günlük tam yedekler + 4 saatte bir artımlı yedek; SATA yedek sunucuda 30–60 gün saklama.
• Arşiv: Haftalık tam yedekler, Object Storage üzerinde örneğin 12–24 ay saklama; bu süre ancak ilgili veri türü ve amaç için gerekçelendirilebiliyorsa seçilmelidir. Kişisel verilerin saklama sınırlarını ve uygulanabilir muhasebe yükümlülüklerini ayrı ayrı değerlendirin.

WooCommerce için kapasite planlama ve veritabanı tuning tarafını doğru yapmak, yedek geri yükleme sürelerinde de fark yaratır. Bunun için WooCommerce kapasite planlama rehberimize de göz atabilirsiniz.

3) SaaS Uygulamaları ve Çok Kiracılı Mimari

SaaS örneğimiz için şu koşulları varsayalım:

• Birden fazla müşteri (tenant) aynı veritabanında veya şemada.
• Veri hacmi yüksek, sürekli yazma var.
• Belirli veri türleri için uygulanabilir mevzuattan doğan saklama yükümlülükleri.

Önerilen strateji:

• Sıcak: Örneğin son 24–72 saat için point-in-time recovery (PITR). PostgreSQL 17’de uygun fiziksel temel yedek ile bu yedeğin başlangıcından hedef ana kadar kesintisiz WAL arşivi gerekir; pg_dump çıktısı WAL kurtarmasının temel yedeği değildir. MySQL 8.4’te uygun tam yedek ve onu izleyen eksiksiz binary log zinciri kullanılır. Gerekli yedek ve günlükleri bağımsız depoda koruyun, motor/sürüm uyumunu ve hedef zamana geri dönüşü doğrulayın. Replika hızlı devralma için ayrıca kullanılabilir; yanlış silmeleri de çoğaltabileceğinden geçmiş yedeğin yerini tutmaz.
• Soğuk: Günlük tam yedekler, ayrı VPS veya dedicated yedek sunucusunda 60–90 gün saklama.
• Arşiv: Haftalık/aylık tam yedekler, Object Storage üzerinde 1–5 yıl saklama (veri türü ve saklama amacı için gerekçelendirilebiliyorsa; müşteri sözleşmeleri ve uygulanabilir mevzuat birlikte değerlendirilerek).

SaaS modelinde müşteri verisi yedekleme ve saklama politikalarını daha önce SaaS uygulamaları için müşteri verisi yedekleme rehberimizde detaylandırmıştık. Orada da sıcak–soğuk–arşiv ayrımının SaaS dünyasında neleri kolaylaştırdığını görebilirsiniz.

Bu Stratejiyi Nasıl Kurabilirsiniz?

Bu örnek mimarinin kurulum adımlarını özetleyelim. Depolama türü, fiziksel ayrım ve uzak depolama desteği, seçilecek planların gereksinimleri olarak değerlendirilmelidir.

1) Canlı Ortam İçin NVMe VPS/Dedicated Tercihi

Canlı ortam ve sıcak yedekler için NVMe depolama bir tasarım seçeneğidir; katmanlı yedekleme kurmak için mevcut ortamı mutlaka taşımak gerekmez. VPS veya dedicated sunucu seçerken disk türünü, kapasiteyi ve I/O sınırlarını gereksinimlerinizle karşılaştırın. Canlı ortam:

• Web sunucusu (Nginx/Apache/LiteSpeed),
• Veritabanı (MySQL/MariaDB/PostgreSQL),
• Uygulama (WordPress, Laravel, Node.js vb.)

için, iş yükü disk I/O’suyla sınırlıysa NVMe’nin yüksek IOPS kapasitesinden faydalanabilir. Altyapı destekliyorsa kısa ömürlü snapshot’lar veya veritabanı dump’larıyla sıcak katmanı oluşturabilirsiniz. Aynı diskteki kopyalar disk arızasına karşı bağımsız koruma sağlamaz; ayrı katmanlara aktarım bu nedenle gereklidir.

2) Ayrı Yedekleme Sunucusu (SATA Tabanlı)

İkinci adımda, canlı ortamdan bağımsız depolamaya sahip bir VPS veya dedicated sunucuyu yedekleme sunucusu olarak konumlandırabilirsiniz. SATA SSD/HDD, kapasite ve geri yükleme hızı hedeflerine uyuyorsa değerlendirilebilir. Bu sunucu:

• Yukarıdaki hazırlama modelinde, kaynak sunucuda başarıyla tamamlanmış tutarlı veritabanı yedeklerini ve uyumlu uygulama dosyalarını rsync ile SSH üzerinden yerel hazırlama dizinine çeker. rclone kullanılacaksa kaynak erişiminin seçilen arka uçla desteklendiği doğrulanmalıdır.
• Sunucuda çalışan restic veya Borg, hazırlama dizinindeki yerel dosyaları ayrı yedek deposuna alır; bu araçlar burada doğrudan uzak kaynak dosyalarını çekmek için kullanılmaz.
• Günlük tam ve gün içi artımlı yedek planını, seçilen aracın çalışma ve saklama modeline göre uygular; gerekli geri dönüş noktalarını ve yedek zincirlerini korur.
• Güvenlik duvarı ve erişim politikalarıyla sadece yedekleme ve yetkili yönetim için gereken erişime açılır.

Yedek sunucusuna yönetim amaçlı SSH erişimini yalnızca yetkili yönetim IP’lerine açabilirsiniz. Güvenlik duvarında yedek aktarımı ve gerekli altyapı hizmetleri için bağlantılara izin verip gereksiz trafiği engelleyin. Root yetkisini yalnızca görev gereği ihtiyaç duyan yetkililere verin; ayrı yönetici hesaplarıyla erişimleri izlenebilir tutun.

3) S3 Uyumlu Object Storage’a Otomatik Yedek Aktarımı

Yedek sunucudan Object Storage’a otomatik aktarım planlarken, aracın seçilen depolama arka ucunu desteklemesi gerekir. Aktarım, şifreli yedekleme ve zamanlama için şu araçlar değerlendirilebilir:

• rclone: S3 başta olmak üzere birçok uzak depolama için son derece esnek.
• restic: Uyumlu S3 arka ucuna şifreli, deduplikasyonlu ve artımlı yedekleme için.
• Borg 1.4: Yerel veya SSH üzerinden erişilen depoda yedekleme için; bu sürümün burada kullanılan depo modeli doğrudan S3 aktarımıyla eş tutulmamalıdır.
• Cron: Zamanlama ve rutin işler için.

Örneğin her gece saat 02:00’de, bir önceki günün sıkıştırılmış ve şifrelenmiş yedeğini şu mantıkla Object Storage’a gönderebilirsiniz:

• Yedek sunucuda /backups klasöründe başarıyla tamamlanmış günlük arşivleri tut.
• Örneğin /backups/2024‑09‑01.tar.gz dosyasını istemci tarafında şifrele; .tar.gz sıkıştırması tek başına şifreleme değildir. rclone ile şifrelenmiş çıktıyı, yapılandırılmış S3 uzak hedefindeki seçili bucket’ın 2024/09/ önekine yükle. Tarih ve yollar temsilidir; gerçek uzak hedef adı, bucket ve erişim bilgileri yapılandırmana uygun olmalıdır.
• Object Storage hizmeti uygun depolama katmanlarını ve lifecycle geçişlerini destekliyorsa, 30 günden eski bağımsız arşiv nesnelerini daha ucuz katmana taşı; geçiş, asgari saklama ve geri çağırma maliyetlerini de hesaba kat.

4) Felaket Kurtarma Provası ve Geri Dönüş Testleri

Yedeğin geri yüklemesi test edilmemişse, kurtarma sırasında kullanılabilirliği doğrulanmış değildir. Bu yüzden önerilen yaklaşım şu:

• Aylık veya üç aylık periyotlarla, yedeklerden test geri yükleme yapılması.
• Üretimden izole bir test VPS’i üzerinde, ilgili yedeğin açılıp uygulamanın ayaklanması.
• Geri dönüş süresinin ölçülmesi ve hedeflenen kurtarma süresiyle (RTO) karşılaştırılması.

Bu süreci adım adım nasıl yöneteceğinizi, hosting tarafında felaket kurtarma provası rehberimizde örnek senaryolarla anlatıyoruz. Tavsiyemiz: En azından yılda birkaç kez bu provayı gerçekten uygulamanız.

Sık Yapılan Hatalar ve İyileştirme Önerileri

Tüm Yedekleri Aynı Diskte Tutmak

En büyük hatalardan biri, “zaten NVMe çok hızlı” deyip hem canlı veriyi hem de tüm yedekleri aynı disklerde saklamak. Bu durumda:

• Disk arızasında hem canlı veri hem yedekler aynı anda kaybedilebilir.
• Ransomware, erişip değiştirebildiği yedek kopyalarını da şifreleyebilir.

Çözüm: En azından soğuk katmanı fiziksel olarak ayrı bir yedek sunucuya taşımak, arşiv katmanını ise ayrı bir lokasyondaki Object Storage’ta konumlandırmak. Fiziksel ayrımın yanında, canlı ortamın ele geçirilen erişim bilgileriyle tüm yedeklerin değiştirilememesi veya silinememesi için yedek erişim yetkilerini de ayırmak gerekir.

Yedek Alıp Geri Dönüş Senaryosunu Tanımlamamak

“Yedek alıyoruz” cümlesi ancak “şu kadar dakikada şu şekilde geri dönüyoruz” diye tamamlandığında anlamlı olur. Özellikle e‑ticaret ve SaaS tarafında:

• Hangi tablo veya dizin bozulduğunda hangi yedekten dönüleceğini,
• DNS/SSL, uygulama konfigürasyonu ve IP taşınması gibi adımların sırasını,
• Kimlerin hangi rolde devreye girdiğini

önceden yazmak gerekir. Buna basit bir DR runbook diyebilirsiniz.

KVKK/GDPR Saklama Sürelerini Göz Ardı Etmek

“Ne kadar çok yedek, o kadar iyi” yaklaşımı, kişisel verilerin saklanması için tek başına yeterli gerekçe değildir. KVKK/GDPR kapsamındaki verilerde saklama amacını, hukuki dayanağı ve gerekli süreyi belirlemek gerekir. Özellikle:

• Kişisel verilerin tutulduğu loglar,
• E‑posta arşivleri,
• Eski müşteri verileri

için saklama süresini politika olarak tanımlamak önemlidir. Hizmet destekliyorsa Object Storage lifecycle kuralları bu politikayı uygulamaya yardımcı olabilir; ancak tek başına mevzuata uyum sağlamaz. Kuralları yedekleme aracının saklama ve temizleme mekanizmasıyla uyumlu kurun; gerekli tam/artımlı yedekleri veya ortak kullanılan nesneleri silerek geri dönüş noktalarını bozmayın. Bu konuya özel olarak yedek saklama süresi ve KVKK/GDPR dengesini anlattığımız rehberde değindik.

Yedek Transferi ve Şifrelemeyi İhmal Etmek

Yedek, canlı verinizle aynı hassasiyettedir. Daha az izlenmesi, olası bir ihlalin fark edilmesini de geciktirebilir. Bu nedenle:

• Sunucular arası taşıma mutlaka SSH/TLS üzerinden şifreli yapılmalı.
• Object Storage’a yüklenen arşivler istemci tarafında ek olarak şifrelenmeli (seçilen depolama hedefiyle uyumlu bir şifreleme yöntemi kullanılarak). Şifre çözme anahtarları yedekten ayrı, güvenli ve kurtarma sırasında erişilebilir biçimde saklanmalı.
• Yedek sunuculara erişim sıkı firewall ve VPN/SFTP politikalarıyla sınırlandırılmalı.

Özet ve Sonraki Adım: Yedeklerinizin Katmanlarını Netleştirin

Sıcak, soğuk ve arşiv yedek kavramlarını doğru yerleştirdiğinizde, “yedek var mı?” sorusu yerini çok daha olgun bir soruya bırakır: “Hangi yedeğe, kaç dakikada, ne kadarlık veri kaybıyla dönebiliyoruz ve bu bize kaça mal oluyor?”. Günlük yedekleme sıklığının yeterliliği, kabul edilebilir veri kaybına ve kurtarma süresine bağlıdır. Katmanlı bir NVMe + SATA + Object Storage stratejisi, bağımsız kopyalar ve geri yükleme testleriyle desteklendiğinde bu hedeflere ulaşmaya yardımcı olabilir; maliyetler saklama süresine, veri hacmine ve geri çağırma ihtiyacına göre değerlendirilmelidir.

Bir sonraki adımınız çok karmaşık olmak zorunda değil. Önce mevcut durumunuzu çıkarın: Canlı veriniz hangi diskte? Kaç günde bir tam yedek alıyorsunuz? Offsite kopyanız var mı? Son ne zaman gerçek bir geri yükleme testi yaptınız? Bu cevapları, kabul edilebilir veri kaybı ve kurtarma süresi hedeflerinizle birlikte değerlendirerek eksik katmanları belirleyin. Ardından NVMe tabanlı canlı ortam, SATA yedek sunucu ve S3 uyumlu Object Storage üçlüsünü bir tasarım seçeneği olarak ele alın; seçilecek hizmetlerin disk, kapasite, lokasyon ve erişim özelliklerinin bu tasarıma uygunluğunu doğrulayın.

Planı uygulanabilir hale getirmek için ekibinizle her katmanın saklama süresini, erişim yetkilerini, sorumlusunu ve geri yükleme adımlarını belgeleyin. Maliyet ve kurtarma süresi hedeflerinin karşılanıp karşılanmadığını, mimariyi devreye aldıktan sonra izole geri yükleme provalarıyla ölçün.