Otomatik Yedeklemeyi Dış Depolamaya Yollama Rehberi (2026)

Sunucuda bir sorun çıktığında yedek var mı sorusunun cevabı kadar, yedeğin nerede durduğu ve ne kadar güvenilir şekilde erişilebilir olduğu da kritiktir. Bu rehberde, otomatik yedeklemeleri yerel diskten dış depolamaya (S3 uyumlu obje depolama, SFTP/NAS, başka bir bulut) nasıl göndereceğinizi adım adım öğreneceksiniz. Hedef; tek seferlik yedek değil, saat/günlük otomatik akış, şifreleme (encryption), erişim kontrolü ve düzenli test ile sürdürülebilir bir yapı kurmak.

Dış depolama neden şart: aynı riske düşmeyi engelleyin

Yedekleri aynı VDS/VPS üzerinde tutmak, donanım arızası, yanlış silme, fidye yazılımı (ransomware) veya disk doluluğu gibi durumlarda çoğu zaman yedeği de etkiler. Bu nedenle dış depolama; yedeği üretildiği sisteme bağımlılıktan çıkarır.

Aşağıdaki risklere karşı dış depolama stratejisi daha tutarlı olur: - Silme/bozulma: Sunucuda yanlışlıkla silinen klasörün dışarıda kopyası kalır. - Disk arızası: Yerel disk giderse, dış depoya aktarılan kopya hayatta kalır. - Ransomware: Sunucu erişimi ele geçirilse bile dış depoya giden yetkilendirme ve şifreleme doğru kurgulanırsa koruma artar. - Hızlı kurtarma: Dış depodan geri getirme süresi planlanırsa RTO düşer.

Dış depolama hedefinizi seçin

En yaygın 3 yöntem: 1. S3 uyumlu obje depolama (Amazon S3, Wasabi, MinIO vb.) 2. Bulut sağlayıcı depolama (Cloud Storage) + servis entegrasyonu 3. SFTP/NAS/uzak dosya sunucusu

Kural olarak şu tabloyu kullanın: - Sunucu tek bir dosya arşivi üretip gönderiyorsa: S3 uyumlu daha pratik. - Şirket içi ağda NAS kullanıyorsanız: SFTP daha kontrol edilebilir. - Çok küçük/çok sık yedeklemede: S3 sürümleme (versioning) ve yaşam döngüsü kurallarıyla maliyet optimize edilir.

Mimari plan: yedek akışı nasıl çalışmalı?

Amaç; şu 4 aşamanın otomatik ve ölçülebilir olmasıdır: 1. Yedek üretimi (backup) 2. Şifreleme (encryption) 3. Dış depoya transfer (upload/sync) 4. Test ve doğrulama (restore test)

Bunu “tek komutla her şeyi yapma” yerine modüler düşünün. Örneğin yedek üretimi başarılı olmalı; transfer de başarılı olmalı; loglar izlenmeli ve başarısızlık halinde alarm üretmelidir.

Uygun yedek kapsamı (hangi veriler?)

En az şu bileşenleri düşünün: - Uygulama dosyaları (web kökü, config dizinleri) - Veritabanı: MySQL/MariaDB/PostgreSQL - Sistem konfigleri: /etc ve uygulama bazlı kritik dosyalar - TLS sertifikaları (Let’s Encrypt): yeniden üretilebilir olsa bile kurgunuza göre ekleyin - Uygulama özel ayarlar: ör. WordPress wp-content, Nginx site configleri

Yedekleme sıklığı ve saklama politikası

“Her şey günlük olsun” yaklaşımı maliyeti kontrol etmeyi zorlaştırır. Tipik, ölçülebilir bir politika: - Saatlik: veritabanı (özellikle yoğun çalışan sistemlerde) - Günlük: uygulama dosyaları + veritabanı tam - Aylık: daha geniş saklama (arşiv)

Dış depoda saklama için örnek (sade plan): - Son 7 gün: günlük saatlik setler - Son 30 gün: yalnızca günlük tamlar - 90 gün: aylık arşivler

Dış depolamaya gönderim yöntemleri (net karşılaştırma)

Aşağıdaki karşılaştırma, hangi yöntemi seçeceğinizi netleştirir.

Şifreleme: dışarı yollamadan önce koruyun

Dış depolama üzerinden koruma tek başına yeterli değildir; taşıma ve depolama sırasında riskler vardır. En doğru yaklaşım: yedek arşivini transfer öncesi şifrelemek.

Önerilen teknik prensipler: - Şifreleme anahtarını sunucuya “düz metin” gömmeyin. - Dosya şifreliyse, dış depodaki verinin okunabilirliği düşer. - Şifreleme algoritmasını güçlü tutun (ör. AES-256).

Uygulama: Linux’ta otomatik yedek üret + dış depoya gönder

Aşağıdaki örnek mimari; herhangi bir sağlayıcıya uyarlanabilir. Burada amaç komutların mantığını göstermek, sizin sisteminize göre değiştirmeniz gereken kısımları netleştirmektir.

1) Yedek üretimi (mysqldump + arşiv)

Veritabanı için örnek mantık: - MySQL/MariaDB ise mysqldump - PostgreSQL ise pg_dump

Örnek: MySQL için (sadece şablon): - mysqldump ile DB dump alın - Dosyaları bir arşive toplayın (ör. tar)

Yedek dosyalarını isimlendirin: - backup-hostname-YYYY-MM-DD_HHMM.tar.gz

2) Şifreleme (transfer öncesi)

Arşivi üretir üretmez şifreleyin. Mantık: - Şifreli dosya oluşsun - Şifreli dosyayı dış depoya gönderin

3) Dış depoya gönderim

S3 uyumlu depolama (önerilen)

S3 için pratik yaklaşım: rclone ya da sağlayıcı CLI kullanmak. - Kimlik bilgilerini (access key / secret) ortam değişkenlerinden veya root’a kapalı bir config dosyasından yönetin. - Aktarım sonrası doğru dosya üretildi mi kontrol edin (ör. boyut/exit code).

Örnek komut şablonu (sağlayıcıya göre değişir): - rclone copy /path/backup.enc remote:bucket/host/ --progress --transfers 1

SFTP ile NAS/uzak sunucu

SFTP yönteminde kritik konu: yeniden deneme (retry) ve kısmi dosya problemleri. - Önce “tam dosya” için farklı bir isimle yükleyin - Yükleme tamamlanınca hedef isim değiştirin (atomic rename mantığı)

4) Sistem dışı kalma: Cron yerine zamanlayıcı + log

Planlanan işlerin doğruluğunu kanıtlamak için log şarttır. - cron ile çalışacaksanız bile stdout/stderr’ı dosyaya yönlendirin - Başarısızlıkta e-posta/Slack/telemetri tetikleyin

Örnek log prensibi: - /var/log/backup/backup-YYYY-MM-DD.log - Her çalışmada özet: başlangıç saati, üretilen dosya boyutu, şifreleme durumu, transfer exit code

5) Yedekleri doğrulayın: restore test

En sık yapılan hata: “dosya dış depoda görünüyor” demek. Bu, içeriğin restore edilebilir olduğu anlamına gelmez.

Restore test için net yöntem: - Her hafta: dış depodan şifreli arşivi indirip yerel test ortamında açın - Veritabanı için: dump’ın içinden sample bir tabloyu yükleyin ve checksum/ilk kayıt doğrulaması yapın - Uygulama için: en azından konfig + statik dosya erişimini doğrulayın

Saklama ve maliyet kontrolü: dış depoda yaşam döngüsü

Dış depolama maliyeti; veri boyutu + transfer maliyeti + saklama süresine göre şekillenir. Bu nedenle dış depoda yaşam döngüsü (lifecycle policy) kurun.

S3 lifecycle ile net hedefler

• 7-30-90 gün gibi net aralıklar belirleyin
• “Silme” yerine “daha ucuz sınıfa geçiş” (storage class transition) seçeneğini değerlendirin
• Versioning açtıysanız silme davranışı değişir; restore için sürüm mantığını test edin

Güvenlik kontrol listesi (doğrudan uygulanabilir)

Aşağıdaki listeyi “dış depoya yedek gönderiyorum” diyemeden önce kontrol edin: - Şifreleme var: Yedek dosyası transfer öncesi şifreli - Anahtar yönetimi: Şifre anahtarı dosya sisteminde açıkta değil - Erişim en az yetki (least privilege): Yedekleme kullanıcısı sadece gerekli bucket/path erişimine sahip - Şifreli aktarım: SFTP kullanıyorsanız SSH anahtarı; S3 kullanıyorsanız HTTPS - Loglar: Transfer başarısızsa yakalanıyor - Restore testi: En az haftalık doğrulama yapılıyor - Boş alan/paketleme kontrolü: Sunucuda disk doluluğu yedek akışını kesmesin (pre-check) - Saklama politikası: Dış depoda kontrolsüz birikim yok

Ayrıca veri bütünlüğü için doğrulama

• Şifreleme öncesi ve sonrası hash (örn. sha256sum) oluşturun
• Transfer sonrası hash karşılaştırın veya en azından dosya boyutu + çıkış kodu ile teyit edin

Sık yapılan hatalar ve net düzeltmeler

• Yedek var, ama okunamıyor: Restore testini otomatikleştirin.
• Yalnızca yerel kayıp değil, yanlış silme de yedeği etkiliyor: Dış depoyu ayrı yetki ve farklı isimlendirme ile kullanın.
• Dış depoya hiç gitmiyor ama log görünüyor: Transfer exit code kontrolü ekleyin.
• Şifreleme yok: Dış depodaki izinler bozulsa bile yedek okunmasın.
• Yaşam döngüsü yok: 90 günden sonra “otomatik bütçe patlaması” yaşarsınız; lifecycle kuralı şart.

Sonuç: 3 adımda çalışır, test edilen dış yedek planı kurun

Otomatik yedeklemeyi dış depolamaya taşımada en doğru yaklaşım; şifreli arşiv üretmek, transferi otomatikleştirip loglamak, ardından düzenli restore testi yapmaktır. Hemen aksiyon önerim: (1) dış hedefinizi seçin (S3 uyumlu veya SFTP), (2) şifreli yedek üretim + transfer akışını kurup exit code/log doğrulaması ekleyin, (3) haftalık restore testini takvime bağlayın. Bu üç adımı tamamladığınızda yedek sistemi “dosya duruyor” seviyesinden “kurtarma sağlayan” seviyeye geçer.