VDS Yedekleme Stratejileri ve 3-2-1 Kuralı

Sunucu yedekleme, ihtiyaç duyulana kadar ertelenen ama ihtiyaç duyulduğu anda her şeyin ona bağlı olduğu bir konudur. Bir VDS ne kadar güçlü donanım üzerinde çalışırsa çalışsın, yanlış bir komut, hatalı bir eklenti güncellemesi, ele geçirilmiş bir yönetici hesabı ya da fidye yazılımı verilerinizi saniyeler içinde kullanılamaz hâle getirebilir. Bu yazıda VDS için sağlam bir yedekleme stratejisinin nasıl kurulacağını; 3-2-1 kuralını, RPO ve RTO kavramlarını, veritabanı yedeklerini, restic ile şifreli uzak yedeklemeyi ve en çok ihmal edilen adım olan geri yükleme testini ele alıyoruz.

Yedek Neden Gerekli? RAID ve Snapshot Neden Yetmez?

Veri kaybının en yaygın nedenleri çoğu zaman donanım arızası değil, insan ve yazılım kaynaklı olaylardır:

• Yanlış dizinde çalıştırılan bir silme komutu ya da hatalı bir veritabanı sorgusu
• Siteyi bozan bir tema, eklenti veya uygulama güncellemesi
• Ele geçirilen bir hesap üzerinden verilerin silinmesi veya değiştirilmesi
• Dosyaları şifreleyen fidye yazılımları
• Uygulama hatası nedeniyle günlerce fark edilmeden bozulan veriler

RAID yedek değildir. RAID bir diskin arızalanmasına karşı hizmetin sürmesini sağlar; ama silinen bir dosya tüm disklerden aynı anda silinir. Anlık görüntü (snapshot) de tek başına yedek değildir. Snapshot hızlı geri dönüş için çok değerlidir, örneğin büyük bir güncelleme öncesinde; ancak çoğu zaman aynı depolama sistemi üzerinde durur ve o sistem ya da hesap etkilendiğinde snapshot da etkilenebilir. Gerçek bir yedek, kaynak sistemden bağımsız bir yerde saklanan ve geri yüklenebildiği doğrulanmış bir kopyadır.

3-2-1 Yedekleme Kuralı

3-2-1 kuralı, yedekleme stratejileri için kabul görmüş basit bir çerçevedir:

• 3 kopya: Verinin biri canlı, ikisi yedek olmak üzere en az üç kopyası bulunmalı.
• 2 farklı ortam: Yedekler en az iki farklı depolama ortamında veya sisteminde tutulmalı.
• 1 farklı lokasyon: Kopyalardan en az biri fiziksel olarak farklı bir yerde durmalı.

Günümüzde bu kural sıklıkla 3-2-1-1-0 olarak genişletilir: ek olarak bir kopyanın çevrim dışı veya değiştirilemez (immutable) olması ve geri yükleme testlerinde sıfır hata hedeflenmesi. Fidye yazılımlarının yedekleri de hedef aldığı düşünüldüğünde bu ek maddeler artık bir lüks değildir.

3-2-1 kuralını VDS'e uygulamak

RPO ve RTO: Ne Kadar Sık, Ne Kadar Hızlı?

Yedekleme sıklığını rastgele değil, iki soruya göre belirleyin:

• RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybını göze alabilirsiniz? Günde bir yedek alıyorsanız en kötü durumda bir günlük veri kaybedersiniz.
• RTO (Recovery Time Objective): Bir felaketten sonra hizmetin en geç ne kadar sürede ayağa kalkması gerekir?

Haftada bir güncellenen kurumsal bir sitede günlük yedek yeterliyken, sürekli sipariş alan bir e-ticaret sitesinde veritabanının saatlik ya da daha sık yedeklenmesi gerekebilir. RTO kısa olmalıysa geri yükleme adımlarını önceden belgelemek ve yedeği hızlı erişilebilir bir yerde tutmak gerekir.

Neleri Yedeklemelisiniz?

• Uygulama ve site dosyaları: Örneğin /var/www veya uygulamanızın kurulu olduğu dizin
• Veritabanları: Tutarlı döküm dosyaları olarak (aşağıda anlatılıyor)
• Yapılandırma dosyaları: /etc dizini; web sunucusu, PHP, güvenlik duvarı ve servis ayarları
• SSL sertifikaları: Let's Encrypt kullanıyorsanız /etc/letsencrypt
• Zamanlanmış görevler: crontab -l çıktısı ve /etc/cron.d
• E-posta kutuları, kullanıcı dizinleri ve Docker birimleri

Önbellek dizinleri, geçici dosyalar ve yeniden üretilebilen içerikler yedek dışında bırakılarak yedek boyutu ve süresi küçültülebilir.

Veritabanı Yedekleri: Dosya Kopyalamak Yetmez

Çalışan bir veritabanının dosyalarını doğrudan kopyalamak tutarsız bir yedek üretebilir. Bunun yerine veritabanının kendi döküm araçlarını kullanın. MySQL ve MariaDB'de InnoDB tablolarının kilitlenmeden tutarlı yedeğini almak için:

mkdir -p /var/backups/db
mysqldump --single-transaction --quick --routines --triggers --events \
  --all-databases | gzip > /var/backups/db/tum-db-$(date +%F).sql.gz

Yeni MariaDB sürümlerinde aynı araç mariadb-dump adıyla da bulunur. Komutun parola sormadan çalışması için MariaDB'de root kullanıcısının soket kimlik doğrulamasını kullanabilir ya da kimlik bilgilerini izinleri 600 olan /root/.my.cnf dosyasında tutabilirsiniz. PostgreSQL için:

sudo -u postgres pg_dump -Fc veritabani_adi > /var/backups/db/veritabani_adi.dump

restic ile Şifreli ve Artımlı Uzak Yedek

restic, verileri istemci tarafında şifreleyen, yalnızca değişen blokları gönderen (artımlı) ve tekrar eden veriyi tekilleştiren açık kaynaklı bir yedekleme aracıdır. Yedek hedefi olarak SFTP erişimli başka bir sunucu, S3 uyumlu depolama veya restic rest-server kullanılabilir. Benzer özelliklere sahip Borg da güçlü bir alternatiftir.

Kurulum

# Ubuntu 22.04 / 24.04
sudo apt install restic

# AlmaLinux 9
sudo dnf install epel-release
sudo dnf install restic

Depoyu oluşturma ve ilk yedek

Aşağıdaki örnekte yedekler, SSH anahtarıyla erişilebilen ayrı bir yedek sunucusuna SFTP üzerinden gönderilir. Komutları root olarak çalıştırın:

# Depo parolasını güvenli bir dosyada saklayın
openssl rand -base64 32 > /root/.restic-parola
chmod 600 /root/.restic-parola
export RESTIC_PASSWORD_FILE=/root/.restic-parola
export RESTIC_REPOSITORY=sftp:yedek@YEDEK_SUNUCU:/srv/restic/sunucu1

restic init
restic backup /etc /var/www /var/backups/db --exclude-caches
restic snapshots

Depo parolasını mutlaka sunucu dışında da güvenli bir yerde saklayın. Parolayı kaybederseniz yedekleriniz kalıcı olarak okunamaz hâle gelir.

Saklama politikası ve doğrulama

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

Bu politika son 7 günün günlük, son 4 haftanın haftalık ve son 6 ayın aylık yedeğini saklar; diğerlerini siler ve kullanılmayan veriyi temizler. restic check deponun bütünlüğünü doğrular.

Otomatikleştirme

Veritabanı dökümü, restic yedeği ve temizlik adımlarını bir betikte birleştirip her gece çalıştırabilirsiniz. Örneğin /usr/local/sbin/yedekle.sh adlı betiği oluşturup çalıştırılabilir yaptıktan sonra root kullanıcısının crontab -e ile açılan zamanlama tablosuna şu satırı ekleyin:

0 3 * * * /usr/local/sbin/yedekle.sh >> /var/log/yedek.log 2>&1

Cron sözdizimi ve zamanlama örnekleri için Linux cron job rehberimize göz atabilirsiniz. Yedek işinin başarısız olduğunda size haber vermesi de en az yedek almak kadar önemlidir; günlük dosyasını izleyen ya da başarısızlıkta e-posta gönderen basit bir kontrol ekleyin.

Fidye Yazılımına Karşı Yedeklerinizi Koruyun

Saldırgan üretim sunucusunu ele geçirdiğinde, o sunucudan yedek deposuna tam yazma ve silme yetkisi varsa yedekleri de silebilir. Bu riski azaltmak için:

• Yalnızca ekleme (append-only) modu kullanın: restic rest-server ve Borg, istemcinin yeni yedek ekleyebildiği ama eskileri silemediği bir modu destekler. Temizlik işlemini yedek sunucusu tarafında, ayrı yetkiyle yapın.
• Çekme (pull) modelini değerlendirin: Yedek sunucusunun üretim sunucusuna bağlanıp veriyi çekmesi, üretim sunucusuna yedek deposuna erişim yetkisi vermeme imkânı sağlar.
• Ayrı kimlik bilgileri kullanın: Yedek sunucusunun parolaları ve anahtarları üretim sunucusunda bulunmasın.
• Değiştirilemez bir kopya tutun: Nesne kilitleme destekleyen depolama ya da düzenli olarak çevrim dışı alınan bir kopya, son savunma hattıdır.

Yeni bir sunucuda yedeklemenin diğer güvenlik adımlarıyla birlikte nasıl planlanacağını yeni VDS'te ilk 10 güvenlik adımı yazımızda bulabilirsiniz.

Geri Yükleme Testi: Yedeğin Gerçek Sınavı

Hiç geri yüklenmemiş bir yedek, yalnızca bir varsayımdır. Belirli aralıklarla, örneğin üç ayda bir, şu testi yapın:

1. Yedekten dosyaları geçici bir dizine geri yükleyin: restic restore latest --target /tmp/geri-yukleme
2. Veritabanı dökümünü ayrı bir test veritabanına içe aktarın ve tabloların eksiksiz olduğunu kontrol edin.
3. Mümkünse ayrı bir test sunucusunda siteyi veya uygulamayı yedekten ayağa kaldırın.
4. Geçen süreyi ölçün ve RTO hedefinizle karşılaştırın.
5. Adımları ve karşılaştığınız sorunları belgeleyin; gerçek bir felakette bu belge en değerli kaynağınız olur.

Yedekleri Nerede Saklamalı?

Yedek hedefi, üretim sunucusundan bağımsız olmalıdır. Pratik seçenekler arasında aynı veri merkezinde ayrı bir sanal sunucu, farklı bir lokasyondaki ikinci bir sunucu, ofisinizdeki bir depolama cihazı ya da nesne depolama hizmetleri bulunur. Büyük veri hacimleri ve uzun saklama süreleri için yüksek disk kapasiteli dedicated sunucular veya kendi depolama donanımınızı sunucu barındırma (colocation) hizmetiyle veri merkezine yerleştirmek ekonomik çözümler olabilir. Küçük projeler için ise yedek hedefi olarak kullanılacak ek bir VDS çoğu zaman yeterlidir.

Kişisel veri içeren yedeklerde şifreleme ve saklama lokasyonu yasal bir gerekliliktir. Bu konunun ayrıntılarını KVKK ve sunucu lokasyonu yazımızda ele aldık.

Sık Sorulan Sorular

Ne sıklıkla yedek almalıyım?

Sıklığı, kaybetmeyi göze alabileceğiniz veri miktarı belirler. Sık değişen veritabanları için günde birden fazla, nadiren değişen dosyalar için günlük yedek çoğu senaryoda yeterlidir.

Snapshot almak yedek yerine geçer mi?

Hayır. Snapshot hızlı geri dönüş için idealdir ama genellikle aynı altyapı üzerinde durur. Bağımsız bir lokasyondaki yedeğin yerini tutmaz; ikisi birlikte kullanılmalıdır.

Yedeklerimi şifrelemem gerekir mi?

Evet, özellikle yedekler üçüncü taraf bir depolama alanında veya farklı bir lokasyonda tutuluyorsa. restic ve Borg verileri varsayılan olarak istemci tarafında şifreler.

Windows VDS'i nasıl yedeklerim?

Windows Server'da Windows Server Yedekleme özelliğini Sunucu Yöneticisi'nden veya PowerShell'de Install-WindowsFeature Windows-Server-Backup komutuyla etkinleştirip ağ paylaşımına zamanlanmış yedek alabilirsiniz. 3-2-1 kuralı Windows için de aynen geçerlidir.

Yedeğin çalıştığından nasıl emin olurum?

Yalnızca yedek işinin hatasız bitmesi yeterli değildir. Düzenli geri yükleme testleri yapın, depo bütünlüğünü kontrol edin ve yedek işinin başarısızlığında bildirim alacağınız bir izleme kurun.

Etkili bir sunucu yedekleme stratejisi; 3-2-1 kuralı, iş ihtiyacına göre belirlenmiş RPO ve RTO hedefleri, şifreli ve otomatik yedekler ve düzenli geri yükleme testlerinden oluşur. Bugün kurduğunuz basit bir yedek düzeni, yarın yaşanabilecek bir veri kaybını küçük bir aksaklığa dönüştürebilir.