Bir disk arızası genellikle önceden haber vermez; sabah sunucu normal çalışırken öğleden sonra tamamen açılmaz hâle gelebilir. Yedekleme stratejisi olmayan bir sistemde bu, aylarca biriken müşteri verisinin veya kod tabanının tek seferde kaybolması demektir. Fidye yazılımı saldırıları da benzer bir tehdit oluşturur: dosyalarınız şifrelenip erişilemez hâle gelir. Bu durumda tek çıkış yolu, saldırıdan önceki temiz bir yedeğe dönmektir. Bu yazıda gerçek komutlar ve somut bir plan üzerinden, hem küçük bir web sitesi hem de bir sunucu filosu için işleyen yedekleme stratejilerini ele alıyoruz.
Yedekleme, ara sıra elle alınan bir kopya değil, test edilmiş ve otomatikleştirilmiş bir süreçtir. Aşağıdaki adımlar bu süreci baştan sona kurmanız için gereken pratik bilgiyi veriyor.
3-2-1 kuralı ve pratik uygulaması
3-2-1 kuralı, verinin 3 kopyasının 2 farklı depolama türünde tutulmasını, bu kopyalardan 1 tanesinin de saha dışında (farklı bir fiziksel konumda) durmasını önerir. Bu dağılım, tek bir noktanın bozulmasının bütün yedekleri birlikte götürmesini engeller.
Pratikte bu kural şöyle karşılık bulur:
- 1. kopya: Üretim sunucusundaki canlı veri.
- 2. kopya: Aynı sunucuda veya yerel ağda, farklı bir diskte tutulan yedek.
- 3. kopya: Bulut depolama servisinde (S3, Backblaze B2 gibi) tutulan saha dışı yedek.
Bir web sunucusunda bu kuralı uygulamanın en basit yolu, günlük bir yedek betiği yazıp çıktıyı hem yerel bir dizine hem de uzak bir depolama alanına göndermektir. Aşağıdaki betik, veritabanını ve dosya sistemini tek seferde yedekler.
#!/bin/bash
TARIH=$(date +%Y%m%d)
mysqldump -u yedek_kullanici -p'parola' veritabani > /yedekler/db_$TARIH.sql
tar -czf /yedekler/dosyalar_$TARIH.tar.gz /var/www/site
Tam, artımlı ve diferansiyel yedekleme
Tam yedekleme, tüm veriyi baştan sona kopyalar. En güvenilir yöntemdir ama zaman ve depolama alanı açısından da en pahalısıdır. Büyük bir dosya sunucusunda her gece tam yedek almak, hem yedekleme penceresini uzatır hem de depolama maliyetini artırır.
Artımlı yedekleme yalnızca son yedeklemeden bu yana değişen dosyaları kopyalar. Bu yüzden hem hızlıdır hem de az yer kaplar. rsync aracı, artımlı yedeklemeyi Linux sunucularda kurmanın en yaygın yoludur.
rsync -avz --delete /var/www/site/ /yedekler/site_guncel/
--delete bayrağı, kaynakta silinen dosyaların yedekte de silinmesini sağlar; böylece yedek kaynakla birebir aynı kalır. Yedeklemede sık kullanılan rsync aracının tüm seçeneklerini resmi belgelerinde bulabilirsiniz. Diferansiyel yedekleme ise son tam yedekten bu yana değişen her şeyi kopyalar. Artımlıya göre biraz daha fazla yer kaplar ama geri yükleme sırasında yalnızca iki yedeği (tam yedek ve son diferansiyel yedek) birleştirmeniz yeterli olur.
Otomatik yedekleme kurulumu
Manuel yedekleme er ya da geç unutulur. Bu yüzden yedekleme betiğini cron ile zamanlamak, sürecin güvenilirliğinin temel şartıdır. Aşağıdaki cron girdisi, yukarıdaki betiği her gece saat 03:00'te otomatik çalıştırır.
crontab -e
# Aşağıdaki satırı ekleyin:
0 3 * * * /usr/local/bin/yedekle.sh >> /var/log/yedekleme.log 2>&1
>> /var/log/yedekleme.log 2>&1 kısmı, hem normal çıktıyı hem hata mesajlarını bir günlük dosyasına yazar. Betik sessizce başarısız olduğunda bunu fark etmenizin tek yolu bu günlüktür. Günlük dosyasını haftada bir kontrol etmek veya betiğin sonuna bir bildirim (e-posta, Slack webhook) eklemek, yedek alındığını sandığınız ama aslında hiç çalışmadığı bir durumu önceden yakalamanızı sağlar.
Bulut sunuculardaki yönetilen veritabanı hizmetleri (RDS, Cloud SQL gibi) genellikle otomatik anlık görüntü (snapshot) özelliği sunar; bu özelliği açık bırakmak, kendi betiğinizi yazmadan temel bir koruma sağlar. Ancak yönetilen yedekleme bile 3-2-1 kuralındaki saha dışı bağımsız kopya ilkesini tam karşılamayabilir, çünkü veriler genellikle aynı bulut sağlayıcının altyapısında kalır.
Yedekleri şifrelemek ve güvenli saklamak
Bir yedek dosyası, orijinal veri kadar hassastır; ele geçirildiğinde aynı zararı verir. Yedekleri bulut depolamaya göndermeden önce şifrelemek bu riski ortadan kaldırır.
tar -czf - /var/www/site | gpg --symmetric --cipher-algo AES256 -o dosyalar_$TARIH.tar.gz.gpg
Bu komut, dosyaları sıkıştırırken aynı anda AES256 ile şifreler. Sonuç dosyasını yalnızca doğru parolayı bilen biri açabilir. Geri yükleme sırasında aynı parolayla gpg --decrypt komutunu kullanmanız yeterlidir.
Yedeklere erişimi de sınırlamak gerekir; yedek dosyalarının bulunduğu dizine yalnızca yedekleme işlemini çalıştıran kullanıcının erişimi olmalıdır.
chmod 700 /yedekler
chown yedek_kullanici:yedek_kullanici /yedekler
Bulut depolama tarafında da bucket'ı herkese açık bırakmamak ve erişim anahtarlarını kod deposuna commit etmemek gerekir; bunlar temel ama sık atlanan güvenlik adımlarıdır. Erişim anahtarlarını ortam değişkeninde veya ayrı bir gizli anahtar yöneticisinde tutmak, bu anahtarların yanlışlıkla bir GitHub deposuna sızmasını önleyen basit bir alışkanlıktır.
Yedekleri test etmek
Alınan bir yedeğin çalıştığından emin olmanın tek yolu, onu gerçekten geri yüklemeyi denemektir. Test edilmemiş bir yedek, ihtiyaç anına kadar bozuk olduğu fark edilmeyen bir risk taşır.
Geri yükleme testini yalnızca veritabanı için değil, tüm sistem için de düşünmek gerekir. Bir sunucunun sıfırdan, yalnızca yedeklerden ayağa kalkabildiğini doğrulamak, gerçek bir felaket senaryosuna en yakın provadır.
Basit bir geri yükleme testi şu adımları izler:
- Yedek dosyasını ayrı bir test sunucusuna veya konteynerine kopyalayın.
- Veritabanı yedeğini boş bir test veritabanına geri yükleyin:
mysql -u root -p test_db < db_20260701.sql - Dosya yedeğini ayıklayıp birkaç kritik dosyanın açılabildiğini doğrulayın.
- Sonucu bir kontrol listesine not edin ve tarihini kaydedin.
Bu testi ayda bir tekrarlamak, yedekleme sisteminizdeki bir bozulmayı gerçek bir felaketten önce yakalamanızı sağlar. Büyük ekiplerde bu test süreci, felaket kurtarma tatbikatının (disaster recovery drill) bir parçası olarak takvime bağlanır.
Test sırasında geri yüklenen verinin güncelliğini de kontrol etmek gerekir. Bazen yedekleme betiği çalışır ama yanlış veritabanını veya eski bir dizini yedekler; bu hata yalnızca gerçek bir geri yükleme denemesinde ortaya çıkar.
Felaket kurtarma süresi hedefleri
Bir felaket kurtarma planının iki temel metriği vardır. RPO (Recovery Point Objective), ne kadar veri kaybını göze alabileceğinizi tanımlar. RTO (Recovery Time Objective) ise sistemi ne kadar sürede tekrar ayağa kaldırmanız gerektiğini tanımlar. Günde bir yedek alan bir sistemde RPO en kötü ihtimalle 24 saattir; bu süre kritik bir e-ticaret sitesi için kabul edilemez olabilir.
RPO'yu kısaltmak için yedekleme sıklığını artırmak (örneğin saatlik artımlı yedekler almak) veya veritabanı replikasyonu kurmak gerekir. RTO'yu kısaltmak ise genellikle önceden hazırlanmış bir kurtarma betiği, güncel dokümantasyon ve düzenli tatbikatla mümkün olur; kurtarma adımlarını ilk kez gerçek bir kriz anında öğrenmek süreci gereksiz yere uzatır.
Küçük bir ekip için bile bu iki metriği yazılı hâle getirmek faydalıdır: "En fazla 4 saatlik veri kaybını kabul ediyoruz, sistemi 2 saat içinde ayağa kaldırmalıyız" gibi somut bir hedef, hangi yedekleme sıklığının yeterli olduğunu netleştirir. Bu hedef olmadan alınan yedekler, gerçek ihtiyacı karşılayıp karşılamadığı belirsiz bir güvenlik hissi yaratır. Hedefleri belirledikten sonra mevcut yedekleme sıklığınızı gözden geçirip RPO hedefinizi gerçekten karşılayıp karşılamadığını kontrol etmek, kağıt üzerinde iyi görünen bir planın pratikte işe yarayıp yaramadığını gösterir.
Bir yedekleme sistemi ancak geri yüklendiğinde işe yarar. 3-2-1 dağılımını kurmak, betikleri cron ile otomatikleştirmek ve ayda bir gerçek bir geri yükleme provası yapmak, bir veri koruma planını kağıt üzerindeki bir niyetten gerçekten çalışan bir sürece dönüştürür.
Yazan Celil Uyanikoglu
Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.
Henüz yorum yok.
Sohbete katıl. Yorumlar yayınlanmadan önce moderasyondan geçer.