Sunucu Yedekleme Stratejileri: 3-2-1 Kuralı ile Net Plan

Sunucu yedekleme, “dosyaları bir yere kopyalayalım” işinden ibaret değildir. Bir felaket anında (yanlış silme, veri bozulması, depolama arızası, fidye yazılımı) hangi yedeğin işe yarayacağını önceden netleştirmeniz gerekir. Bu yazıda 3-2-1 kuralını (3 kopya, 2 farklı ortam, 1 kopya dışarıda) VDS/VPS ve web uygulamaları için uygulanabilir bir stratejiye dönüştüreceksiniz. Ayrıca hangi yedek türlerinin (tam, artımlı, anlık görüntü) ne zaman seçileceğini, şifrelemeyi ve yedeği gerçekten doğrulamanın yollarını göreceksiniz.

3-2-1 kuralı neyi çözer, neyi çözmez?

3-2-1 kuralı basit bir tasarım yaklaşımıdır: - 3 kopya: Tek bir kaynağın tek bir arızası tüm veri kaybına yol açmaz. - 2 farklı ortam: Örneğin bir kopyayı aynı sağlayıcıdaki farklı disk alanında tutmak yerine, biri yerel diğeri harici olur. - 1 kopya dışarıda: Üretim sunucusu ve aynı altyapıdan bağımsız bir yerde tutulur.

Bu kurala yaklaşmak, en yaygın senaryolarda koruma sağlar: - Ransomware (fidye yazılımı): Saldırgan üretim diskine erişip veriyi şifrelerse, şifrelenmemiş yedeğin dışarıda olması kurtarır. - Hatalı yönetim aksiyonu: Yanlış drop/rsync komutu, yanlış migrasyon veya silme sonrası eski hal geri alınabilir. - Depolama arızası / disk bozulması: Yedek olmadan “diskten kurtaralım” çoğu zaman maliyetli ve risklidir.

Ancak kuralın “tek başına” yeterli olduğu varsayımı yanlıştır. Çünkü yedeklerin: - güncelliği (RPO/RTO), - doğruluğu (bozulmuş yedeği geri dönmek), - erişim güvenliği (yedek anahtarları), - geri dönüş testi (restore edilebilirlik)

olmadığında yedek, kağıt üzerinde var ama pratikte işe yaramaz.

RPO ve RTO’yu netleştirmeden 3-2-1 uygulamak eksik kalır

Yedek stratejisi tasarımında iki hedefi belirleyin: - RPO (Recovery Point Objective): Son geri dönüş noktasına kadar kaybedilebilecek veri miktarı. Örneğin “en fazla 15 dakika”. - RTO (Recovery Time Objective): Sistem geri kurulana kadar geçecek süre. Örneğin “en fazla 2 saat”.

Bu hedefler, hangi sıklıkla tam/artımlı yedek alınacağını ve anlık görüntü (snapshot) kullanımını belirler.

VDS/VPS ortamında 3 kopyayı nasıl kurmalısınız?

VDS/VPS kullanan çoğu senaryoda üretim verisi genelde şu parçalardan oluşur: - web uygulaması kodu (repo veya dosya sistemi), - veritabanı (MySQL/PostgreSQL vb.), - yapılandırmalar (nginx/Apache, environment, kontrol panel ayarları), - sistem seviyesinde ayarlar (cron, kullanıcılar, anahtarlar), - özel veriler (upload’lar, kullanıcı dosyaları).

3-2-1’i kurarken her kopya aynı formatta olmak zorunda değildir. Önemli olan geri dönüşte hangi bileşenin eksiksiz ayağa kaldırılabildiğidir.

Kopya örnekleri (net ve uygulanabilir)

Aşağıdaki tablo, sık görülen bir VDS kurulumunda kopyaların “nerede” duracağını örnekler:

Kopya	Neyi tutar?	Ortam	Saklama amacı
1 (Yerel)	Veritabanı + dosyalar + konfig	Aynı VDS üzerindeki ikinci disk / lokal depolama	Hızlı geri dönüş (düşük RTO)
2 (Sağlayıcı içinde farklı)	Snapshot ya da ayrı depolama alanında yedek	Sağlayıcının farklı fiziksel/izole alanı	Disk arızası veya silme sonrası orta hız
3 (Dışarıda)	Şifreli arşiv ya da bulut objesi	Başka bölge/başka sağlayıcı (örn. S3/R2 uyumlu)	Felaket senaryolarında bağımsızlık

Not: “2 farklı ortam” kuralını sadece “aynı bulut hesabındaki iki klasör” gibi düşünmeyin. Aynı fiziksel altyapı ve aynı erişim anahtarlarıyla korunuyorsa dışarıda bağımsızlık zayıflar.

Tam yedek mi artımlı mı? Net seçim rehberi

Aşağıdaki karar çerçevesiyle gereksiz masrafı azaltırsınız: - Tam yedek (full backup): Dönüşün temiz başlamasını sağlar. Günlük/haftalık daha uygun olur. - Artımlı yedek (incremental): Değişen veriyi alır; maliyeti düşürür. Gün içinde periyodik uygundur. - Anlık görüntü (snapshot): Veritabanı için “tek seferde tutarlılık” sağlanır (uygun yöntemle). Ancak yönetim ve restore akışı dikkat ister.

Pratik bir plan örneği (hedeflerinizle uyarlayın): - Saatlik artımlı yedek + günlük tam yedek - Snapshot’ları veritabanı tutarlılığı için uygun şekilde almak - Dışarıdaki kopyayı günlük/haftalık periyotla günlemek (RPO hedefinize göre)

Yedek türlerini doğru eşleştirin: kod, dosya, veri tabanı

Yedek stratejisinde en sık yapılan hata, sadece “/var/www” gibi dosyaları kopyalamaktır. Uygulamalar genelde veritabanı ve yapılandırmalarla birlikte restore edilmelidir.

Dosya sistemi yedeği (upload’lar ve varlıklar)

Hangi dizinler kritik? Örneğin uploads/, storage/, public/ içindeki kullanıcı kaynakları.
Dosya izinleri ve sahiplikleri (permissions/ownership) restore sırasında korunmalı.
Büyük dosyalarda kademeli yöntemler veya sıkıştırma planı yapılmalı.

Veritabanı yedeği (MySQL/PostgreSQL)

Veritabanı için hedefiniz “tutarlı restore” olmalı. Bunun için iki yol vardır: - Mantıksal yedek: mysqldump benzeri (uygulama uyumluluğu iyi, ama büyük veride süre uzar). - Fiziksel/tutarlı yedek: Snapshot veya base + binlog (daha karmaşık ama daha düşük RPO sağlayabilir).

Net kural: Veritabanı yedeğini alırken uygulama yazma trafiğini doğru yönetmeden “rastgele dosya kopyalama” yapmayın. Aksi halde yedek geri dönüşte bozulabilir.

Konfigürasyon yedeği (infra değil, sistemin hafızası)

Aşağıdakiler restore senaryosunda kritik rol oynar: - web sunucusu konfigleri (nginx/Apache), - uygulama env dosyaları ve secret’lar (şifreli şekilde), - crontab ve sistem zamanlayıcıları, - kullanıcı/anahtar listeleri, - log rotasyon (opsiyonel ama sorun tespiti kolaylaşır).

Bu parçalar olmadan uygulama kodu geri gelse bile sistem tam çalışmayabilir.

Yedeklemeyi şifreleyin: “dışarıya çıktı” tek başına yetmez

Dışarıda tutmak güvenliği artırır; fakat yedekler çalınırsa/erişimi ele geçirilirse risk devam eder. Bu yüzden şifreleme şarttır.

Şifreleme için net yaklaşım

Yedek arşivini yedekleme işlemi sırasında şifreleyin.
Şifreleme anahtarını (key) üretim sunucusundan bağımsız saklayın.
Bulut depolamada (S3/R2 uyumlu) sunucu tarafı şifreleme (server-side encryption) tek başına düşünülmemelidir; mümkünse istemci tarafı (client-side) şifreleme kullanın.

Aşağıdaki durumlarda şifreleme “zorunlu” seviyeye çıkar: - Yedekleri başka sağlayıcıya kopyalıyorsanız. - Yedekleri uzun süre saklıyorsanız. - İnsan hatasıyla yanlış erişim paylaşımı ihtimali varsa.

3-2-1’i tamamlayan en kritik adım: geri dönüş testi

Bir yedeğin doğru olup olmadığını, yedek dosyasını oluşturduktan sonra restore ederek anlarsınız. “Restore testini haftada bir yapıyoruz” söylemi tek başına yeterli değildir; testin kapsamı net olmalıdır.

Restore testi nasıl yapılmalı? (minimum seviye)

En azından şu testleri uygulayın: 1. Dosya geri dönüş testi: Yedekten bir kullanıcı upload’ı veya statik varlık geri getirildi mi? 2. Veritabanı geri dönüş testi: Yedekten restore edilen DB, uygulamanın beklediği şemayla uyumlu mu? 3. Uygulama başlatma testi: Restore sonrası uygulama ayağa kalkıyor mu (migrations dahil)?

Test sıklığı

Büyük değişikliklerden sonra: yeni sürüm, veritabanı şeması değişimi, kontrol panel değişimi
Düzenli: en az aylık “tam restore” veya çekirdek bileşen restore testi

Net hedef: Aynı hatayı bir daha yaşayabilmek yerine, restore adımlarındaki eksikliği testle erken yakalayın.

“Ne kadar saklayalım?” sorusunu saklama penceresiyle netleştirin

Saklama süresi, maliyeti ve geri dönüş senaryolarını etkiler.

Net bir yaklaşım: - Son 24-72 saat: yüksek frekanslı yedekler (saatlik/artımlı) - Son 30 gün: günlük tam + artımlı - Daha eski dönem: haftalık/aylık arşiv (gerektiğinde sürüm bazlı geri dönüş)

Buna göre dış kopyayı (kopya 3) günlük yerine haftalık güncellemek bütçeyi düşürür; ama RPO hedefini kaçırmamalıdır.

Yaygın hatalar ve net düzeltmeler

Aşağıdaki maddeler, 3-2-1’i bozan ama genelde “iyi niyetle” yapılan uygulamalardır.

1) Aynı sunucudan silinince yedek de siliniyor

Yapmamanız gereken: Yedek klasörünü aynı sistemde tutup yetkileri/replication kurallarını doğru ayırmamak.
Net düzeltme: Dış kopya için farklı sağlayıcı/bölge; içeride ise yetki ayrımı ve farklı depolama alanı.

2) Şifreleme yapılmadan dışarıya kopyalama

Net düzeltme: Şifreli arşiv, anahtarların bağımsız saklanması.

3) “Yedek aldık” ama restore yok

Net düzeltme: Aylık restore testi + büyük değişiklik sonrası ek test.

4) Veritabanını tutarlı almamak

Net düzeltme: Uygun yöntemle tutarlılık (snapshot mantığı veya DB-native backup yaklaşımı).

5) Yedeklerin boyutu kontrol edilmemesi

Net düzeltme: Saklama penceresi + sıkıştırma + artımlı mantık. Ayrıca yedek depolama kotasını izleyin.

Sonuç: 3-2-1 ile bugün net bir yedek planı çıkarın

Bugün yapmanız gereken en net aksiyon, 3-2-1 kuralını soyuttan somuta çevirmektir: 3 kopya oluşturun (yerel + izole/ayrı ortam + dışarıda), kopya 3’ü şifreli saklayın ve her yedek türü için en az bir kez restore testi yapın. Önce RPO/RTO hedeflerinizi yazın, ardından dosya + veritabanı + konfigün birlikte geri dönüp dönmediğini doğrulayın. Bu adımları kurduğunuzda yedekleme, beklenmedik bir arızada sizi “tahminle kurtarmaya” değil, planla geri dönmeye yönlendirir.