Otomatik Yedeklemeyi Dış Depolamaya Gönderme: Net Plan

Sunucuda veri kaybı senaryosu; donanım arızası, yanlış silme, fidye (ransomware) ve hatta sağlayıcı kaynaklı kesintilerle gelir. Bu nedenle yedekleme yalnızca "alınacak" bir iş değil; dış depolamaya güvenli şekilde gönderilecek ve düzenli olarak test edilecek bir sistem olmalıdır. Bu yazıda, otomatik yedekleri (backup) dışarıya aktarırken hangi bileşenlerin kritik olduğunu, hangi ayarlarla riskin azaltıldığını ve hangi kontrol adımlarıyla yedeklerin gerçekten işe yaradığını öğreneceksiniz.

Dış depolama neyi çözer? İç yedekten farkı

İç depolama (aynı sunucu üzerindeki disk veya aynı storage havuzu) çoğu zaman hızlıdır; ancak tek bir arıza alanına takılır. Örneğin: - Sunucu diskleri bozulursa hem ana veri hem de yedek zarar görür. - Fidye yazılımı, aynı sunucuda çalışan yedekleme dizinlerini de şifreleyebilir. - Yanlış bir süreç, hem canlı veriyi hem de yedekleri silebilir.

Dış depolama, bu tek arıza alanını kırar. Burada "dış" şu anlama gelir: - Yedek dosyaları, canlı sistemin olduğu aynı sunucuda/aynı erişim anahtarlarında tutulmaz. - Mümkünse farklı bir güvenlik sınırı ve farklı bir fiziksel/lojik konum kullanılır. - Yedek erişimi için kullanılan kimlik bilgileri (credential) sınırlı ve izole olur.

3-2-1 kuralı: Otomatik dış yedek için net hedef

Dış depolamaya otomatik gönderim, tek başına yeterli değildir; yedeklerin gerçekten geri yüklenebilir olması gerekir. Bu hedefi 3-2-1 kuralıyla çerçevelerseniz net bir plan çıkar:

• 3 kopya: Canlı veri + en az 2 yedek
• 2 farklı medya türü: Örn. yerel disk + nesne depolama (object storage)
• 1 kopya off-site: İnternetten erişilen farklı konum (dış depolama)

Aşağıdaki senaryo pratikte iyi çalışır: - Günlük yerel snapshot/backup (hız için) - Haftalık veya günlük dış depolama (off-site kopya) - Ayda bir restore testi (gerçek geri yükleme doğrulaması)

Restore testi olmadan "otomatik yedek" ne ifade eder?

Dış depolamaya dosya atmak, yedek işe yarıyor demek değildir. Aşağıdaki kontrolleri mutlaka planınıza dahil edin: - Yedek dosyası büyüklüğü (0 KB veya aşırı küçük olmamalı) - Arşivin bütünlüğü (checksum/restore sonrası doğrulama) - Uygulama seviyesinde doğrulama (DB restore edilebiliyor mu, WordPress dosya yapısı doğru mu)

Hangi dış depolama türleri kullanılır? Net karşılaştırma

Dış depolama derken tek seçenek yok. İşin kritik noktası; erişim modeli, şifreleme ve maliyetin birlikte düşünülmesidir.

Bu yazıda amaç, hangi altyapı olursa olsun otomatik yedek + dışa transfer + şifreleme + doğrulama bileşenlerini kurmaktır.

Güvenli aktarım ve saklama: Şifreleme + erişim izolasyonu

Dış depoya veri taşırken iki katman düşünün: 1) Aktarım sırasında güvenlik (in transit) 2) Dosya üzerinde güvenlik (at rest)

Aktarım için net gereksinimler

• API erişimi yapan aracın TLS kullanması şarttır (örn. HTTPS/S3 endpoint üzerinden).
• Kimlik bilgileri için sunucuda düz metin parola tutmayın; mümkünse erişim anahtarlarını (access key) sınırlı izinle kullanın.
• Erişimi en az yetkiyle verin: yalnızca belirli bucket/klasöre yazma/okuma.

Saklama için net gereksinimler

• Şifrelemeyi mümkünse yedek üretiminden önce uygulayın (client-side encryption). Böylece dış depolama tarafı dosyayı okunabilir formatta görmez.
• Anahtar yönetimi: Şifreleme anahtarı (encryption key) yedekle birlikte saklanmamalıdır. Anahtar ayrı bir güvenlik alanında tutulmalıdır.

Otomatik süreç tasarımı: Zamanlama, rotasyon ve bant genişliği

Otomasyonun başarısı; "her gün yedek al" değil, ne zaman, ne kadar, ne kadar süre tut sorularına net cevap vermektir.

Zamanlama

• Yedekleme işi yoğun saatlerde çalıştırmayın.
• Bant genişliği planı için gerçek transfer boyutunu takip edin. Örneğin günlük 200 GB yedek 1 GB/saat gibi değilse, aktarım süresi gecikme yaratır.

Rotasyon (retention)

Dış depoda disk maliyetini kontrol etmek için net bir retention tanımlayın: - Öneri: 7 günlük günlük, 4 haftalık haftalık, 6 aylık aylık (örnek) - Log ve kontrol dosyaları ayrıca saklansın; "yedek başarılı" durumu kanıtlanabilir olsun.

Band genişliği ve pencere (window)

Aşağıdaki kontrol pratikte iş görür: - Son 7 günde ortalama yedek boyutunu ölçün. - Dışa aktarım hızını (MB/s) ölçün. - Toplam süreyi CPU/IO yükü ile çakıştırmayın.

Uygulama seviyesine göre yedek yöntemi: DB + dosyalar ayrı düşünülür

Otomatik yedek planı kurarken hangi verinin nasıl geri yükleneceğini önceden belirleyin.

WordPress senaryosu (örnek şablon)

WordPress için pratik ayrım: - Dosyalar: /wp-content (temalar, eklentiler, yüklenen medya) ve gerekiyorsa core dosyaları - Veritabanı: MySQL/MariaDB dump (DB dump) - Konfigürasyon: wp-config.php (veritabanı bağlantısı, bazı ayarlar)

Dış depoya gönderirken en net yaklaşım: - DB dump dosyasını tek bir arşive dahil etmek veya ayrı dosya olarak dışa koymak - wp-content/uploads ve eklenti/tema dosyalarını arşivleyip şifrelemek

Node.js / statik uygulamalar

• Kaynak kodu Git’ten çekiliyorsa, dış depoya ihtiyaç daha çok veritabanı ve upload dizinleri seviyesindedir.
• Uygulama logları dışa otomatik gönderilecekse ayrı bir kategori olarak ele alın (retention farklı olmalı).

Otomatik dış depolama aktarımı için adım adım kontrol listesi

Aşağıdaki listeyi uyguladığınızda süreç daha güvenilir ve izlenebilir olur.

1) Yedek kapsamını netleştirin

• Hangi dizinler? Hangi veri tabanları?
• Yedeklenmeyecek gereksiz klasörler var mı? (örn. cache dizinleri)

2) Şifreleme tasarımını kurun

• Şifreleme nerede yapılacak? (client-side önerilir)
• Şifreleme anahtarını nerede saklayacaksınız?

3) Dış depoya erişim yetkilerini daraltın

• Sadece yazma izinleriyle başlayın; ihtiyaç olursa okuma ekleyin.
• Erişim anahtarını sadece yedekleme servis hesabında kullanın.

4) Aktarımı bant genişliği kısıtıyla yönetin

• Yedekleme aracında hız limit (throttle) kullanın.
• Transfer penceresini belirleyin.

5) Rotasyon ve silme politikası ekleyin

• Dış depoda eski yedekleri otomatik silin.
• Silme kuralını, test restore planınızla çeliştirmeyin.

6) Başarı/başarısızlık loglarını izleyin

• Her çalışmada “başarılı mı” çıktısını saklayın.
• Her yedek denemesi için bir özet dosyası tutun: boyut, checksum, zaman.

Net bir “başarılı yedek” doğrulaması nasıl yapılır?

Aşağıdaki doğrulama adımları, yedeklerin işe yarayıp yaramadığını ölçer.

Pratik restore testi (aylık)

• Dış depodan rastgele bir yedek alın.
• Test ortamında geri yükleyin.
• Uygulama/DB doğrulaması yapın: bağlantı, tablo sayısı, dosya bütünlüğü.

En az 2 seviye kontrol

• Dosya seviyesi: arşiv açılabiliyor mu?
• Sistem seviyesi: uygulama çalışıyor mu?

Maliyet hesabı: Dış depolama masrafını sürpriz olmaktan çıkarın

Dış depolama maliyetini kontrol etmenin net yolu; 3 parametreyi hesaplamaktır: 1) Günlük yedek boyutu (GB/gün) 2) Ortalama tutulan gün sayısı (retention etkisi) 3) Saklama + istenen çıktı maliyeti (varsa egress)

Örnek hesap mantığı: - Günlük 200 GB - 7 gün günlük + 4 hafta haftalık + 6 ay aylık gibi bir plan - Bu durumda dış depoda ortalama tutulan toplam GB’yi tahmini olarak toplayın - Depolama sınıfı ve silme maliyeti/planı ile birlikte değerlendirin

Not: Sağlayıcılar arasında “silme sonrası faturalama” ve “sınıf” farkları olabilir. Karar öncesi kendi kullanım profilinizle test edin.

Sık yapılan hatalar: Dış depolama kuruldu sanılması

• Yalnızca dosya gönderilip restore testinin yapılmaması: Gerçekte arşiv bozuk çıkabilir.
• Şifrelemenin sadece aktarımda kalması: Dış depoda dosya okunabilir kalır.
• Geniş yetkili erişim anahtarları: Her bucket üzerinde sınırsız yetki gereksiz risktir.
• Retentiton planının eksik olması: Maliyet birikir veya kritik yedekler çok erken silinir.

Sonuç: Bugün kurulumu tamamlamak için aksiyon planı

Otomatik yedeklemeyi dış depolamaya göndermek, 4 net bileşenle sağlamlaşır: şifreli aktarım + dışta saklama + rotasyon + restore testi. Hemen bugün atılacak en iyi adım; yedek kapsamını netleştirip (dosyalar + DB), dış depolama için erişim yetkilerini daraltıp, retention kuralını yazılı hale getirmektir. Ardından ilk çalıştırmayı 1-2 gün içinde yapın ve aynı yedekten doğrulama için restore testini takvime alın. Bu sırayla ilerlediğinizde, yedek sistemi “dosya üreten” değil, gerçekten geri yüklenebilen bir altyapı olur.