Felaket kurtarma planı hatalarının çoğu fancy araç eksikliğinden kaynaklanmaz; varsayımlardan kaynaklanır. Yedeklemenin çalıştığını varsayarsınız, geri yüklemenin işe yarayacağını varsayarsınız, saat 03:00'te birinin ne yapacağını bileceğini varsayarsınız. Benim ortamımda bu varsayımların kurtarılabilir bir olayı tam bir haftalık downtime'a çevirdiğini gördüm. Karşılaştığım en büyük DR planı hataları test edilmemiş geri yüklemeler, tek lokasyonlu yedekler, dokümantasyon olmaması ve tanımlanmış RTO/RPO olmamasıdır. Son 30 günde yedekten geri yükleme yapmadıysanız, yedeğiniz yok; umudunuz var.
Geri Yükleme Testi Yapmamak #1 DR Hatasıdır
Bunu daha önce de söyledim ve söylemeye devam edeceğim: önceki yazımda yedekleme testi konusunda belirttiğim gibi (https://furkanikkan.com/urun/geri-yukleme-testi-olmayan-yedekleme-sadece-bosuna-disk-isgalidir-34), hiç geri yüklemediğiniz bir yedek sadece disk işgalidir. Ama felaket kurtarma planlamasında işler daha kritiktir çünkü sadece verinin geri gelip gelmediğini kontrol etmiyorsunuz; tüm geri yükleme sürecinin uçtan uca çalışıp çalışmadığını kontrol ediyorsunuz.
Benim ortamımda her ay yaptığım şey şu:
- Rastgele bir kritik sistem seçerim
- İzole bir VLAN'a geri yüklerim
- Boot ederim, servisleri doğrularım, uygulama loglarını kontrol ederim
- Tüm süreci süre tutarım
- Ne bozulduysa belgelerim ve gelecek aya kadar düzeltirim
Bunu ilk yaptığınızda bir şeyler bozulur. Mesele de bu. Planlı bir bakım penceresinde yapılan geri yükleme testi ucuzdur. Ransomware olayı sırasında yapılan geri yükleme testi ucuz değildir.
Tek Lokasyonlu Yedekler Sizi Öldürür
Küçük ve orta ölçekli ortamlarda en sık gördüğüm hata bu. Yedekleme sunucusu production SAN'ın hemen yanında durur, aynı raf'taki bir NAS'a replike eder ve herkes rahat uyur. Sonra binanın elektriği kesilir, yangın sprinkler'ları çalışır ya da biri rafı fiziksel olarak çalar.
Gerçek bir DR planı en az iki fiziksel lokasyonda iki kopya gerektirir. Ben 3-2-1 kuralını uygularım ve bundan taviz vermem:
- 3 veri kopyası (production + 2 yedek)
- 2 farklı medya tipi (disk + tape veya disk + object storage)
- 1 offsite ve offline kopya
Pratikte benim kurulumum şöyle: birincil yedek hızlı geri yüklemeler için yerel bir Proxmox Backup Server'a gider. İkinci kopya bir WireGuard tüneli üzerinden uzak bir PBS instance'ına senkronize olur. Üçüncü kopya versioning ve object lock aktif olan immutable S3 uyumlu object storage'a düşer. Ransomware yerindeki her şeyi şifrelerse, immutable kopya güvenlik ağıdır.
Tanımlanmış RTO ve RPO Yoksa Plan Yoktur
Biri size "ne kadar sürede geri döneriz?" diye sorduğunda cevabınız "duruma göre" ise DR planınız yoktur. DR temenniniz vardır.
RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) buzzword değildir; her yedekleme kararını yönlendiren sayılardır. Ne sıklıkla snapshot aldığınız, ne kadar retention tuttuğunuz, replike mi ettiğiniz yoksa sadece kopya mı aldığınız; hepsi bu iki sayıdan gelir.
Benim ortamımda, business impact'ın sahibi olan kişiyle otururum ve sistem bazında RTO/RPO tanımlarız. Cluster bazında değil, site bazında değil; sistem bazında. Bir file server 24 saatlik bir RPO'yu tolere edebilir ama müşteri portalının arkasındaki database 15 dakikaya ihtiyaç duyabilir. Bu sayılar yedekleme sıklığınızı ve storage maliyetinizi belirler.
Tek Bir Kişinin Kafasında Yaşayan Runbook'lar
Bu çok yaygın olduğu için can sıkıcı. Senior admin yedekleme sistemini kurmuştur, scriptleri yapılandırmıştır, hangi job ID'nin hangi VM'e denk geldiğini bilir ve sonra tatile çıkmıştır. Disk dolmuştur, yedekler altı gündür başarısızdır ve kimse fark etmemiştir çünkü tek alert o kişinin email'ine gider.
Ben, bir meslektaşımın beni aramadan 03:00'te takip edebileceği runbook'lar yazarım. Her birinde şunlar bulunur:
- Sistem ne yapıyor ve neden önemli
- Yedekler nerede (host, path, credentials vault referansı)
- Geri yüklemeyi nasıl tetikleyeceğiniz (tam komutlar veya UI adımları)
- Geri yüklemenin başarılı olduğunu nasıl doğrulayacağınız
- Bir şey yanlış görünce kime escalate edeceğiniz
Proxmox VM için bir geri yükleme runbook snippet'inin nasıl göründüğüne dair hızlı bir örnek:
# VM 104 için mevcut yedekleri listele
proxmox-backup-client snapshot list --repository root@pbs@backup-repo
# VM 104'ü en son snapshot'tan geri yükle
qmrestore /mnt/pbs/dump/vm-104-2024*.vma.zst 104 --storage local-lvm
# VM'in boot olduğunu doğrula ve ağı kontrol et
qm start 104 && qm guest cmd 104 network-get-interfacesRunbook'unuz "yedekten geri yükle" diyor ama hangi yedekten, hangi host'tan, hangi komutla olduğunu belirtmiyorsa; runbook değildir. Post-it'dir.
Immutable Storage ve Access Control'ü Görmezden Gelmek
Ransomware artık sadece production verisini şifrelemiyor. Modern varyantlar doğrudan yedekleme altyapısını hedef alır. Veeam console'larını, Proxmox yedekleme endpoint'lerini, yedek klasörleri içeren SMB share'lerini; ulaşabildikleri her şeyi arar. Yedekleme credential'larınız domain admin ise ve yedekleme share'iniz herkes tarafından yazılabilir durumdaysa, saldırgana güvenlik ağınızı yok etme imkanı vermişsinizdir.
Ben yedekleme sistemlerini taç mücevheri gibi ele alırım:
- Production domain ile paylaşılmayan ayrı admin credential'ları
- Network izolasyonu — user network'lerinden inbound olmayan yedekleme VLAN'ları
- Mümkün olduğunca immutable storage (object lock, WORM tape'ler, hold flag'li ZFS snapshot'ları)
- Yetkili olsa bile her yedek silme olayında alert
Saldırganlar yaratıcı olduğunda neler olduğunu anlamak istiyorsanız, gerçek saldırı senaryoları hakkındaki önceki yazıma bakın (https://furkanikkan.com/urun/saldirganlar-sirketleri-nasil-ihlal-eder-gercek-saldiri-senaryolari-41). Yedekleme sunucusu her zaman hedef listesindedir.
DR Plan'larının Süresi Doluyor Unutmak
İki yıl önce yazılan bir DR planı bugün muhtemelen yanlıştır. VM'ler eklenmiştir, storage path'leri değişmiştir, biri credential'ları rotate etmiştir ve runbook'u güncellememiştir, offsite replikasyon hedefi üç ay önce dolmuştur ve kimse fark etmemiştir.
Ben her çeyrek bir DR review planlarım. Her seferinde tam drill değil; ama minimum olarak şunları doğrularım:
- Yedekleme job'larının hala çalıştığını ve başarılı olduğunu
- Retention policy'lerinin mevcut storage kapasitesiyle uyuştuğunu
- Runbook credential'larının hala geçerli olduğunu
- Offsite kopyaların gerçekten senkronize olduğunu (sadece queued değil)
- RTO/RPO sayılarının hala business beklentileriyle uyuştuğunu
İpucu: Kendinize tekrarlayan bir takvim daveti ayarlayın. "DR planını gözden geçir" sıkıcı görünür; ama ihtiyaç duyduğunuz gün ve son güncellemenin 18 ay önce olduğunu fark ettiğinizde sıkıcı gelmez.
İşler Ters Gittiğinde Gerçekten Ne Önemli
Gerçek bir olay geldiğinde sakin ve toparlanmış olmayacaksınız. Stresli olacaksınız, baskı altında olacaksınız ve muhtemelen her beş dakikada bir sistemlerin ne zaman döneceği sorulacak. İşte tam o noktada sağlam bir DR plan değerini kanıtlar. Haftalar yerine saatler içinde kurtulan şirketler en pahalı araçlara sahip olanlar değildir; geri yüklemelerini test etmiş, offsite kopya tutmuş, başkasının takip edebileceği runbook'lar yazmış ve kötü gün gelmeden önce yedekleme erişimini kilitlemiş olanlardır.
Mecbursanız küçük başlayın. Bu hafta bir kritik sistem seçin. Geri yükleyin. Ne bozulduğunu görün. Düzeltin. Sonra bir sonrakine geçin. Test ettiğiniz bir DR planı, kağıtta mükemmel görünen on plandan daha değerlidir.
Kapak görseli: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/8058113576