Sunucu Yedekleme Stratejisi: 3-2-1 Kuralı, RPO/RTO ve Geri Dönüş Testi

Sunucu yedekleme stratejisi, verinin ne sıklıkla, nereye ve nasıl yedekleneceğini iş hedeflerine göre belirler. Temel yaklaşım 3-2-1 kuralıdır: verinin 3 kopyası, 2 farklı ortamda ve en az 1'i başka bir lokasyonda tutulur. Ne kadar veri kaybının (RPO) ve kesinti süresinin (RTO) kabul edilebileceği yedek sıklığını belirler. Geri yüklenmesi test edilmemiş bir yedek güvenilir sayılmaz.

Bu rehberde yedek türlerini, saklama yerlerini, fidye yazılımına karşı korumayı ve geri dönüş testini adım adım ele alıyoruz. Son bölümde sağlayıcının aldığı yedeğin bu stratejide nereye oturduğunu anlatıyoruz; yedeklerinizi sunucu yönetimiyle birlikte düşünmek isterseniz sunucu yönetimi ve veri kurtarma desteği sayfasına da göz atabilirsiniz.

Yedekleme neden plan gerektirir?

Çünkü veri kaybının tek bir nedeni yok ve her neden farklı bir önlem ister. Disk arızası, yanlışlıkla çalıştırılan bir silme komutu, hatalı bir güncelleme, fidye yazılımı, ele geçirilen bir yönetici hesabı ya da fark edilmeden bozulan bir veritabanı tablosu aynı sonuca götürür, ama aynı yedek hepsine çözüm olmaz.

Plansız yedeklemenin en tipik hali, sunucudaki bir cron işinin her gece aynı diske bir arşiv yazmasıdır. Disk arızalandığında ya da sunucu ele geçirildiğinde bu yedek de veriyle birlikte gider. RAID ve replikasyon da yedek değildir: bir dosyayı sildiğinizde ya da fidye yazılımı veriyi şifrelediğinde, bu değişiklik anında tüm kopyalara yansır. Yedeği yedek yapan, verinin geçmişteki bir halini bağımsız bir yerde saklamasıdır.

3-2-1 kuralı (ve 3-2-1-1-0)

Önemli her verinin biri asıl olmak üzere 3 kopyası, 2 farklı ortam türünde ve 1'i başka bir lokasyonda tutulur. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) kuralı bu şekilde tanımlar.

• 3 kopya: Asıl veri ve iki yedek. Bir yedek bozulursa diğeri kalır.
• 2 farklı ortam: Kopyalar aynı türde bir arızadan birlikte etkilenmemelidir. Sunucu dünyasında bu, farklı depolama sistemleri, farklı hesaplar ya da farklı sağlayıcılar anlamına gelir.
• 1 farklı lokasyon: Kopyalardan biri başka bir binada, başka bir şehirde ya da başka bir sağlayıcıda durur. Yangın, sel veya veri merkezi çapında bir sorun tüm kopyaları aynı anda götürmez.

Yedekleme sektöründe yaygınlaşan 3-2-1-1-0 genişletmesi iki madde ekler: kopyalardan biri çevrimdışı ya da değiştirilemez (immutable) olmalı ve geri yükleme doğrulamasında sıfır hata çıkmalıdır. İlk ek madde fidye yazılımına, ikincisi ise "yedek var ama açılmıyor" durumuna karşıdır.

Tipik bir web sunucusu için uygulaması şöyle olabilir: asıl veri sunucuda, ikinci kopya aynı veri merkezinde ayrı bir yedek sisteminde, üçüncü kopya başka bir lokasyondaki şifreli ve değiştirilemez bir nesne depolamada.

RPO ve RTO nedir?

RPO ne kadar veri kaybedebileceğinizi, RTO ne kadar süre kapalı kalabileceğinizi tanımlar. Yedek sıklığı RPO'dan, geri yükleme yöntemi RTO'dan türetilir.

RPO (Recovery Point Objective, kurtarma noktası hedefi), bir felakette geri dönebileceğiniz en son noktanın ne kadar geride kalabileceğidir. Günde bir yedek alıyorsanız en kötü durumda yaklaşık 24 saatlik veriyi kaybedersiniz; haftada bir yedekte bu süre yedi güne çıkar. RTO (Recovery Time Objective, kurtarma süresi hedefi) ise arızadan sonra hizmetin yeniden çalışır hale gelmesi için kabul edilebilir en uzun süredir. RTO; yedeğin boyutuna, indirme hızına, sunucunun ne kadar sürede yeniden kurulabildiğine ve bu işi kimin yaptığına bağlıdır. NIST'in acil durum planlama rehberi SP 800-34 de bu hedeflerin iş etkisi analiziyle belirlenmesini önerir.

İş etkisine göre hedef belirleme

Hedefi teknik ekip değil, kesintinin maliyetini bilen iş tarafı belirlemelidir. Aşağıdaki değerler karar vermeyi kolaylaştıracak örneklerdir, standart değildir:

RPO sıfıra yaklaştıkça maliyet hızla artar. Bu yüzden her sistem için aynı hedef konmaz; önce en kritik veritabanı belirlenir, gerisi daha gevşek hedeflerle planlanır.

Yedek türleri

Yedekler ne kadarının kopyalandığına göre tam, artımlı ve fark yedeği; neyin kopyalandığına göre dosya ve veritabanı yedeği olarak ayrılır. Snapshot ise tek başına bir yedek türü sayılmaz.

Tam, artımlı ve fark yedeği

restic ve BorgBackup gibi modern araçlar bu ayrımı büyük ölçüde ortadan kaldırır. Veriyi parçalara ayırıp yalnızca daha önce görülmemiş parçaları saklarlar; buna tekilleştirme (deduplication) denir. Her yedek bir tam yedek gibi geri yüklenir ama yalnızca değişen kısım kadar yer kaplar.

Dosya ve veritabanı yedeği

Çalışan bir veritabanının dosyalarını, örneğin /var/lib/mysql dizinini, doğrudan kopyalamak tutarsız bir yedek üretir; kopyalama sürerken veri değişmeye devam eder. Veritabanını ya kendi yedek aracıyla mantıksal olarak dışa aktarın ya da tutarlı fiziksel yedek alan bir araç kullanın. InnoDB tablolar için --single-transaction seçeneği, tabloları kilitlemeden tutarlı bir döküm alır:

set -o pipefail
mysqldump --single-transaction --routines --triggers --all-databases | gzip > /root/db-dump/tum-veritabanlari-$(date +%F).sql.gz

pipefail, mysqldump hata verdiğinde betiğin bunu fark etmesini sağlar; aksi halde gzip başarılı olduğu için hata gizlenir. Bu komutu crontab satırına yazacaksanız % işaretlerini ters eğik çizgiyle kaçırın. MariaDB'de aynı işi mariadb-dump yapar. MySQL belgeleri, mysqldump'ın büyük veri hacimleri için hızlı ya da ölçeklenebilir bir çözüm olmadığını, büyük veritabanlarında fiziksel yedeğin daha uygun olduğunu belirtir. Dosya yedeğine ise uygulama dizinleriyle birlikte /etc altındaki yapılandırmayı, SSL sertifikalarını ve cron tanımlarını da ekleyin; sunucuyu yeniden kurarken ilk aranan şeyler bunlardır.

Snapshot yedek midir?

Snapshot, bir diskin belirli bir andaki halinin depolama katmanında dondurulmasıdır. Hızlıdır ve güncelleme öncesi geri dönüş noktası olarak çok kullanışlıdır. Ancak tek başına yedek sayılmaz: çoğunlukla asıl diskle aynı depolama sisteminde durur, o sistem arızalanırsa snapshot da kaybolur. Ayrıca çalışan bir veritabanının snapshot'ı, elektrik kesilmiş bir sunucuya benzer biçimde yalnızca çökme tutarlıdır (crash-consistent); veritabanı çoğu zaman açılır ama bunun garantisi yoktur. Snapshot'ı yedek stratejisinin hızlı geri dönüş katmanı olarak kullanın, bağımsız yedeğin yerine değil.

Yedek nereye alınmalı?

En az bir kopya, sunucuyla aynı arıza alanını paylaşmayan, yani farklı bir veri merkezinde ya da farklı bir sağlayıcıda duran bir yere alınmalıdır.

Nesne depolama, dosyaları dizin yapısı yerine bir API üzerinden erişilen nesneler olarak saklayan depolama türüdür; S3 uyumlu olması, Amazon S3 API'sini konuşan araçlarla kullanılabileceği anlamına gelir. Yurt dışında bir depolama seçecekseniz, kişisel veri içeren yedeklerin yurt dışına aktarımının KVKK açısından ayrıca değerlendirilmesi gerektiğini de hesaba katın.

Güvenlik: şifreleme ve değiştirilemez yedek (fidye yazılımı)

Yedekler sunucudan çıkmadan şifrelenmeli ve sunucuyu ele geçiren birinin yedekleri silemeyeceği bir düzen kurulmalıdır.

Yedek kopyalar, çoğu zaman asıl sistemden daha az korunan ama aynı veriyi taşıyan kopyalardır. restic ve BorgBackup veriyi istemci tarafında, yani sunucudan çıkmadan şifreler. BorgBackup belgeleri bu şifrelemenin 256 bit AES ve bütünlük doğrulaması için HMAC-SHA256 kullandığını belirtir. Şifreleme anahtarını ya da parolasını yalnızca sunucuda tutmayın; sunucu kaybolursa şifreli yedek de açılamaz hale gelir. Anahtarın bir kopyasını parola yöneticisinde veya fiziksel bir kasada saklayın.

Fidye yazılımı saldırılarında saldırganlar bilinçli olarak önce yedekleri hedefler. Sunucuda yedek deposunu silme yetkisi olan bir kimlik bilgisi varsa, root yetkisi ele geçiren saldırgan da o yetkiye sahip olur. Buna karşı üç yöntem kullanılır:

• Yalnızca ekleme (append-only) modu: BorgBackup deposu bu modda çalıştırıldığında Borg, kaydedilmiş veriyi asla üzerine yazmaz ya da silmez. Bu modda prune ve delete komutları yer açmaz, yalnızca silme işareti koyar; eski yedeklerin temizliğini güvenilir ayrı bir makineden yapmanız gerekir.
• Nesne kilidi: Birçok S3 uyumlu depolama hizmeti, nesnelerin belirli bir süre boyunca silinmesini ve değiştirilmesini engelleyen nesne kilidi (object lock) özelliği sunar.
• Çekme (pull) modeli: Yedek sunucusu verileri kendisi çeker; asıl sunucuda yedek deposuna erişen hiçbir kimlik bilgisi bulunmaz.

Sunucunun kendisini sıkılaştırmak da yedek güvenliğinin parçasıdır; bu konuyu Linux sunucu güvenliği rehberinde adım adım anlattık.

Geri dönüş testi nasıl yapılır?

Rastgele seçilen bir yedek, asıl sunucudan ayrı bir ortama gerçekten geri yüklenir; ardından uygulamanın çalıştığı doğrulanır ve geçen süre ölçülür.

1. Yedek seçin: Hep en son yedeği değil, zaman zaman daha eski bir tarihi seçin; eski yedeklerin de açıldığını görmek gerekir.
2. Ayrı ortam hazırlayın: Testi canlı sunucunun üzerine yapmayın. Kısa süreli bir test sunucusu ya da izole bir dizin kullanın.
3. Geri yükleyin ve süreyi tutun: İndirme, açma, veritabanını içe aktarma ve servisleri başlatma adımlarının toplam süresi sizin gerçek RTO'nuzdur.
4. Doğrulayın: Uygulama açılıyor mu, veritabanındaki son kaydın tarihi beklenen RPO ile uyumlu mu, önemli tablolardaki kayıt sayıları mantıklı mı, yüklenen dosyalar yerinde mi?
5. Kaydedin: Tarihi, kullanılan yedeği, süreyi ve karşılaşılan sorunları yazın. Eksik bir adım bulduysanız yedek betiğini ya da dokümantasyonu hemen düzeltin.

Kritik sistemlerde bu testi ayda bir yapın. Bunun yanında yedek deposunun bütünlüğünü de düzenli kontrol edin; restic'te restic check --read-data-subset=1/10 komutu deponun onda birlik bir bölümünü okuyarak doğrular; her çalıştırmada 2/10, 3/10 gibi farklı bir bölüm seçerseniz zamanla verinin tamamını kontrol etmiş olursunuz. Testin takvime nasıl yerleşeceğini sunucu bakım kontrol listesi yazısında gösterdik.

Araçlar: rsync, restic, BorgBackup, panel yedekleri

Araçların rolü farklıdır: rsync dosyaları kopyalar, restic ve BorgBackup sürümlü ve şifreli yedek alır, panel yedekleri ise hesap bazında pratik ama sunucuya bağımlı bir katman sunar.

restic ile uzak bir SFTP sunucusuna şifreli yedek almanın temel akışı şöyledir:

export RESTIC_REPOSITORY="sftp:yedek@yedek.ornek.com:/srv/restic/web01"
export RESTIC_PASSWORD_FILE="/root/.restic-parola"

restic init
restic backup /etc /var/www /root/db-dump
restic snapshots
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic restore latest --target /tmp/geri-donus-testi

forget --prune komutu, saklama politikasının dışında kalan eski yedekleri kalıcı olarak siler. Politikayı ilk kez uygulamadan önce --dry-run ile hangi yedeklerin silineceğini görün. Örnekteki politika 7 günlük, 4 haftalık ve 6 aylık yedek tutar; bu yaklaşım, yakın geçmişe ayrıntılı, uzak geçmişe seyrek erişim sağlar. Yedek işlerinin başarısız olduğunu da bir izleme sisteminin size bildirmesi gerekir; sessizce duran bir yedek işi, çoğu zaman ancak ihtiyaç anında fark edilir.

Sağlayıcının yedeği ile sizin yedeğiniz

Sağlayıcının aldığı yedek değerli bir katmandır, ama tek başına 3-2-1 stratejisi değildir. Onu stratejinizin kopyalarından biri olarak sayın, tamamı olarak değil.

Bulutzone'da VDS paketlerinde haftalık yedekleme dahildir. Bu tür bir sağlayıcı yedeğinin sizin stratejinize katkısını değerlendirirken şu noktaları göz önünde tutun:

• Sıklık RPO'nuzu belirler: Haftalık bir yedekte en kötü durumda yaklaşık bir haftalık veri kaybı yaşanabilir. Günlük sipariş alan bir site için bu genellikle kabul edilemez; aradaki boşluğu kendi günlük veritabanı yedeğinizle kapatmanız gerekir.
• Tek bir kopyadır: 3-2-1'in "3 kopya" ve "2 farklı ortam" koşulunu tek başına karşılamaz.
• Aynı idari alandadır: Sunucu ile yedeği aynı sağlayıcıda ve aynı müşteri hesabı altında durur. Hesap düzeyinde bir sorun ya da yanlış bir işlem ikisini birden etkileyebilir; en az bir kopyanın başka bir sağlayıcıda ya da kendi kontrolünüzdeki bir ortamda olması bu riski kaldırır.
• Ayrıntıları sorun: Yedeklerin kaç hafta saklandığını, nerede tutulduğunu, veritabanları için tutarlılığın nasıl sağlandığını ve geri yükleme talebinin nasıl işlediğini sipariş öncesinde yazılı olarak öğrenin. Bu cevaplar, sağlayıcı yedeğinin RTO hesabınızdaki yerini belirler.

Hizmetin sözleşmesel çerçevesi için Bulutzone yedekleme sözleşmesi metnini okuyun. Sunucu yönetimi sayfasında yönetim ekibinin yaptığı işler arasında veri kurtarma da listeleniyor; bir veri kaybı yaşadığınızda bu desteğin kapsamını önceden bilmek, kriz anında zaman kazandırır.

Sık sorulan sorular

Sunucu yedeği ne sıklıkla alınmalı?

Sıklığı RPO hedefiniz belirler. Az değişen tanıtım siteleri için günlük yedek çoğu zaman yeterlidir; sipariş ya da kullanıcı verisi alan sistemlerde veritabanı saatlik ya da daha sık yedeklenmelidir. Dosyalar ile veritabanı için farklı sıklıklar belirlemek hem maliyeti hem riski dengeler.

RAID yedek yerine geçer mi?

Hayır. RAID tek bir diskin arızasında sunucunun çalışmaya devam etmesini sağlar, yani süreklilik içindir. Silinen bir dosya, şifrelenen bir veri ya da bozulan bir tablo tüm disklere aynı anda yazılır. Geçmişe dönmek için bağımsız ve sürümlü bir yedek gerekir.

Yedekler ne kadar süre saklanmalı?

Bir sorunun fark edilme süresinden daha uzun. Veri bozulması ya da sızma bazen haftalar sonra anlaşılır; yalnızca son yedi günü saklıyorsanız temiz bir kopya kalmamış olabilir. Günlük, haftalık ve aylık yedekleri kademeli tutan bir politika bu riski düşük maliyetle azaltır. Yasal saklama yükümlülüğü olan veriler için süreyi hukuk biriminizle belirleyin.

Mevcut yedeklerinizin 3-2-1'e ne kadar yakın olduğunu yukarıdaki tablolarla kontrol edin: kaç kopya var, kaçı farklı bir lokasyonda, en son ne zaman geri yükleme denendi? Yedek planınızı sunucu bakımı ve güvenlik takibiyle birlikte ele almak isterseniz sunucu yönetimi paketlerini inceleyin.

Kaynaklar

• CISA: Data Backup Options (PDF)
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• restic documentation
• BorgBackup documentation
• BorgBackup: Additional notes (append-only mode)
• MySQL 8.4 Reference Manual: mysqldump