Yedekleme stratejisi: 3-2-1 kuralından JetBackup saklama ayarlarına

Çoğu hosting firmasında yedekleme şöyle "çözülür": JetBackup kurulur, günlük bir iş tanımlanır, panelde yeşil tik görülür, konu kapanır. Sonra bir sabah /home bölümü salt okunur (read-only) moda düşer ya da bir müşteri yanlış eklentiyle veritabanını uçurur. Elinizdeki 40 günlük arşivin gerçekten açılıp açılmadığını ilk kez o gün öğrenirsiniz.

Bu yazı, yedeklemeyi "kurulmuş" durumdan "çalıştığı kanıtlanmış" duruma taşıyan adımları anlatıyor.

3-2-1 kuralı bir sunucuda tam olarak ne demek

Kural basit: 3 kopya, 2 farklı ortam, 1 tanesi dışarıda. Sunucuya uyarlandığında çoğu kurulumun aslında 1-1-0 olduğu ortaya çıkar:

• Yedekler sunucunun kendi diskinde, /backup altında duruyor
• Aynı RAID dizisi, aynı kasa, aynı rafta
• Uzak kopya "yakında ekleyeceğiz" listesinde bekliyor

RAID yedek değildir; disk arızasına karşı çalışmaya devam etmenizi sağlar, rm -rf karşısında hiçbir şey yapmaz. LVM ya da ZFS snapshot'ı da yedek değildir, çünkü kaynak veriyle aynı depolama havuzunda durur; havuz gittiğinde snapshot da gider.

İşleyen bir düzen genelde şuna benzer:

• Kopya 1 — yerel disk: ayrı bir fiziksel disk ya da NVMe. Amaç hız; tek dosya veya tek veritabanı geri dönüşü dakikalar içinde.
• Kopya 2 — ağdaki depolama sunucusu: SSH hedefi. Sunucu tamamen gittiğinde başvurulacak kopya.
• Kopya 3 — farklı sağlayıcıda nesne depolama: S3 uyumlu bir hedef. Veri merkezi düzeyindeki olaylar ve fidye yazılımı için.

Kuralın güncel hali 3-2-1-1-0 diye geçiyor: bir kopya değiştirilemez (immutable) ya da çevrimdışı olacak, doğrulama sonunda sıfır hata olacak. Eklenen bu iki rakam doğrudan fidye yazılımı senaryosuyla ilgili ve aşağıda tekrar karşımıza çıkacak.

Artımlı yedek gerçekte nasıl çalışıyor

Rakamla bakmak faydalı. 200 hesaplı, hesap başına ortalama 3 GB veri tutan bir sunucu: 600 GB.

• Her gece sıkıştırılmış tam yedek: 600 GB okunur, içeriğe göre 250-400 GB arşiv yazılır. 7 gün saklamak 2 TB'ın üzerinde alan ister ve her gece diski saatlerce meşgul eder.
• Sıkıştırılmamış (snapshot) yedek: ilk gece 600 GB, sonraki gecelerde yalnızca değişen dosyalar. Paylaşımlı hostingte günlük değişim tipik olarak %1-3 bandındadır, yani 6-18 GB.

JetBackup 5 bunu hardlink ile yapar. Her yedek klasörü, hesabın tam dizin ağacı gibi görünür; ama değişmemiş dosyalar, önceki yedekteki inode'a bağlanmış ikinci bir isimden ibarettir. Doğrulamak kolay:

• stat /backup/.../public_html/wp-includes/version.php çıktısındaki Links: değeri 14 ise, aynı inode'a 14 isim işaret ediyor demektir: canlı dosya ve onu paylaşan yedekler. Disk üzerinde bir kez yer kaplar.
• Tek bir yedek klasöründe du -sh çalıştırırsanız tam boyutu görürsünüz, bu yanıltıcıdır. Gerçek toplamı görmek için üst dizini tek çağrıda ölçün: du -h --max-depth=1 /backup/jetbackup5/
• Bu komutta -s kullanmayın; du, -s ile --max-depth birlikte verildiğinde çalışmadan hata döner. Tek çağrıda ölçtüğünüzde aynı inode ikinci kez sayılmaz; bu yüzden ilk klasör kocaman, sonrakiler küçük görünür. Anlamlı olan, en alttaki toplam satırıdır.

Geri yüklemedeki avantajı da buradan gelir: müşterinin sildiği tek bir dosyayı almak için 300 GB'lık arşivi açmanız gerekmez, doğrudan cp ile alırsınız.

Bedeli inode. Hardlink'in kendisi yeni inode tüketmez; ama her yedekte dizin ağacı yeniden kurulduğu için her klasör yeni bir inode alır, değişen ve yeni gelen her dosya da öyle. 200 hesap × ortalama 60.000 dosya, daha ilk kopyada 12 milyon dosya inode'u demektir; üzerine 30 saklama noktasının dizinleri ve her günün değişen dosyaları eklenir. Yedek diskini df -i ile izlemezseniz, disk %40 doluyken şu hatayla tanışırsınız:

No space left on device

Disk boş, inode bitmiş. ext4'ü daha yoğun bir inode oranıyla oluşturmak (mkfs.ext4 -i 8192, yani her 8 KB'a bir inode) ya da inode'ları dinamik ayıran XFS'i tercih etmek burada gerçek bir fark yaratır. Yedek diski kurulurken verilen bu karar, iki yıl sonra düzeltilmesi en pahalı karardır; çünkü düzeltmek, diski yeniden biçimlendirmek demektir.

Hardlink desteklemeyen hedeflerde ne oluyor

Bu genelde geç fark edilir: artımlı mantık dosya sistemi seviyesinde hardlink'e dayanır. Dolayısıyla artımlı yapı yalnızca hardlink destekleyen hedeflerde, yani yerel disk ve SSH tarafında çalışır. S3 uyumlu nesne depolama, Google Drive, Dropbox gibi hedeflerde hardlink kavramı yoktur; buralara yazarken arşiv tabanlı bir davranış devreye girer ve yerel diskteki verimliliğin aynısını beklememek gerekir.

Pratik sonucu şu: uzak hedefte sıklığı ve saklama sayısını yerelden farklı ayarlayın. Yerelde günlük 30 kopya makul olabilir; aynı politikayı S3'e uygularsanız hem depolama hem aktarım tarafında sürprizle karşılaşırsınız. Uzakta haftalık 8 + aylık 6 iyi bir başlangıçtır.

Uzak hedef neden pazarlık konusu değil

İlk gönderim planlanmadığında iş orada tıkanır. 600 GB'lık ilk aktarım, 100 Mbit/s uplink üzerinden teorik olarak yaklaşık 13 saat sürer (600.000 MB ÷ 12,5 MB/s ≈ 48.000 saniye); gerçek verim her zaman bunun altında kaldığı için pratikte daha uzun. Aynı sunucu gündüz müşteri trafiği taşıyorsa süre iyice açılır. İlk tam gönderimi hafta sonuna ya da düşük trafik penceresine denk getirin; sonraki günler zaten çok daha küçük olacaktır.

Hedef tipini seçerken:

• SSH/SFTP: hardlink çalışır, artımlı verimlilik korunur, trafik şifreli. Kendi depolama sunucunuz varsa en iyi seçenek.
• S3 uyumlu: dayanıklılık yüksek; sürüm (versioning) ve nesne kilidi (object lock) gibi özellikler var. Geri yüklemede çıkış trafiği ücretlendirilir, bunu tatbikat yaparken de hesaba katın.
• FTP: hâlâ destekleniyor ama düz FTP'de hem kimlik bilgileri hem veri ağda açık gider. Uzak hedef için tercihiniz SSH/SFTP olsun; FTP'yi ancak başka seçenek kalmadıysa kullanın.

Fidye yazılımı tarafında ince bir nokta var: JetBackup saklama kuralını uygulayabilmek için hedefte silme yetkisine ihtiyaç duyar. Yani sunucu ele geçirilirse, o kimlik bilgileriyle uzak kopya da silinebilir. Çözüm yetkiyi kısmak değil, hedef tarafında bunu telafi etmektir:

• Bucket üzerinde versioning + object lock açın; silinen nesne belirlenen süre boyunca geri getirilebilir kalsın.
• Ya da üçüncü kopyayı pull yöntemiyle alın: depolama sunucusu gidip çeksin, üretim sunucusu itmesin.

Saklama süresi: JetBackup'ta retention işi zamanlamada

JetBackup 5'te en çok yanlış anlaşılan konu bu. Saklama süresi yedek işine değil, zamanlamaya (Schedule) bağlıdır. Bir yedek işine birden çok zamanlama eklersiniz ve her birinin kendi "retain" değeri olur:

• Daily — retain 14
• Weekly — retain 8
• Monthly — retain 6

Bu üçü tek bir işte birleştiğinde klasik GFS (dede-baba-oğul) düzenini elde edersiniz: son iki hafta günlük, iki ay haftalık, yarım yıl aylık. JetBackup 4'ten gelenlerin en sık yaptığı hata, saklamayı hâlâ işin üzerinde aramaktır; sonuçta ellerinde sandıklarından çok daha kısa bir geçmiş kalır.

Karıştırılan ikinci ayar: silinen hesapların yedekleri. Bir hesabı sunucudan kaldırdığınızda yedekleri anında düşmez; bunların ne kadar süre duracağını ayrı bir kural yönetir. Yıllık faturalı bir müşteri iptal edip 40 gün sonra geri döndüğünde işinizi kurtaracak tek sayı budur. Politikanızı yazarken bu değeri bilinçli seçin, varsayılanla bırakmayın.

Üçüncü nokta: hedef tanımında ayrılmış boş alanı (Reserved Space) belirtmezseniz, saklama kuralı eski yedekleri silmeye fırsat bulamadan disk dolabilir ve kuyruk hata vermeye başlar. Yedek diskinin tamamını yedeklerin kullanımına açmayın; her zaman bir pay ayırın.

Geri yükleme testi yapılmayan yedek, yedek değildir

Bu cümle klişe ama çoğu firmada gerçekten hiç yapılmamış tek iş budur. Somut bir tatbikat şöyle görünür:

• Ayda bir, rastgele bir hesap seçin (en küçüğü değil).
• Test sunucusuna ya da farklı bir kullanıcı adına geri yükleyin.
• Dosya sayısını karşılaştırın: find /home/kullanici -type f | wc -l
• Kritik tablolarda satır sayısına bakın; bir WordPress için SELECT COUNT(*) FROM wp_posts; iyi bir ilk kontroldür.
• Siteyi kendi hosts dosyanızda test sunucusuna yönlendirip gerçekten açıldığını görün.
• Süreyi ölçün. "600 GB'ı geri yüklemek 5 saat 20 dakika sürüyor" bilgisi, hem sözleşme yazarken hem kriz anında elinizdeki en değerli sayıdır.

İki değeri de yazılı hale getirin: RPO (ne kadar veri kaybı kabul edilebilir — gece 03:00 yedeğiyle çalışıyorsanız en kötü senaryo yaklaşık 24 saattir) ve RTO (ne kadar sürede ayağa kalkıyorsunuz).

Tatbikatta en sık ortaya çıkan sürpriz, yedek işinin içerik seçiminde saklıdır. İş yalnızca ana dizini kapsayacak şekilde tanımlanmışsa geri yüklemede DNS bölgeleri, SSL sertifikaları, cron kayıtları, e-posta filtreleri ve FTP hesapları gelmez. Site açılır, kimse mail alamaz. Bunu gerçek bir olayda değil, tatbikatta öğrenmek çok daha ucuzdur.

Şifreleme kullanıyorsanız aynı disiplin anahtar için de geçerlidir: anahtar kaybolduğunda yedek kurtarılamaz. Anahtarı yedeklenen sunucunun dışında, ayrı bir yerde tutun ve tatbikatta anahtarı da test edin.

cPanel ve DirectAdmin tarafındaki pratik notlar

• JetApps deposu eklendikten sonra kurulum tek pakettir: cPanel için jetbackup5-cpanel, DirectAdmin için jetbackup5-directadmin. İki panelde de arayüz ve mantık büyük ölçüde aynıdır.
• JetBackup 5 kendi verisini MongoDB'de tutar. Loglar /usr/local/jetapps/var/log/jetbackup5/ altındadır; kuyruk takılmalarında ilk bakılacak yer burasıdır.
• Komut satırından iş listesi ve kuyruk kontrolü mümkündür: jetbackup5api -F listBackupJobs, jetbackup5api -F listQueueItems. İzleme betiklerinizi buradan besleyebilirsiniz.
• Son kullanıcıya kendi geri yüklemesini yaptırma özelliğini açmak destek yükünü ciddi biçimde düşürür. "Dün akşamki haline döndür" taleplerinin büyük kısmı size hiç ulaşmaz.
• Dürüst olmak gerekirse zayıf tarafı da var: ilk tam yedek sırasında MongoDB ve kuyruk süreçleri düşük RAM'li sunucularda hissedilir yük yaratır; 2 GB RAM'li bir makinede ilk gece I/O ve bellek baskısı beklenmelidir. JetBackup 4'ten geçenler için de arayüz ve kavramlar yeterince farklıdır, geçişi yoğun bir güne planlamayın.

Lisans tarafı basit: JetBackup lisansı sunucunun IP adresine bağlanır, anahtar dosyasına değil. Yedek sunucunuzu taşıdığınızda paneldeki IP'yi kendiniz değiştirirsiniz, eski adres anında durur. JetBackup lisansını ön ödemeli bakiyeden aktive ettiğinizde onay adımı beklenmez; kurulum sunucuda tek komuttur ve betik lisansı IP'den bulur. Aynı sunucudaki cPanel ya da DirectAdmin lisansını da aynı panelden yönetebilir, yedekleme lisanslarının tamamına tek yerden bakabilirsiniz.

Ama asıl mesele lisans değil. Yukarıdaki listeden bugün yapacağınız tek bir şey seçecekseniz, rastgele bir hesabı test sunucusuna geri yükleyin ve süreyi tutun. Sonuç, yedekleme stratejiniz hakkında panelde gördüğünüz tüm yeşil tiklerden daha çok şey söyleyecek.