Yedeğimiz Var Cümlesi Denetim Sorusunu Cevaplamaz

Veritabanı tarafında bir denetim sorusu sorulduğunda en sık verilen cevaplardan biri şudur: "yedeğimiz var, geri dönebiliriz." Bu cümle doğrudur ve önemlidir, ama sorulan soruyu cevaplamaz. Bu yazı, yedeğin neyi çözdüğünü ve neyi çözmediğini ayırıyor.

Yedeğimiz Var Cümlesi

Yedekleme olgun bir disiplindir. Çoğu kurumda düzenli alınır, test edilir ve saklama süresi tanımlıdır. Bu, kurtarma tarafında sağlam bir zemindir.

Sorun, yedeğin denetim sorularına cevap olarak sunulmasıdır. Denetçi "bu değişiklik yetkili miydi" diye sorar; cevap "yanlış giderse geri dönebiliriz" olur. İkisi farklı sorulardır. Birincisi kontrolle, ikincisi kurtarmayla ilgilidir.

Bu karışıklık zararsız değildir. Kurtarma yeteneğine güvenen bir kurum, önleyici kontrolleri gevşetmeye eğilim gösterir: nasılsa geri dönebiliriz düşüncesi, onay adımlarını ve inceleme derinliğini azaltır. Oysa kurtarma bir maliyettir ve her zaman mümkün değildir.

Yedeğin Cevaplamadığı Üç Soru

• Bu değişikliği kim istedi ve kim onayladı? Yedek verinin bir fotoğrafıdır. Fotoğrafın öncesinde alınan kararı içermez. İki yedek arasındaki farkı görebilirsiniz ama o farkın neden oluştuğunu göremezsiniz.
• Çalışan metin onaylanan metin miydi? Yedek sonucu gösterir, ifadeyi değil. Onaylanan betikle çalıştırılan betik farklıysa, iki yedeği karşılaştırarak bunu anlamanın yolu yoktur.
• Hiç değişmemesi gereken bir şey değişti mi? Yedek yalnız sorduğunuz soruya cevap verir. Neyi soracağınızı bilmiyorsanız, iki yedek arasındaki milyonlarca satırlık farkın içinde tek bir yetkisiz değişikliği bulmak pratikte imkânsızdır.

Bu üç sorunun cevabı yalnızca değişiklik yapıldığı anda üretilen bir kayıtta bulunur. Sonradan üretilemez, çünkü karar anındaki bağlam geçmiştir.

Geri Dönüş ile Geri Alma Aynı Şey Değildir

Yedekten geri dönmek bütün veritabanını belli bir ana taşır. Bu, hatalı bir değişikliği düzeltmenin en pahalı yoludur çünkü aradaki bütün doğru işlemler de kaybolur.

Geri alma ise hedeflidir: yalnız o değişikliği tersine çeviren bir betiktir ve diğer işlemlere dokunmaz. Bir değişiklik talebi açılırken geri alma betiğinin de hazırlanması, kurtarma maliyetini saatlerden dakikalara indirir.

Denetim açısından fark daha da önemlidir. Geri alma da bir taleptir: kaydı vardır, onayı vardır, kim çalıştırdığı bellidir ve kaynak talebe bağlıdır. Yedekten dönüş ise genellikle bir olay kaydında bir satır olarak kalır ve hangi değişikliği geri aldığı belgelenmez.

Geri alma betiğinin ne zaman ve nasıl üretileceği de bir karardır. Otomatik üretim mümkündür ama her ifade için değil; bazı işlemler doğaları gereği tersine çevrilemez ve bunun talep açılırken bilinmesi gerekir. Ürün geri alınamayan durumları risk değerlendirmesinde ayrı bir bulgu olarak işaretler; sürpriz olay anında değil, karar anında yaşanmalıdır.

Yedek Bir Kişisel Veri Kopyasıdır

Bu, yedeklerin denetimde ürettiği asıl risktir ve genellikle veri koruma tarafından gelir. Üretim yedeği, üretimdeki bütün kişisel verinin bir kopyasıdır ve saklama süresi boyunca yaşamaya devam eder.

Bir silme talebi geldiğinde üretimden silmek kolaydır. Yedeklerdeki kopyalar için verilen standart cevap, o kayıtların yedekten geri yüklenmesi hâlinde yeniden silineceğidir. Bu savunulabilir bir yaklaşımdır ama yazılı bir prosedür ve o prosedürün işlediğini gösteren bir kayıt gerektirir. Çoğu kurumda ikisi de yoktur.

İkinci risk, yedeğin test ortamına geri yüklenmesidir. Bu yaygın bir uygulamadır ve üretim verisini kontrolsüz bir ortama taşır. Yedek almak bir kontrol, yedeği test ortamına açmak ise bir risktir; ikisi aynı prosedürün parçası olduğu için genellikle birlikte onaylanır ve ayrı ayrı değerlendirilmez.

Yedeğin Gerçekten Kanıt Olduğu Yer

Yedek, doğru soru sorulduğunda gerçekten kanıt üretir ve bu değeri küçümsememek gerekir.

• Kurtarma yeteneğinin kanıtı. Düzenli yapılan ve kaydı tutulan geri yükleme testleri, iş sürekliliği kontrolleri için doğrudan kanıttır.
• Veri kaybı olmadığının kanıtı. Bir olaydan sonra hangi ana dönüldüğü ve ne kadar veri kaybedildiği yedek kayıtlarından gösterilir.
• Bir iddianın çürütülmesi. Bir kaydın belli bir tarihte var olmadığı iddiası, o tarihli yedek üzerinden kontrol edilebilir. Bu, denetimde nadiren kullanılan ama güçlü bir yöntemdir.

Ortak nokta şudur: yedek, verinin durumu hakkında kanıt üretir. Kararlar, yetkiler ve süreç hakkında kanıt üretmez. İki tür kanıt birbirinin yerine geçmez ve denetim ikisini birden ister.

Sık Sorulan Sorular

Her değişiklik öncesi yedek almak yeterli bir kontrol mü?

Kurtarma tarafında iyi bir uygulamadır, kontrol tarafında ise değildir. Yedek, değişikliğin yetkili olup olmadığını, hangi kurala göre değerlendirildiğini ve çalışan metnin onaylanan metin olup olmadığını göstermez. Ayrıca büyük veritabanlarında değişiklik öncesi yedek almak pratikte her zaman mümkün olmaz ve bu, kontrolün sessizce atlandığı yerdir.

Geri alma betiğini kim hazırlamalı?

Değişikliği isteyen kişi hazırlar, ama tek başına yeterli değildir: geri alma betiğinin varlığı ve doğruluğu onay adımının bir parçası olmalıdır. Bazı durumlarda geri alma otomatik üretilebilir; üretilemeyen durumlar da açıkça işaretlenmelidir. Bir talebin geri alınamaz olması bir engel değildir, ama bilinmeden onaylanması bir bulgudur.

Yedekteki kişisel veri için ne yapmalıyız?

Yazılı bir prosedür gerekir: silme talebi gelen kayıtların listesi tutulur ve bir yedek geri yüklendiğinde bu kayıtlar yeniden silinir. Prosedürün varlığı yetmez, işlediğini gösteren kayıt da gerekir. Ayrıca yedeğin test ortamına yüklenmesi ayrı bir karar olarak değerlendirilmeli ve bu kararın da izi kalmalıdır.

Denetim kayıtlarının yedeği ayrıca alınmalı mı?

Denetim kayıtları ürünün kendi veritabanındadır ve o veritabanının yedeği içine girer. Bunun ötesinde, kayıtların tam satır kopyası tercihen ayrı bir sunucudaki ikinci bir veritabanına yazılabilir. Bu bir yedek değil bir kontroldür: amacı veri kaybını önlemek değil, ana kaydın silinmesi hâlinde karşılaştırılacak bir kopya bırakmaktır. İkisi farklı işler yapar ve biri diğerinin yerine geçmez.