Otomatik Yedeklemeyi Dış Depolamaya Gönderme Rehberi

Bir sunucuda veya web uygulamasında yedek (backup) almak tek başına yeterli değildir. Asıl kritik nokta, hatalı güncelleme, kötü amaçlı yazılım, donanım arızası veya veri merkezindeki kayıp senaryolarında yedeğin orijinal sistemden bağımsız kalmasıdır. Bu rehberde, otomatik yedeklemenin çıktısını dış depolamaya (örn. S3 uyumlu obje depolama) nasıl güvenli ve düzenli aktaracağınızı; ayrıca doğrulama, şifreleme ve erişim denetimini adım adım öğreneceksiniz. Hedefimiz, “yedek var mı?” sorusunu düzenli testlerle “yedek gerçekten kurtarır mı?” seviyesine taşımak.

Dış depolama neden şart: İçeride kalanın riski

Yedek dosyalarını sunucu üzerinde tutmak, yedekleme amacını zayıflatır. Şu senaryolarda iç depolama yetersiz kalır: - Sunucu dosya sisteminin bozulması (fsck ile kurtarma bile otomasyonun beklediği formatı bozabilir). - Kripto-trojan/şifreleyici (ransomware) ile hem uygulama hem de yedeklerin aynı erişim yetkileriyle etkilenmesi. - Yanlış silme veya kötü yapılandırma (ör. rsync/cron hatası). - Veri merkezinin büyük kesintisi: iç disk/RAID sorunlarında kurtarma gecikebilir.

Dış depolama (external storage) iki şeyi aynı anda sağlar: - Bağımsızlık: Yedek, üretim sistemiyle aynı arıza alanında olmaz. - Saklama ve maliyet kontrolü: Yaş (retention) ve sınıf (tier) stratejisi kurarsınız.

Pratik hedef: Üretim sunucusu erişilemez olsa bile yedeğiniz erişilebilir durumda olmalı ve kurtarmayı taklit edebilecek şekilde test edilmelidir.

Doğru mimariyi seçin: Tam yedek mi, artımlı mı, veritabanı mı?

Dış depolamaya göndereceğiniz şey, kullandığınız bileşene göre değişir. En sık üç model:

1) Dosya tabanlı (file-level) yedek

• Uygun: statik dosyalar, kullanıcı yükleri, bazı CMS kurulumları.
• Tipik yaklaşım: arşiv al (tar), sonra objeye yükle.
• Artımlı senaryo: değişen dosyaları incremental almak gerekir; basit kurulumlarda tam yedek daha sorunsuzdur.

2) Veritabanı (DB) yedek

• Uygun: MySQL/MariaDB, PostgreSQL, MongoDB.
• Tipik yaklaşım: native dump (örn. mysqldump, pg_dump) al, sonra dış depoya yükle.
• Önemli: büyük DB’lerde dump süresi ve kilitleme (lock) etkisini hesaba katın.

3) Uygulama/özel kurulum yedeği

• Uygun: Docker stack, özel yedekleme araçları, managed bileşenler.
• Tipik yaklaşım: uygulama seviyesinde export/import, sonra dış depoya kopya.

Aşağıdaki tablo seçimde hız sağlar:

Dış depolama hedefi: S3 uyumlu obje depolama nasıl seçilir?

S3 uyumlu çözümler (örn. S3, bazı R2/B2 benzerleri veya S3-compatible storage) dışa aktarıma uygundur. Seçerken şu kriterleri netleştirin: - Erişim yöntemi: S3 API (HTTP) üzerinden PUT/GET ile aktarım. - Şifreleme desteği: Depoda sunucu tarafı şifreleme (server-side encryption) ve/veya istemci tarafı şifreleme (client-side). - Saklama (retention) yönetimi: Gün, ay bazlı tutma. - Versiyonlama (versioning): Yanlışlıkla bozma/silme riskine karşı.

Şifreleme stratejisi: İki katmanlı yaklaşım

Güvenlik için iki katman hedefleyin: 1) Dosyayı dışarı göndermeden önce şifreleyin (client-side). Bu, anahtarlar sizdeyken sağlayıcı tarafında verinin okunamaz olmasını sağlar. 2) İsteğe bağlı olarak sağlayıcı tarafında da şifreleme açın.

En pratik karar: müşteri tarafı şifreleme ile veri taşınırken de korunur; dış depodaki “erişim anahtarı ele geçirilirse” bile içeriğin okunmasını zorlaştırır.

Erişim anahtarı: Parola değil anahtar (access key) ve minimum yetki

Dış depoya erişimde tek bir “her şey yetkili” kullanmayın. İdeal kurulum: - Sadece gerekli bucket/namespace için PutObject, GetObject ve gerekirse ListBucket yetkisi. - Yalnızca yazma (upload) gerekiyorsa PutObject ağırlıklı yetki. - Anahtarları sistemde düz metin tutmayın.

Otomatik aktarım: Cron + güvenilir sıra (queue) mantığı

Otomatik yedeklemeyi dış depoya yollama tipik olarak üç adımdan oluşur: 1) Yerelde yedeği üret (dump/arşiv) 2) Sıkıştır + şifrele 3) Dış depoya yükle, ardından yerel geçici dosyayı temizle

Zamanlama (cron) ve çakışma engeli

Özellikle veritabanı dump’larında süre değişir. Aynı anda iki yedek çalışırsa dosya bozulabilir veya yükleme yarışa girer. Çakışmayı engellemek için kilit (lock) mantığı kullanın.

Örnek komut akışı (mantık düzeyi)

Aşağıdaki pseudo-akış, komutları çoğaltmadan mantığı verir: - Yedek üret: backup_source -> backup_archive - Şifrele: backup_archive -> backup_archive.enc - Yükle: backup_archive.enc -> object_storage - Doğrula: md5/etag eşleşmesi (mümkünse) ve/veya arşiv bütünlüğü - Temizle: local temp files sil

Kurtarma kalitesini artırmak için iki kontrol yapın: - Dosya bütünlüğü: Şifreli arşivin bozulmadığını doğrulayın (checksum). - Kurtarma denemesi: Ayda en az bir kez arşivden restore edip uygulamayı ayağa kaldırmayı simüle edin.

Doğrulama ve test: “Yükledim” ile “kurtarır” aynı şey değil

Dış depoya yükleme başarısı bile tek başına yeterli değildir. En sık görülen sorunlar: - Arşiv şifrelenmiş ama anahtar kayıp. - Dump sırasında hata olmuş, yine de dosya boyutu hedefe yakın olduğu için fark edilmemiş. - Şifreleme/kompresyon ayarları kurtarma aracının beklediği formatla uyuşmuyor.

Bu nedenle doğrulama hattını net kural seti gibi düşünün: - Yükleme sonrası doğrulama: Mümkünse depodan bir HEAD/metadata kontrolü + checksum karşılaştırma. - Restore testi: Düzenli aralıklarla “restore sandbox” ortamında çalıştırma. - Log takibi: cron çıktısını log dosyasında tutun ve e-posta/uyarı ile bildirin.

Restore testi için minimal senaryo

• Son yedekten birini seçin.
• Şifreyi çözün (doğru anahtar geldi mi?).
• Dosya/DB restore edin.
• Uygulamanın kritik endpoint’ini doğrulayın (ör. login, listeleme, ödeme öncesi kontrol vb.).

Saklama planı: retention (gün) ve versiyonlama

Dış depoda sınırsız saklama yapmak maliyeti büyütür. Net bir retention politikası belirleyin.

Örnek retention (pratik ve yaygın)

• Son 7 gün: günlük yedekler (7 nokta)
• Son 30 gün: haftalık yedekler
• Son 12 ay: aylık yedekler

Buna ek olarak bucket versiyonlama açıksa “yanlış silme/bozulma” durumunda kurtarma şansı artar.

Aşağıdaki tablo, bir “tek platforma yedek gönderme” yaklaşımında karar verirken yardımcı olur:

Performans ve bant genişliği: Yükleme süresini ölçün

Dış depoya gönderim ağ gecikmesi ve bant genişliğine bağlıdır. Bu nedenle yedek üretimi ile yükleme süresini aynı gün içinde planlayın.

Net ölçüm kriterleri

• Son 10 yedek için ortalama yükleme süresi
• En kötü senaryoda (peak trafik) yükleme süresi
• Yükleme tamamlanmadan yeni bir cron tetikleniyor mu?

Önerilen hedef: Ortalama yükleme süresi, yedek aralığının %30-40’ını aşmasın. Örneğin 24 saatte bir yedek alıyorsanız, en kötü koşulda bile yükleme birkaç saat içinde tamamlanmalıdır.

Güvenlik kontrol listesi: Kağıt üstünde değil, uygulamada

Aşağıdaki kontrol listesi pratikte sorunları erken yakalar:

• Anahtar yönetimi: Dış depoya erişim anahtarları düz metin olmamalı; mümkünse ortam değişkenleri veya güvenli saklama.
• Şifreleme: Yedek dosyaları dışarı çıkmadan önce şifrelenmeli.
• Minimum yetki: Yalnızca gerekli bucket/namespace yetkisi.
• Loglar: Yedek üretim hataları görünür olmalı.
• Rollback planı: Şifre çözme anahtarı/restore adımı dokümante olmalı.
• Periyodik restore testi: “Yükleme doğru” varsayımı yerine gerçek restore doğrulaması.

Yaygın hata senaryoları ve net çözümler

1) Yedek dosyası dış depoya gidiyor ama bozuk

• Sebep: dump/arşiv oluşurken hata alınıyor, süreç yine de devam ediyor.
• Çözüm: Her adım için hata kodunu kontrol edin ve yalnızca başarılı adımlar sonrası yükleme yapın.

2) Anahtar değiştiğinde kurtarma imkânsız

• Sebep: şifreleme anahtarları rotasyon/erişim planına dahil değil.
• Çözüm: Anahtar rotasyon takvimi ve restore dokümantasyonu oluşturun; en az bir “eski anahtarla restore” simülasyonu yapın.

3) Cron çakışıyor, aynı anda iki yedek yazıyor

• Sebep: backup süreleri dalgalanıyor.
• Çözüm: lock mekanizması ve tek iş çalıştırma garantisi.

4) Yükleme sırasında ağı kesiliyor

• Sebep: büyük dosyalar, network instabilities.
• Çözüm: parçalı yükleme (multipart) veya yeniden deneme (retry) mantığı. Sağlayıcı multipart desteğini kullanın.

Sonuç: İlk hedefiniz “otomatik + test edilmiş kurtarma” olsun

Otomatik yedeklemeyi dış depolamaya göndermek için en doğru başlangıç, tek seferlik kurulum yerine üç şeyi aynı anda tasarlamaktır: şifreli üretim, güvenilir aktarım ve düzenli restore testi. Bu hafta yapmanız gereken aksiyon önerisi: - Yedeğinizi hangi bileşene göre (dosya/DB) alacağınıza net karar verin. - Dış depoda bir bucket/namespace seçip minimum yetkili anahtar tanımlayın. - Şifreleme + checksum doğrulaması ekleyin. - En geç 7 gün içinde bir restore simülasyonu çalıştırıp dokümante edin.

Bu adımlar tamamlandığında yedek “var” olmaktan çıkar, “kurtarır” hale gelir.