VDS Yedeklemesi Nasıl Yapılır? Otomatik mi Manuel mi?

VDS yedeklemesi; dosya kaybı, yanlış silme (human error), saldırı sonrası bütünlük bozulması veya depolama arızasında veriyi geri getirme ihtiyacını doğrudan karşılar. Ancak “yedek almak” tek başına yetmez: Yedeğin ne sıklıkta alındığı, nerede tutulduğu, şifrelenip şifrelenmediği, test edilip edilmediği ve geri dönüş (restore) süresi planlanmalıdır. Bu rehberde VDS üzerinde dosya ve veritabanı yedeklerini manuel ve otomatik yaklaşımla kurmayı, pratikte hangi senaryoda hangisinin daha doğru olduğunu net karşılaştıracaksınız.

VDS yedeklemesi neleri kapsamalı?

VDS’te iki ana veri grubu vardır:

1) Uygulama dosyaları - Web kökü (ör. /var/www/) - Uygulama kodu (Node.js/uygulama dizinleri) - Konfigürasyon dosyaları (ör. .env) - Nginx/Apache ayarları (gerekli ise)

2) Veritabanı (database) - MySQL/MariaDB için: veri dosyaları değil, en doğru yöntem SQL dump (mysqldump) veya fiziksel snapshot yaklaşımı - PostgreSQL için: pg_dump mantığıyla mantıksal yedek

Net hedef: Uygulamanın tek tek dosyalarını değil, geri dönüşte çalışacak bütünlüğü yedeklemektir.

Yedekleme stratejisi için 4 karar

Yedekleme planınızı oluşturmadan önce şu 4 kararı netleştirin: - Sıklık: Her değişiklik mi, saatlik mi, günlük mü? - Saklama süresi: 7 gün mü, 30 gün mü, 90 gün mü? - Hedef: Aynı sunucuda mı, farklı lokasyonda mı (en azından farklı depolama/hesap)? - Geri dönüş testi: Yedek alınmış mı, restore edilebilir mi?

Bu kararlar otomatik mi manuel mi yapacağınızı da doğrudan etkiler.

Manuel VDS yedeklemesi nasıl yapılır?

Manuel yöntem, komutları siz tetiklersiniz. Avantajı kurulumun basit olmasıdır. Dezavantajı ise sıklığı “insan alışkanlığı” belirlediği için risk oluşturmasıdır.

Dosya yedekleme (örnek: rsync ile)

Tipik yaklaşım; dosyaları yerel ya da uzak depoya kopyalamaktır. En pratik araçlardan biri rsync’tir.

Örnek akış: - Kaynak dizin: /var/www/ - Yedek hedefi: uzak bir sunucu üzerindeki klasör (veya aynı sunucuda ayrı bir mount) - Hız ve bant için artımlı mantık

Örnek komut (senaryonuzda dizinleri değiştirin):

rsync -a --delete /var/www/ backupuser@yedek-sunucu:/backups/www/

Burada kritik noktalar: - --delete kullanıp kullanmamak: Eğer hedef aynen kaynak gibi tutulacaksa doğru; yanlışsa “eski dosyalar da geri gelmesin” hedefi bozulabilir. - Yetki: Yedeklenen dosyalar uygulamanın okuyabildiği şekilde olmalı.

Veritabanı yedekleme (örnek: MySQL/MariaDB dump)

MySQL/MariaDB için mantıksal yedek; mysqldump ile alınır. Örnek akış:

mysqldump -u dbuser -p --single-transaction --routines --triggers databasename > /backups/db-$(date +%F).sql

Net dikkat noktaları: - --single-transaction: InnoDB tablolarında tutarlılık için genelde tercih edilir. - --routines ve --triggers: Uygulamanın çalışması için gerekiyorsa eklenir. - Yedek dosyası saklama dizini: Uygun disk alanı planlayın.

Manuelde sık yapılan hatalar

• Yedek dosyasını almak ama saklama süresini uygulamamak (disk dolması)
• Yedeği aynı fiziksel sunucuda tutmak (disk arızasında hem servis hem yedek gider)
• Restore adımını hiç denememek (yedek var, ama geri dönüşte hata çıkması)

Otomatik VDS yedeklemesi nasıl yapılır?

Otomatik yaklaşımda tetikleyici genelde cron (zamanlayıcı) olur. Siz kuralları tanımlarsınız; sistem belirlenen aralıklarla yedek alır.

Otomatik zamanlama (cron) mantığı

En temel plan: - Dosya yedekleri: günlük veya saatlik - Veritabanı yedekleri: en az günlük; değişiklik yoğunluğuna göre saatlik - Saklama: ör. 7 günlük tam, 30 günlük artımlı yaklaşım veya her gün ama farklı tutma pencereleri

Örnek cron düzeni (mantık gösterimi): - Her gün 02:00 dosya yedeği - Her saat DB dump (yük çoksa günlük ile başla)

Cron’u kurduktan sonra şu kontrolleri otomasyona ekleyin: - Komut hatası olursa e-posta/Slack bildirimi - Yedek bütünlüğü: dosya boyutu veya checksum doğrulaması - Dönüşümlü saklama: eski dosyaları silme/arşivleme

Şifreleme ve güvenlik

Otomatik yedek alırken yedek dosyaları hedef depoda güvenli olmalıdır: - Yedekleri şifreleyin (örn. gpg ile veya şifreli container mantığı) - Uzak depoya aktarımı şifreli yapın (SSH/SFTP) - Erişim yetkilerini daraltın: yalnızca yedekleme yapan kullanıcı

Şifreleme şartı özellikle uzaktaysa belirleyicidir.

Uzak hedef seçimi: aynı VDS mi, farklı depolama mı?

• Aynı VDS üzerinde yedek: disk dolarsa veya disk arızası olursa risk devam eder.
• Farklı depolama/hesap/lokasyon: saldırı veya fiziksel sorun senaryolarında yedeği korur.

Net hedef: Yedek arızası ile ana servis arızasının aynı “kök nedene” bağlı olmamasını sağlayın.

Manuel vs otomatik: Hangi durumda hangisi net olarak daha iyi?

Aşağıdaki karşılaştırma, “daha kolay olan” değil “daha güvenli ve geri dönüşü daha öngörülebilir” seçimi hedefler.

Net öneri kuralı

• Dosya/veritabanı değişiklikleri günlükten daha sık ve kritikse: otomatik tercih edin.
• Test ortamı, düşük riskli statik site veya öğrenme amaçlı kurulum ise: manuel ile başlayın; sonra otomatiğe geçin.

Pratik yedek planı şablonları (dosya + DB)

Aşağıdaki planlar “başlangıçta net” bir çerçeve sağlar. Uygulamanızın güncelleme sıklığına göre düzeltin.

Senaryo 1: Blog/kurumsal site (günlük güncelleme)

• Dosya yedeği: günlük
• DB yedeği: günlük (şifreli dump)
• Saklama: 14 gün (DB), 30 gün (dosya)
• Yedek hedefi: farklı depolama/uzak konum
• Restore testi: ayda 1

Senaryo 2: E-ticaret/yoğun trafik (sürekli güncelleme)

• Dosya yedeği: her 6 saatte bir
• DB yedeği: her 1-2 saatte bir (yük çoksa günlük + kritik anlar)
• Saklama: 7 gün (DB tam), 30 gün (daha eski arşiv)
• Yedek hedefi: uzakta + şifreli
• Restore testi: her 2 haftada 1 veya büyük güncelleme sonrası

Senaryo 3: Geliştirme/staging ortamı

• Dosya yedeği: haftalık
• DB yedeği: haftalık (veya deploy sonrası)
• Saklama: 14 gün
• Restore testi: deploy öncesi kontrol edilen rutin

Restore (geri dönüş) testini nasıl yaparsınız?

Yedek stratejisinin en kritik kısmı, yedeğin gerçekten geri dönüp dönmediğidir. Otomatik sistem kurduysanız bile restore testi yapmazsanız yedek “varsayım” olur.

Basit restore test checklist

• Yedek dosyası mevcut mu ve boyutu normal mi?
• Şifreli yedek ise şifre çözme (decrypt) sorunsuz mu?
• DB dump ise SQL komutları hatasız mı?
• Restore sonrası uygulama ayağa kalkıyor mu?
• Konfigürasyonlar (ör. APP_ENV, .env) yedekten geliyor mu?

DB restore örneği (mantık)

MySQL dump için genel mantık:

mysql -u dbuser -p databasename < /backups/db-YYYY-MM-DD.sql

Buradaki net kritik nokta: Restore edilecek veritabanı adı, kullanıcı yetkileri ve şema uygunluğu.

Performans ve maliyet: yedekleme işlemi VDS’i yavaşlatmasın

Yedekleme bir anda disk IO ve CPU tüketebilir. Bu yüzden planınız “bakım penceresi” mantığı taşımalı.

Net ayar önerileri

• Yoğun saatlerde DB dump’ı sıklaştırmayın; trafik düşükken çalıştırın.
• Artımlı dosya transferinde rsync kullanın.
• Yedeklerin sıkıştırma politikasını belirleyin:
• Disk azsa: sıkıştırın
• CPU kısıtlıysa: sıkıştırmayı azaltın
• Yedek hedefi için ağ bant genişliğini göz önünde bulundurun.

Sonuç: VDS yedeklemesini nasıl netleştirmelisiniz?

VDS yedeklemesinde manuel yaklaşım yalnızca düşük riskli senaryolarda sürdürülebilir olur. Gerçek veri kaybı maliyeti olan uygulamalarda otomatik yedekleme; zamanlama, saklama, şifreleme ve restore testi ile birlikte kurulduğunda net şekilde daha güvenli bir dönüş sağlar.

Aksiyon önerisi: Bugün başlamak için (1) dosya + DB kapsama alanınızı listeleyin, (2) günlük bir otomatik planla başlayın, (3) yedekleri şifreleyip uzak hedefe gönderin, (4) ilk hafta içinde en az bir kez restore testini çalıştırın. Böylece yedek “alınan dosya” değil, gerektiğinde gerçekten çalışan bir geri dönüş süreci olur.