Otomatik Yedeklemeyi Dış Depolamaya Gönderme Rehberi (VDS/VPS)

Otomatik yedekleme tek başına “güvende olduğunuz” anlamına gelmez. Yedek dosyalarının aynı sunucuda kalması; donanım arızası, yanlışlıkla silme veya kötü amaçlı erişim gibi senaryolarda geri dönüşü zorlaştırır. Bu rehberde, VDS/VPS üzerinde çalışan yedekleri dış depolamaya (S3 uyumlu storage, SSH/SFTP veya yurt dışı bulut) otomatik olarak gönderecek şekilde kurulum ve doğrulama adımlarını netleştiriyoruz. Hedef; yedek almayı değil, yedek alındığını kanıtlamayı ve geri dönüş testini düzenli hale getirmeyi sağlamaktır.

Dış depolama stratejisini netleştirin: hedef, sınırlamalar, maliyet

Dış depolamaya gönderimde önce “nerede tutacağım?” sorusunu teknik olarak tanımlayın. Çünkü doğru seçim, hem süreleri hem de maliyetleri belirler.

Dış depolama seçenekleri ve tipik kullanım alanları

Aşağıdaki tablo, yaygın seçenekleri pratik ölçütlerle özetler:

Yedek politikasını 3 katmana ayırın

Dış depolama planınız, “her şeyi her gün” yerine katmanlı olursa sürdürülebilir olur.

• Hızlı kurtarma (ör. 24 saat içinde): Günlük inkremental/rotasyonlu yedek (örn: son 7 gün)
• Ransomware/yanlış silme toleransı: Daha uzun tutma (örn: son 30 gün)
• Afet kurtarma: Aylık tam yedek + uzun süreli saklama (örn: 90 gün/1 yıl)

Bu katmanlar, dış depolama maliyetinizi de doğrudan etkiler. Örneğin günlük tam yedek yerine inkremental yaklaşımı seçmeniz, çoğu WordPress ve uygulamada ciddi fark yaratır.

Ön kontrol: yedeklenecek veri türlerini ayırın

“Dış depolamaya gönderme” adımına geçmeden önce yedeklenecek veriyi doğru paketleyin. Çünkü yanlış paketleme, geri yüklemede sürpriz çıkarır.

WordPress/VPS için veri listesi (örnek)

• Web kökü (örn: /var/www/html): dosyalar
• Veritabanı (örn: MySQL/MariaDB veya PostgreSQL): şema + veriler
• Uygulama ayarları: .env dosyaları, wp-config.php (gizli değerler kontrol edilerek)
• Günlükler (opsiyonel): gereksiz şişmeyi önlemek için filtreleyin

Kritik doğrulama: yedek dosyası tutarlı mı?

Yedek almadan önce şu kontrolü yapın: - Veritabanı dump işlemi sırasında tutarlılık (tamlık) sağlanıyor mu? - Dosyalar sık değişiyorsa (cache/ uploads yoğun), yedek sırasında eşzamanlama var mı?

Pratikte “önce dump, sonra dosya paketleme” sırası çoğu senaryoda daha stabil sonuç verir.

Otomasyon altyapısı: neyle yedek alacağım, neyle dışarı aktaracağım?

VDS/VPS tarafında iki katman düşünün: 1) Yedek üretim aracı (backup engine) 2) Dış depoya taşıma aracı (transfer)

Üretim araçları: örnek seçenekler

• WordPress için plugin (ör. yedek al + dışarı gönder): hızlı başlangıç
• Sistem seviyesinde araçlar:
• mysqldump / pg_dump (veritabanı)
• tar + sıkıştırma (dosyalar)
• rsync (inkremental yaklaşım; uygun senaryolarda)

Taşıma araçları: S3 ve SSH

• S3 uyumlu depolama için: aws-cli veya S3 uyumlu CLI
• SSH/SFTP için: scp/sftp yerine daha kontrollü rsync over ssh tercih edin

Bu rehberde “taşıma” tarafını odaklayacağız; ancak üretim katmanı tutarlı olmalıdır.

Adım adım: S3 uyumlu dış depolamaya otomatik gönderim

Aşağıdaki akış, VDS/VPS üzerinde çalışacak bir otomasyonu anlatır. Amaç: yedek üretildikten sonra dış depoya aktarım, ardından yerel temizleme ve doğrulama.

1) Gerekli bağımlılıkları kurun

S3 için sıklıkla şu paketler kullanılır: - awscli (veya S3 uyumlu sağlayıcının önerdiği CLI)

2) Erişim anahtarlarını sınırlayın

En kritik güvenlik adımı budur: - Uygulama için ayrı bir erişim anahtarı oluşturun - Sadece hedef bucket’a yazma/okuma izni verin (gerektiği kadar) - Dışarı aktarımı yapan kullanıcıya sadece gerekli izinleri tanımlayın

3) Dosya isimlendirmesi: geri yüklemeyi kolaylaştırın

Yedek dosyası adları geri dönüşte zaman kazandırır. Örnek format: - backup_{uygulama}_{yyyy-mm-dd}_{HHMM}.tar.gz - Veritabanı için: db_{yyyy-mm-dd}_{HHMM}.sql.gz

4) Yedek üretimini paketleyin

Örnek yaklaşım: - Veritabanını dump al → gzip ile sıkıştır - Dosyaları tar ile paketle - İkisini ayrı ayrı saklamak genelde daha güvenlidir (tek büyük arşiv yerine)

5) Yerel geçici klasör kullanın

Aktarım başarısız olduğunda veri kaybetmemek için: - Yedekler önce /tmp/backups gibi geçici alanda üretilsin - S3’e yükleme tamamlanınca yerel silme yapın

6) Aktarımı yapın: yükleme + bütünlük kontrolü

S3’e yükleme sonrası iki kontrol hedefleyin: - Dosya boyutu/özet (md5/etag veya sistem içi hash) - Yükleme sonrası dış depoda varlık

S3 için pratik bir kontrol yaklaşımı: - Yükleme tamamlandıktan sonra CLI ile aynı anahtarı listede arayın - Mümkünse yerel üretilen sha256 hash’iyle dış taraf doğrulaması yapın

7) Cron ile otomasyon

Zaman planı net olmalı: - Günlük inkremental/rotasyon: saat 02:00 gibi düşük trafik - Aylık tam yedek: ayın 1’i gibi sabit gün

Cron ile tetiklenen süreçte her adımın çıktısını loglayın: - yedek üretildi mi? - dış depoya yükleme başarılı mı? - yerel silme yapıldı mı? - doğrulama geçti mi?

Aksi halde “otomatik” gerçekte otomatik değil, sessizce başarısız olabilir.

Adım adım: SSH/SFTP ile dış depoya otomatik gönderim

S3 istemiyorsanız, başka bir sunucuda tutulan depo alanına taşımak yaygın bir yaklaşımdır. Burada kritik olan; kimlik doğrulama ve bağlantı güvenliğidir.

1) Dış depolama sunucusunda hedef dizin hazırlayın

• Yedekler için ayrı bir dizin oluşturun: ör. /backup-repo/hostname
• Disk alanını ve inode kullanımını planlayın

2) SSH anahtarı ile erişim kurun

• İlgili kullanıcı için authorized_keys kullanın
• Parola ile giriş kapatın
• Anahtarı mümkünse yedekleme yapan sunucu ile sınırlayın (IP kısıtı)

3) rsync over ssh kullanın

rsync avantajı: - İlerleme takibi (log) - İnkremental mantık (uygun senaryoda) - Hata durumunda tekrar deneyim

Aşağıdaki akış, “önce üret → sonra aktar → sonra temizle” mantığını korur: - Yerelde arşiv oluştur - rsync ile uzak dizine gönder - Uzak dizinde dosya varlığını kontrol et - Yükleme doğrulandıktan sonra yerel silme

4) Ağ kesintilerine dayanıklılık

• Tek denemede başarısız olursa 2-3 kez tekrar deneyin
• Tekrar denemeleri loga düşürün
• Aynı gün içinde yedeklerin üst üste yazılmamasını sağlayın

En önemli kısım: yedek doğrulama ve geri yükleme testi

Dış depoya “gönderdim” demek yeterli değil. Sisteminizin gerçekten kurtarılabilir olduğunu kanıtlamanız gerekiyor.

1) “Başarılı aktarım” ile “dosya kurtarılabilir” aynı şey değildir

Aşağıdaki hatalar görülebilir: - Arşiv bozuk üretildi - Aktarım yarıda kaldı, tam yüklenmedi - Yedek alındı ama geri yükleme senaryosunda uyumsuzluk var (ör. farklı DB sürümü)

2) Haftalık geri yükleme testi rutini oluşturun

• Tam restore (gereksinime göre) veya seçilmiş parçalı restore yapın
• WordPress için en azından:
• wp-config.php ayarlarını test edin
• veritabanını restore edip siteyi staging ortamında açın

3) Log ve uyarı: sessiz başarısızlığı bitirin

En azından şu bilgileri loglayın: - Yedek başlangıç/bitiş zamanı - Oluşturulan dosyaların boyutu - Dış depoya yükleme sonucu - Doğrulama sonucu

Uyarı için e-posta veya Telegram/Slack webhook gibi bir mekanizma ekleyin. Önemli olan, hatanın fark edilme süresini kısaltmaktır.

Güvenlik kontrolleri: dış depolama hedefi saldırı yüzeyi olabilir

Dış depolama, güvenliği artırır; ama doğru kurulmazsa risk de ekler.

1) Depolama anahtarlarını yetkisizleştirin

• Yazma izni sadece gerekli bucket/prefix’te olsun
• Anahtarların rotasyonu (ör. 90 günde bir) planlansın

2) Yedek dosyalarında hassas veri yönetimi

• Yedeklerde wp-config.php gibi sırlar varsa şifreleme gerektirir
• Dosya düzeyinde şifreleme yerine mümkünse “şifrelenmiş arşiv” yaklaşımı kullanın

Pratik kontrol: - Arşiv şifreli mi? - Şifreleme anahtarına erişim kimlerde?

3) Ransomware senaryosu

Ransomware hem sunucudaki dosyaları hem de yedekleri hedef alabilir. Bunu azaltmak için: - Yedekleri dışarıya aktarım tamamlanmadan yerel temizleme yapmayın - Dış depoda sürümleme (versioning) veya silmeye karşı koruma (provider özelliğine göre) kullanın

Performans ve maliyet: süreyi ve bant genişliğini planlayın

Dış depoya taşıma, bant genişliği kullanır. Bu nedenle süre ve boyut yönetimi net olmalı.

1) Transfer sürelerini ölçün

• İlk çalıştırmada hız ölçümü yapın
• Yedek boyutu büyüdükçe yeni bir plan gerekir mi, değerlendirin

2) Sıkıştırma stratejisi

• Dosya arşivlerinde sıkıştırma genelde fayda sağlar
• Ama veritabanı dump’ta da sıkıştırma yapın; çoğu senaryoda ciddi azalma olur

3) Retention (saklama) rotasyonu

• 30 gün saklamak yerine 7 gün saklamak bazı şirketlerde yetmez, ama 180 gün her zaman gereksizdir
• Katmanlı stratejiyle maliyeti kontrol edin

Aşağıdaki liste, hızlı bir retention başlangıç şablonu olarak kullanılabilir: - Son 7 gün: günlük yedek - Son 30 gün: haftalık yedek - Son 90 gün: aylık tam yedek

Net kontrol listesi (işe başlamadan önce)

Aşağıdaki maddeler tamamlanmadan “otomatik dış yedek” devreye alınmasın:

• [ ] Yedek dosyası üretimi hata vermeden tamamlanıyor
• [ ] Yedekler yerel geçici alanda üretilip aktarım sonrası temizleniyor
• [ ] Dış depoda dosya varlığı doğrulanıyor
• [ ] Haftalık en az 1 geri yükleme testi yapılıyor
• [ ] Yedek dosyalarında hassas içerik varsa şifreleme uygulanıyor
• [ ] Erişim anahtarları sadece gerekli izinlere sahip
• [ ] Loglar toplanıyor ve başarısız iş için uyarı kuruluyor

Sonuç: dış depoya “gönderme”yi değil “kurtarma”yı hedefleyin

Otomatik yedeklemeyi dış depolamaya taşımak için en doğru yaklaşım; yedek üretimi, aktarım, yerel temizleme ve doğrulamayı tek bir akışta birleştirmektir. Bir sonraki adım olarak, önce kendi altyapınızda hangi verileri (dosya + veritabanı) yedeklediğinizi net listeleyin; ardından S3 uyumlu storage ya da SSH/SFTP seçeneklerinden birini seçip retention ve geri yükleme testini takvime bağlayın. Bu kurgu kurulduğunda, dış depoya gönderim tek seferlik bir işlem değil, düzenli ve ölçülebilir bir güvenlik katmanına dönüşür.