Bir teknik due diligence görüşmesinde yedekleme sorusu sorulduğunda gelen cevap neredeyse her zaman olumludur; sistem yöneticisi ekranı paylaşır, gecelik yedekleme işlerinin yeşil renkte tamamlandığını gösteren konsolu açar ve konu kapanmış sayılır. Aynı görüşmede bir sonraki soru — en son ne zaman, hangi sistem üzerinde, hangi veri kümesiyle geri yükleme yapıldığı ve bu işlemin ne kadar sürdüğü — sorulduğunda oda sessizleşir. Cevap genellikle bir olayı hatırlatmak biçiminde gelir: geçen yıl bir kullanıcı yanlışlıkla bir klasörü silmişti, onu geri getirmişlerdi. Tek bir klasörün geri getirilmesiyle bir üretim veritabanının, uygulama katmanının ve kimlik altyapısının birlikte ayağa kaldırılması arasındaki mesafe, bu cevabın kapatamayacağı kadar geniştir.
Bu örüntü hemen her sermaye-yoğun ve teknoloji-bağımlı şirkette tekrarlanır, ve tekrarlanma nedeni ihmal değildir. Yedekleme, kurulduğu anda kendi kendini bildiren bir süreçtir; her gece çalışır, çalıştığını raporlar, çalışmadığında uyarı üretir. Geri yükleme ise ancak talep edildiğinde çalışan, hiçbir zaman kendiliğinden sinyal vermeyen bir süreçtir. Operasyonun günlük ritmi, sinyal üreten süreçleri denetim altında tutmaya, sinyal üretmeyenleri ise varsayıma bırakmaya doğal olarak eğilimlidir; bu, kaynak tahsisi açısından belirli koşullar altında rasyonel bir kısayoldur. Sorun kısayolun kendisinde değil, şirketin veri hacmi, sistem karmaşıklığı ve müşteri taahhütleri büyüdükçe kısayolun aynı kalmasındadır.
İkinci bir mekanizma, yedekleme başarısının teknik tanımı ile iş tanımı arasındaki açıklıktan doğar. Yedekleme yazılımı için başarı, kaynak dosyaların hedef ortama okunabilir biçimde yazılmasıdır; iş için başarı ise, bir kesinti anında operasyonun kabul edilebilir bir süre içinde ve kabul edilebilir bir veri kaybıyla yeniden çalışır hâle gelmesidir. Bu ikisi arasındaki ilişki doğrusal değildir. Şifreli bir veritabanının yedeği alınmış olabilir, fakat anahtar yönetimi aynı sistemin içinde tutuluyorsa geri yükleme mümkün olmayabilir; uygulama sunucusunun imajı alınmış olabilir, fakat lisans anahtarları donanım kimliğine bağlıysa yeni ortamda ayağa kalkmayabilir; nesne depolamadaki yedek sürüm koruması açık olabilir, fakat silme yetkisi aynı yönetici hesabında toplanmışsa fidye yazılımı senaryosunda yedek de birlikte kaybedilebilir. Bu bağımlılıklar yalnızca gerçek bir geri yükleme denemesinde görünür hâle gelir.
İnceleme masasının aradığı şey bu nedenle bir yedekleme politikası dokümanı değildir. Politikanın varlığı yalnızca ilk eşiktir ve tek başına düşük bilgi taşır; çoğu şirkette bu doküman bir sertifikasyon süreci için hazırlanmış, imzalanmış ve o gün bugündür açılmamıştır. Aranan şey üç kaydın birlikte bulunmasıdır: iş birimleriyle mutabık kalınmış kurtarma süresi ve veri kaybı hedeflerinin sistem bazında tanımlandığı bir envanter, bu hedeflerin son tatbikatta ölçülen fiili değerlerle karşılaştırıldığı bir sonuç raporu, ve tatbikatta çıkan sapmaların kapatılması için açılmış, sahibi ve tarihi olan aksiyon kayıtları. Bu üçü varsa, konu birkaç saatte kapanır; yoksa, incelemeyi yürüten taraf açıklamayı dinlemeye devam eder ama artık beyanı değil, beyanın yokluğunu kaydetmektedir.
Ölçüm boyutunun bu alandaki karşılığı özellikle inceltilmiştir, zira yedekleme metrikleri kolayca yanıltıcı hâle gelir. Yedekleme işi başarı oranının yüzde doksan dokuz olması, kritik sistemin tam da başarısız olan yüzde birde bulunması ihtimalini dışlamaz; ortalama geri yükleme süresi, en büyük veri kümesinin geri yükleme süresini gizler. Anlamlı ölçüm sistem kritikliğine göre ayrıştırılmış olmalı, yedekleme penceresinin iş yükü büyüdükçe nasıl uzadığını göstermeli, ve doğrulama testlerinin — yedeğin yalnızca yazıldığını değil, okunabilir ve tutarlı olduğunu sınayan testlerin — kapsama oranını içermelidir. Bu ayrım yapılmamış bir gösterge tablosu, yönetim kurulunu güvence altına almaz; yalnızca güvence hissi üretir.
Sahiplik boyutu, bu alanda değerlemeye en doğrudan bağlanan boyuttur. Yedekleme ve felaket kurtarma sorumluluğu tipik olarak yazılı bir görev tanımıyla değil, fiilî bilgi birikimiyle dağılır; sistemi kuran kişi, o sistemi kurtarabilecek tek kişi hâline gelir. Bu kişi şirkette kaldığı sürece yapı çalışır, fakat inceleme yürüten taraf yapının kişiden bağımsız olup olmadığını sorar, çünkü satın aldığı şey bir kapasitedir, bir kişinin hafızası değil. Bir felaket kurtarma prosedürünün süreklilik testi basittir ve masada sıklıkla uygulanır: prosedür, o sistemi hiç kurmamış bir teknik personel tarafından, dokümanı takip ederek, yardım almadan yürütülebiliyor mu. Cevap hayırsa, teknik risk kalemi kurucu bağımlılığı kalemiyle aynı kanaldan, yani temsil ve tekeffül kapsamının genişletilmesi, kapanış öncesi koşul eklenmesi ya da escrow oranının yukarı çekilmesi biçiminde fiyata girer.
Bu fiyatlamanın mekaniği çoğu zaman doğrudan bir değerleme iskontosu olarak görünmez, ve bu yüzden satıcı tarafında hafife alınır. Sözleşme masasında ortaya çıkan biçim genellikle şudur: alıcı, kapanıştan önce bağımsız bir tatbikatın yapılmasını ve sonucunun paylaşılmasını koşul olarak koyar; bu tatbikat kapanış takvimine haftalar ekler ve takvimdeki her gecikme satıcının pazarlık pozisyonunu aşındırır. Alternatif olarak alıcı koşulu kaldırır, karşılığında veri kaybı ve iş kesintisi başlıklarında özel bir tazminat maddesi ister; bu madde tavan taşımadığında ya da escrow süresini uzattığında, satıcının eline geçen nakdin bir kısmı bilinmeyen bir süre boyunca askıda kalır. Her iki durumda da bedel, tatbikatın maliyetinden büyüklük mertebesi olarak daha yüksektir.
Bulut ve yönetilen hizmet kullanımı bu tabloyu basitleştirmez, aksine sorumluluk sınırını görünmez kılar. Hizmet sağlayıcının altyapı düzeyinde sunduğu dayanıklılık taahhüdü ile müşterinin kendi veri katmanında taşıdığı sorumluluk farklı şeylerdir; bir SaaS uygulamasında yanlışlıkla silinen ya da bozulan kayıtların geri getirilmesi, sağlayıcının standart hizmet kapsamında çoğu zaman yer almaz veya sınırlı bir pencere içinde ve toplu geri dönüş biçiminde sunulur. Bu ayrımın sözleşme metninde nerede durduğu, hizmet seviyesi taahhüdünün hangi olay tiplerini kapsadığı ve ihlal hâlinde öngörülen telafinin gerçek zararla ilişkisiz bir hizmet kredisiyle sınırlı olup olmadığı, incelemede tek tek okunan başlıklardır. Sağlayıcı sözleşmelerinin tipik yapısı gereği, veri düzeyindeki kurtarma yükümlülüğü büyük olasılıkla müşteri tarafında kalır.
Bu alandaki müdahalemiz, yeni bir politika dokümanı yazmakla değil, mevcut yapının kanıt üretecek biçimde yeniden kurulmasıyla başlar. İlk adım, sistem envanterinin iş kritikliğine göre katmanlanması ve her katman için kurtarma süresi ile veri kaybı hedeflerinin teknik ekiple değil, o sistemin durmasından fiilen etkilenen iş birimiyle mutabık kalınarak sabitlenmesidir; bu mutabakat yazılı hâle gelmediği sürece hedefler teknik bir tercih olarak kalır ve müzakerede savunulamaz. İkinci adım, tatbikat takviminin kurulmasıdır: yılda en az bir kez tam kapsamlı, çeyrek dönemlerde ise seçilmiş sistemler üzerinde kısmi geri yükleme, her defasında farklı bir personel tarafından ve dokümanı takip ederek yürütülür. Üçüncü adım, tatbikat sonucunun tek sayfalık standart bir kayda bağlanmasıdır — hedef değer, ölçülen değer, sapma, sapmanın nedeni, açılan aksiyon, sahibi ve kapanış tarihi.
Bu kaydın asıl işlevi teknik değil, kurumsaldır. Bir yatırım komitesi ya da alıcı tarafın teknik danışmanı, on iki ay geriye giden dört tatbikat kaydını yan yana gördüğünde, yalnızca kurtarma kapasitesini değil, şirketin kendi zaaflarını ölçme ve kapatma disiplinini de okur; sapmaların zaman içinde daraldığı bir seri, herhangi bir politika dokümanından daha güçlü bir yönetim kalitesi göstergesidir. Buna karşılık kaydın hiç tutulmamış olması, aynı okuyucuya teknoloji hattının bütününde benzer bir doğrulama boşluğu bulunabileceğini düşündürür, ve inceleme kapsamı genişler. Kapsam genişlemesi, hem takvim hem de danışman ücreti olarak satıcının hanesine yazılır.
Sahiplik tarafındaki müdahale ise yetkinin dağıtılmasından çok, hesap verebilirliğin tekilleştirilmesiyle ilgilidir. Felaket kurtarma için tek bir isimlendirilmiş sahip tanımlanır, fakat bu sahibin görevi kurtarmayı bizzat yürütmek değil, kurtarmanın kendisi olmadan da yürütülebilir olduğunu düzenli olarak kanıtlamaktır; tatbikatı her seferinde başka bir personelin yürütmesi kuralı, tam da bu kanıtı üretmek için vardır. Yedek erişim yetkileri, şifre kasası kurtarma anahtarları ve sağlayıcı hesaplarının yönetim erişimi ayrı bir emanet düzenine bağlanır, zira bu erişimler tek kişide toplandığında yapı teknik olarak sağlam olsa bile kurumsal olarak kırılgandır. Bu düzenin işlediği, yılda bir kez erişim tatbikatıyla sınanır.
Sonuçta bu alanda incelemeye giren tarafın aradığı şey bir güvence beyanı değil, bir tekrarlanabilirlik kanıtıdır; ve bu kanıt yalnızca, şirketin kendi sistemini kasten durdurup yeniden ayağa kaldırdığı ve sonucu yazdığı anlarda üretilir. Yedekleme, çalıştığını her gece bildirdiği için güven veren bir süreçtir; felaket kurtarma ise ancak sınandığında güven vermeye başlar. Bir şirketin teknoloji hattının olgunluğunu tek bir soruyla ölçmek gerekseydi, sorulacak soru hangi araçların kullanıldığı değil, en son ne zaman ve kimin eliyle geri dönüldüğü olurdu.