Kurumsal Veri Yedekleme ve Felaket Kurtarma Çözümleri

Her ofis binasında yangın söndürücü vardır. Duvarda asılıdır, üzerinde bir kontrol etiketi bulunur, kimse ona bakmaz. Sorulması gereken soru şudur: en son ne zaman tatbikat yaptınız, yangın çıkışının kapısı gerçekten açılıyor mu, yoksa önüne koli mi yığılmış? Kurumsal veri yedekleme tam olarak o söndürücüdür: alınmıştır, çalıştığı varsayılır ve gerçekten gerektiği gün ilk kez denenir.

Biz veri yedekleme ve felaket kurtarma altyapısını kurarken iki işi birden yapıyoruz: kopyaları doğru mimariyle üretiyoruz ve o kopyaların geri döndüğünü düzenli olarak test ediyoruz. Sanallaştırma platformunuz VMware, Hyper-V veya Proxmox olsun; yedekleme çözümleri seçimini kurumunuzun kurtarma hedefine göre yapıyoruz, tek bir markaya bağlı kalmadan.

Bu makale BT Sistem Yönetimi hizmetimizin veri sürekliliği koluna odaklanır. Yedeklediğiniz sunucuların kurulumunu Windows Server kurulum rehberimizde ele alıyoruz. Yeni bir sunucuyu yedeklemesi kurulmuş ve geri yükleme testi yapılmış olarak teslim ettiğimiz hizmet ise sunucu kurulumu sayfamızda duruyor. Mevcut sistemlerinize yedekleme düzenini kurup ilk geri dönüş testiyle teslim ettiğimiz hizmetin kapsamı da veri yedekleme hizmeti sayfamızda yazılı.

Veri Yedekleme Neden Tek Başına Yetmez?

Bir yedeğin var olması, verinin geri geleceği anlamına gelmez. Kurumsal veri yedeklemede karşılaştığımız en yaygın durum, yedekleme işlerinin yıllardır sorunsuz yeşil rapor üretmesi ama hiç kimsenin bir geri yükleme denemesi yapmamış olmasıdır. Yeşil rapor yalnızca şunu söyler: kopyalama işlemi hatasız bitti. Dosyanın açılıp açılmayacağını, sunucunun ayağa kalkıp kalkmayacağını söylemez.

Yangın söndürücü benzetmesine dönelim. Söndürücünün duvarda asılı olması bir şey ifade etmez; içindeki basıncın yeterli olup olmadığı, tetiğin sıkışıp sıkışmadığı ancak denendiğinde belli olur. Yedekleme de böyledir. Test edilmemiş bir yedek, yedek değildir; bir varsayımdır.

İkinci sorun, yedeğin nerede durduğudur. Çoğu kurumda yedekler üretim ağındaki bir sunucuda veya aynı storage ünitesinde tutulur. Bu, yangın söndürücüyü yanmakta olan odaya koymaktır. Fidye yazılımı bulaşan bir ağda saldırganın ilk aradığı şey yedeklerdir: onları şifrelerse pazarlık gücü kalmaz. Aynı mantık fiziksel riskler için de geçerlidir. Su baskını, elektrik arızası veya hırsızlık, aynı odadaki iki diski birden götürür.

3-2-1-1-0 Kuralı: Yedeklemenin Güncel Standardı

3-2-1 yedekleme kuralı hâlâ doğru, ama artık eksik. Güncel standart 3-2-1-1-0: üç kopya, iki farklı ortam, bir kopya dış lokasyonda, bir kopya değiştirilemez veya ağdan ayrık, ve geri yükleme testlerinde sıfır hata. Sondaki iki hane fidye yazılımı çağının eklentisidir; ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı’nın (CISA) #StopRansomware rehberi ve NIST SP 800-209 bu yapıyı asgari mimari kabul eder. Siber sigorta poliçelerinin çoğu da artık bunu şart koşar.

3 Kopya: Üretim ve İki Bağımsız Yedek

Üç kopya demek, canlıdaki asıl veri ve ondan bağımsız iki yedek demektir. Canlı veri de bir kopya sayılır: canlı veri, birinci yedek, ikinci yedek. Binada söndürücü, sprinkler ve yangın merdiveni ayrı ayrı bulunur; biri devreye girmezse diğeri girer. Tek yedek, tek nokta arızasıdır.

Kopyaların nasıl üretileceği de bu başlığın altındadır. Tam (full) yedek verinin bütününü kopyalar: en büyük dosyayı üretir, en hızlı geri döner. Artımlı (incremental) yedek yalnızca son yedekten beri değişenleri alır: en küçüğüdür, ama geri yüklerken zincirin tamamı okunacağı için en yavaşıdır. Fark (differential) yedek son tam yedekten beri değişenleri alır ve ikisinin ortasında durur. Kurumsal pratikte bu üçü GFS saklama (Grandfather-Father-Son: günlük, haftalık, aylık döngü) ile birleştirilir.

2 Farklı Ortam: Aynı Sepetin İki Yumurtası Sayılmaz

İki farklı ortam, kopyaların farklı türde medyada durması demektir. Buradaki tuzak sık gözden kaçar: aynı RAID havuzundaki iki disk iki ortam sayılmaz. Aynı storage ünitesi, aynı denetleyici, aynı oda ve aynı fidye yazılımı demektir. Disk ile teyp, disk ile bulut veya disk ile ikinci bir NAS kabul edilebilir ayrımlardır. İki kopya da aynı marka ve aynı üretim partisinden iki disk üzerindeyse, tek bir üretim hatası ikisini birden götürebilir.

1 Dış Lokasyon: Çözüm Yanan Binanın İçinde Olamaz

En az bir kopya binanın dışında, farklı bir coğrafi lokasyonda olmalıdır. Yangın tatbikatında toplanma noktası binanın içinde değildir; olayın kendisi binayı etkiliyorsa, çözümün de aynı binada olmaması gerekir. Su baskını, elektrik arızası, hırsızlık veya yangın; hepsi tek bir adresteki her şeyi birden götüren risklerdir.

1 Değiştirilemez veya Ağdan Ayrık Kopya

Bu, kuralın en yeni ve en kritik parçası. Immutable (değiştirilemez) storage, yazıldıktan sonra belirlenen süre boyunca hiç kimsenin, sistem yöneticisi dahil, silemediği veya değiştiremediği bir kopya üretir. Yangına dayanıklı bir çelik kasa gibi çalışır: içine koyduğunuza ne alevler ne de anahtarı olan biri ulaşabilir. Fidye yazılımı yönetici parolasını ele geçirse bile bu kopyaya dokunamaz. Alternatifi, kopyanın ağdan fiziksel olarak ayrık (air-gapped) tutulmasıdır.

0 Hata: Doğrulanmış Geri Yükleme

Geri yükleme testleri hatasız tamamlanmalıdır. Sondaki sıfır, diğer dört hanenin tamamını denetleyen hanedir: üç kopyanız da olsa, dış lokasyonunuz da olsa, geri dönmediği doğrulanmamışsa mimari kağıt üzerinde kalır. Tatbikat yapılmayan bir binada yangın çıkışının kilitli olduğu, ancak yangın çıktığında öğrenilir.

Felaket Kurtarma Planı: RTO ve RPO Ne Anlama Gelir?

Felaket kurtarma planı iki sayıyla başlar: ne kadar sürede ayağa kalkmanız gerektiği (RTO) ve ne kadar veriyi kaybetmeyi göze aldığınız (RPO). Bu iki sayıyı belirlemeden yapılan her yedekleme yatırımı tahmine dayanır.

RTO: Ne Kadar Sürede Ayağa Kalkıyorsunuz?

RTO (Recovery Time Objective), kurtarma süresi hedefidir: sistemin çökmesiyle yeniden çalışır hale gelmesi arasında kabul edilebilir en uzun süre. Yangın tatbikatındaki tahliye süresidir. Binayı kaç dakikada boşaltabildiğinizi bilmiyorsanız, planınız yoktur.

RTO’yu belirleyen üç şey vardır: geri yükleme hızı, yedeklerin erişim süresi (teypte mi, diskte mi, bulutta mı) ve felaket anında devreye girecek altyapının ne kadar hazır beklediği. Bu son madde sıcak, ılık ve soğuk site ayrımıdır: sıcak site donanımı kurulu ve verisi güncel bekler, soğuk site yalnızca boş bir alandır. Aradaki fark RTO’da saatlerle, faturada katlarla ölçülür.

RPO: Ne Kadar Veriyi Kaybetmeyi Göze Alıyorsunuz?

RPO (Recovery Point Objective), veri kaybı toleransıdır. En son yedekten bu yana geçen süre kadar veri kaybedersiniz. Günde bir kez yedek alıyorsanız RPO’nuz 24 saattir; bir arıza anında en fazla bir günlük çalışmayı kaybedersiniz.

RPO hedefi mimariyi doğrudan belirler. Sıfır RPO, yani hiç veri kaybetmemek, eşzamanlı (senkron) replikasyon gerektirir ve bunun gecikme maliyetini üretim sistemine bindirir. Dakikalar mertebesinde bir RPO genellikle eşzamansız (asenkron) replikasyon veya sık anlık görüntü ile elde edilir. Yirmi dört saatlik RPO ise tek bir gecelik yedek policy’sidir. Üçü arasındaki fark bir ayar değil, bambaşka bir altyapıdır.

Bu İki Sayı BT Kararı Değil, İş Kararıdır

Saha ortamlarında gördüğümüz en sık hata, RTO ve RPO’yu BT ekibinin tek başına belirlemesidir. Bu iki sayı iş birimi kararıdır; BT’nin işi kararı vermek değil, seçeneklerin teknik fizibilitesini ve maliyet aralığını bir menü olarak masaya koymaktır. “Sipariş servisinin on beş dakikada dönmesi şu maliyete mal olur, beş dakikada dönmesi bunun birkaç katına, hiç durmaması ise bambaşka bir bütçeye” demek BT’nin görevidir; hangisinin satın alınacağına karar vermek yönetimin.

İkinci sık hata tüm kuruma tek bir RTO yazmaktır. İlk soru şudur: hangi sistem durursa iş durur? Muhasebe sunucusu bir gün dursa iş aksar ama devam eder; üretim hattını yöneten sunucu iki saat dursa fabrika durur. Arşiv sistemi bir gün beklese kimse fark etmez. Aynı kuruma ait bu sistemlerin RTO’su aynı olmak zorunda değildir ve genellikle olmamalıdır. Kritik sistemleri ayırıp onlara daha sıkı hedefler koymak, tüm ortama tek tip yüksek koruma uygulamaktan hem daha ucuz hem daha gerçekçidir.

Sahadan bir örnek, bu iki sayının farkını en net anlatan vaka. Danışmanlık verdiğimiz bir kurumda, akşam 18:00’den sonra muhasebe sunucusu cevap vermez oldu; bağlı olduğu storage ünitesi arızalanmıştı. Yedek üniteyi hızla devreye aldık, sunucu kısa sürede yeniden ayaktaydı. RTO tarafı iyi çalışmıştı.

Acı diğer taraftaydı. Veriler arızalanan ünitede kalmıştı, dolayısıyla en yakın yedeğe dönmek zorundaydık. O yedek aynı günün gece yarısına aitti: yani muhasebecilerin mesaiye başlamasından sekiz saat öncesine. Ertesi sabah işe geldiklerinde tuhaf bir dejavu yaşadılar. Bir gün önce girdikleri kayıtlar ekranda yoktu.

Kurum bu kaybı sorun etmedi, çünkü yirmi dört saatlik backup policy bilinçli bir tercihti; düşük maliyet karşılığında bu risk baştan göze alınmıştı. Karar yanlış da değildi. Ama görülmesi gereken şu: o kararın bedelini, kararı veren masa ödemedi. Bir günlük veriyi ikinci kez giren muhasebe ekibi ödedi. Muhasebe bugün büyük ölçüde bilgisayar operatörlüğüne dönmüş bir iş; “bir günlük veri kaybı” bir tabloda küçük bir satır gibi durur, o veriyi yeniden tuşlayan için bütün bir gündür.

İşin bir de şans tarafı vardı: arıza, beyanname veya defter gönderiminin olmadığı sakin bir güne denk geldi. Muhasebenin takvimi düz sanılır, değildir. Ayın belirli günlerinde beyanname süreleri ve elektronik defter yükleme süreleri dolar; o günlerde kaybedilen birkaç saat, yeniden veri girişinden ibaret kalmaz, gecikme ve ceza riskine dönüşür. Aynı arıza iki hafta kayarak yaşansaydı, kurumun “bir günlük kayıp sorun değil” cümlesi muhtemelen kurulmayacaktı.

Buradan çıkan sonuç şu: RPO takvimde sabit bir sayı değildir. Aynı yirmi dört saat, ayın bir gününde kimseyi yormaz, başka bir gününde kuruma para kaybettirir. Bu yüzden RPO’yu konuşurken masada yalnızca maliyet olmamalı; o sayının kimin gününe ve hangi güne denk geleceği de olmalı. Yoğunluk ritmi belli olan birimlerde, kritik takvim günlerine özel sıkılaştırılmış bir yedekleme penceresi açmak, tüm yılı en kötü güne göre bütçelemekten çok daha ucuzdur.

Kağıt Üzerindeki RTO ile Gerçek RTO

En sinsi hata budur. Felaket kurtarma planınızda “RTO otuz dakika” yazabilirsiniz. Ama hiç tam kapsamlı bir tatbikat yapmadıysanız, gerçek RTO’nuz altı saattir ve bunu krizin ilk dakikasında öğrenirsiniz. Yazılan sayı bir hedeftir; ölçülen sayı ise gerçektir, ve ikisi arasındaki fark ancak kronometreyle kapanır.

Bu yüzden iki ayrı ritim öneriyoruz ve ikisini birbirine karıştırmıyoruz. Rutin geri yükleme testi: üç ayda bir. Yedeklenen sistemlerden biri seçilir, izole ortamda ayağa kaldırılır, açılışı ve verinin bütünlüğü doğrulanır. Tam kapsamlı felaket kurtarma tatbikatı: yılda en az iki kez. Bu, tek bir sunucuyu değil senaryonun tamamını dener. Kimin aranacağı, hangi sırayla neyin ayağa kalkacağı ve kronometrenin kaçta duracağı bu tatbikatta ortaya çıkar. Birincisi yedeğin çalıştığını, ikincisi planın çalıştığını kanıtlar.

Yedekleme Çözümleri Seçerken Nelere Bakmalı?

Yedekleme çözümleri arasında seçim yaparken ürünün özellik listesinden başlamayın. Doğru sıra şudur: önce kopyalarınızdan birinin değiştirilemez olup olmayacağına, verinin fiziksel olarak nerede duracağına, taramanın nerede yapılacağına ve ölçeğinize karar verin; ürünü bu kararların ardından seçin. Aşağıdaki başlıklar bu kararların her birini sırayla açıyor.

Immutable Storage Desteği

Yukarıdaki kuralın dördüncü hanesi, ürün seviyesinde desteklenmiyorsa kurulamaz. Yedekleme yazılımının veya hedef storage alanının, yazılan veriyi belirli bir süre boyunca kilitleyebilmesi gerekir. Bu özellik olmadan fidye yazılımına karşı gerçek bir savunmanız yok demektir; kalan tek koruma, kopyayı manuel olarak ağdan ayırma disiplinidir ve bu disiplin insana bağlı olduğu için er geç aksar.

Yedekleme Ürünü Güvenlik de Yapmalı mı?

Bugün ciddi yedekleme ürünlerinin neredeyse tamamı bir biçimde zararlı yazılım taraması yapıyor. Bu yüzden ürün seçerken sorulacak soru “antivirüsü var mı?” değil, şu: tarama nerede yapılıyor? İki mimari var ve ikisi de savunulabilir.

Birleşik ajan. Tek bir ajan hem yedeği alır hem üretim makinesini korur; gerçek zamanlı antivirüs, fidye yazılımı engelleme, uç nokta tespit ve yanıt, yama yönetimi aynı konsolun altında toplanır. Küçük ve orta ölçekli ekipler için bu gerçek bir avantajdır: kurulacak ajan sayısı azalır, izlenecek konsol sayısı azalır, fatura tek yerden gelir. Yedekleme ile güvenliği ayrı ayrı yönetecek insan kaynağınız yoksa konsolidasyon mantıklı bir tercihtir.

Ayrı katmanlar. Bu yaklaşımda yedekleme ürünü uç noktayı korumaz, kendi zincirini tarar. Yedek alınırken veri blokları entropi analizinden geçer: bloğun rastgeleliğine bakılarak şifrelenmiş içerik veya fidye notu aranır. Geri yükleme noktaları imza tabanlı motorlarla ve özel tehdit göstergesi kurallarıyla ayrıca taranır. Uç nokta güvenliği ise ayrı ve uzmanlaşmış bir katman olarak durur.

Aradaki tercih aslında bir risk tercihidir. Konsolidasyonun bedeli, iki ayrı disiplini tek satıcıya bağlamaktır: o üründen memnun kalmadığınız gün hem yedeğinizi hem güvenliğinizi birden değiştirmek zorunda kalırsınız. Bu, güvenlik ile yasal uyumu aynı kutuya koymanın taşıdığı riskin aynısıdır; apartman benzetmesiyle, binanın güvenlik şirketi ile arşivinin aynı firmaya ihale edilmesi zorunlu değildir.

Hangi mimariyi seçerseniz seçin, atlanmaması gereken bir yetenek var: geri yüklemeden önce tarama.

Sebebi şu: fidye yazılımı ağa girdiği gün fark edilmez. Genellikle haftalar önce yerleşmiş, sessizce beklemiştir. Yani “temiz” sandığınız geri yükleme noktalarının bir kısmı çoktan enfektedir. Tarama yapmadan geri dönerseniz veriyle birlikte zararlıyı da geri yükler, olayı ikinci kez yaşarsınız.

Bu, makalenin baştan beri söylediği cümleyi bir adım ileri taşıyor. Test edilmemiş yedek yedek sayılmaz; enfekte yedek de sayılmaz. Geri yükleme testinin sorusu artık tek değil iki tanedir: geri dönüyor mu, ve temiz mi dönüyor?

Verinin Fiziksel Konumu ve KVKK

Dış lokasyon kopyanız bulut üzerindeyse, o bulutun veri merkezinin hangi ülkede olduğu hukuki bir sorudur. Verinin yurt dışındaki bir veri merkezinde tutulması KVKK m.9 kapsamında yurt dışına aktarım sayılır ve ayrı bir hukuki dayanak ile ek yükümlülükler doğurur. Türkiye’de yerleşik bir veri merkezinde tutulan yedek, bu yükümlülüğü baştan ortadan kaldırır.

Kişisel veri barındıran sistemleri yedekliyorsanız, ki neredeyse her kurum yedekliyor, bu soruyu ürün seçiminden önce sorun. Konum sorusunun yanında ikinci bir soru daha var ve retention policy’lerinin en zayıf noktası orası: canlıda silinen bir kaydın yedekteki kopyası da süresi dolduğunda döngüden çıkmalıdır. Bunun nasıl kurgulandığını KVKK teknik uyum rehberimizde anlattık.

Sanallaştırma Katmanıyla Uyum

Yedekleme yazılımının hipervizör ile doğrudan konuşabilmesi, sanal makineyi bütün olarak, işletim sistemi ve uygulamalarıyla birlikte geri getirebilmesi anlamına gelir. Dosya seviyesinde yedek alan bir çözüm size dosyaları geri verir ama çöken sunucuyu ayağa kaldırmaz; ikisi arasındaki fark, RTO’nuzda saatlerle ölçülür. Sanallaştırma katmanının kendisiyle ilgili kararlar için hipervizör ve sanallaştırma rehberimize bakabilirsiniz.

Ölçeğinizin Bir Üstü Değil, Kendi Sınıfınız

Ürün seçiminde birbirinin zıddı iki hata vardır:

1. Ölçeğin çok üstüne atlamak. Küçük bir mühendislik şirketine en ağır kurumsal platformu kurmak faturayı kabartır, özellikler kullanılmaz, lisans yenilemesi geldiğinde kimse memnun olmaz.
2. Ölçeğin altında kalmak. Yüz sunuculu bir kurumda “zaten işletim sisteminin kendi yedekleme aracını kullanıyoruz” demek çalışıyor görünür ve patlama günü patlar.

Kaba bir yön verici: on sunucuya kadar açık kaynak araçlar ve sıkı bir disiplin yeterlidir; on ile yüz arasında ticari bir yedekleme ürünü gerekir; yüzün üstünde kurumsal bir veri koruma platformu konuşulur. Marka tercihini bilinçli olarak bu kriterlerin arkasında tutuyoruz. Kurumun sanallaştırma altyapısı, veri hacmi ve kurtarma hedefi netleşmeden ürün önermek, çözümü değil satıcıyı seçmektir. Bu kriterler netleştikten sonra sürüm ve lisans hesabının nasıl yapıldığını kurumsal yedekleme programı sayfamızda anlattık.

Bir de hangi ürünü alırsanız alın değişmeyen bir gerçek var: hiçbir araç geri yükleme testinizi sizin yerinize yapmaz. Ürünlerin otomatik doğrulama işlevleri yardımcıdır, ama gerçek bir geri dönüş senaryosunu masaya yatırıp kronometreyi çalıştırmayan hiçbir kurum gerçek anlamda yedekli değildir.

Bulut Senkronizasyonu Yedek Değildir

Bu, kurumların en pahalıya ödediği yanılgı. OneDrive, Google Drive veya Dropbox gibi servisler senkronizasyon servisleridir, yedekleme servisleri değil. Bir dosyayı silerseniz veya fidye yazılımı onu şifrelerse, değişiklik saniyeler içinde buluta yansır ve “yedeğiniz” de bozulur. Senkronizasyon değişikliği yayar; yedekleme ise değişiklikten önceki hali saklar. Bu servislerin sürüm geçmişi özellikleri sınırlı bir kurtarma sağlar, ama kurumsal bir retention policy’nin yerine geçmez.

Yedekleme ile Yasal Arşiv Aynı Şey Değil

Bir yedekleme çözümü, 5651 sayılı kanunun gerektirdiği iki yıllık log arşivinin yerine geçmez. Bu ikisi sık karıştırılır ve karışıklık denetim anında ortaya çıkar.

Fark şurada. Yedekleme, kaybettiğinizi geri getirmek içindir ve sürekli kendini yeniler: saklama süreniz otuz günse, otuz bir gün önceki kayıt silinir. Yasal arşiv ise tam tersini ister. Kaydın iki yıl boyunca durmasını, o süre içinde değiştirilmediğinin ispatlanabilmesini ve zaman damgası taşımasını bekler. Silerek yer açan bir sistem, hiçbir şeyi silmemesi beklenen bir görevi üstlenemez.

Doğru kurgu şudur: 5651 log platformu yasal arşivi tutar, yedekleme çözümü de o platformun kendisini korur. Log sunucusu tek bir disk arızasıyla giderse elinizde gösterecek hiçbir şey kalmaz; denetim karşısında “sunucumuz bozuldu” bir savunma değildir. Konunun tamamını 5651 log yönetimi rehberimizde ele alıyoruz.

Benzer bir ayrım ISO 27001 için de geçerlidir. Standardın Ek A kontrolleri yedekleme yapılmasını değil, backup policy’nin yazılı olmasını ve düzenli olarak test edildiğinin kanıtlanmasını ister. Denetçiye gösterilecek şey yedekleme ekranı değil, test kayıtlarıdır. Belgelendirme sürecinin bütününü ISO 27001 belgesi rehberimizde anlatıyoruz.

Kurulumdan Test Döngüsüne: İş Sahada Nasıl Yürür?

Bu bölüm işin nasıl yürüdüğünü anlatır; kapsamı, teslimi ve bedeli merak ediyorsanız veri yedekleme hizmeti sayfamıza bakabilirsiniz.

Denetim aşamasında neyin yedeklendiğini değil, neyin yedeklenmediğini arıyoruz. Kurumların çoğunda dosya sunucusu düzenli yedeklenirken, sanal makinelerin yapılandırması, ağ cihazlarının konfigürasyonu veya Active Directory sistem durumu kapsam dışında kalır. Bir felaket anında dosyalar geri gelir ama kullanıcıların oturum açacağı domain gelmez.

Sahadan somut bir örnek: çok lokasyonlu bir kurumun VMware ortamındaki sanal sunucuların hiçbirinin sistematik yedeği yoktu. Yedekleme için ayrılmış sunucu Windows Server 2016 üzerinde çalışıyordu; hem işletim sistemi hem yedekleme yazılımı yıllardır güncellenmemişti. Sunucuyu Windows Server 2022’ye yükselttik, yedekleme altyapısını sıfırdan kurduk ve sunucuların tamamını hafta içi günlük artımlı (incremental), hafta sonu tam (full) yedek alacak şekilde yapılandırdık.

Kurulumun kendisi 1-2 saat sürdü. Asıl emek doğru zamanlama ve retention policy’nin planlanmasındaydı, üstüne de geri yükleme testlerini yapıp yedeklerin fiilen geri döndüğünü doğrulamaktı. Sürecin ayrıntısını yedekleme sistemi kurulumu vaka çalışmamızda paylaşıyoruz.

Test döngüsü ise kurulumdan sonra başlar ve bitmez. Yukarıda ayırdığımız iki ritmi işletiyoruz: üç ayda bir rutin geri yükleme testi, yılda iki kez tam kapsamlı felaket kurtarma tatbikatı. Her ikisinin sonucu da kayıt altına alınır. Bu kayıt hem ISO 27001 denetiminde istenen kanıttır hem de bir felaket anında geri dönüş süresini tahmin değil, ölçüm haline getirir.

Tatbikat yapmayan bina, yangın çıkışının kilitli olduğunu yangın günü öğrenir.

Sonraki Adımlar

Yedekleme mimarisi kurulduktan sonra sıradaki halka, o yedeklerin korunduğu ortamın kendisidir. Bir yedeğin güvenliği, üzerinde durduğu sunucunun ve o sunucuya erişebilen hesapların güvenliğinden fazla olamaz: fidye yazılımı çoğu zaman yedekleme deposuna, ele geçirdiği bir yönetici hesabının yetkisiyle ulaşır. Bu yüzden yedekleme kurulumunu tamamladıktan sonra sırayı sunucu sıkılaştırmasına, ayrıcalıklı hesapların sınırlanmasına ve Active Directory güvenlik sıkılaştırmasına veriyoruz.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn