Yedeğiniz var, peki geri dönebiliyor musunuz?

Yedekleme konusunda sorulması gereken soru "yedek alıyor musunuz" değil, "en son ne zaman bir yedekten geri döndünüz" sorusudur. Çoğu işletmede yedek bir yerlerde alınıyor; ama o yedekten gerçekten çalışan bir sisteme dönüldüğü hiç denenmemiş oluyor. Denenmemiş bir yedek, yedek değildir; yedek almış olma duygusudur. Aradaki farkı ancak kötü bir günde öğrenirsiniz, ve o gün öğrenmek için en pahalı gündür.

Bu yazı, yedekleme kurulumlarının pratikte nerelerden çatladığını ve sizin bilgi işlem sorumlunuza hangi soruları sormanız gerektiğini anlatıyor. Teknik bir kurulum kılavuzu değil; kararın sizde olduğu kısımlarla ilgili.

Yedek almak ile geri dönebilmek aynı şey değil

Yedekleme iki ayrı işten oluşur. Birincisi kopyayı üretmek: bir program her gece dosyaları ya da veritabanını bir yere kopyalar. İkincisi kopyadan çalışan bir sistem kurmak: sunucuyu ayağa kaldırmak, veritabanını içeri almak, uygulamayı yeniden bağlamak, kullanıcıların girmesini sağlamak. Firmaların neredeyse tamamı birinci işi yapıyor. İkincisini deneyenler azınlıkta.

Bu ayrımın önemi şurada: birinci iş otomatiktir, ikincisi değildir. Kopyalama işi bir kez kurulur ve kendi kendine döner. Geri dönüş ise her seferinde insan kararı, insan bilgisi ve genellikle o an ulaşılamayan bir kişinin kafasındaki adımları gerektirir. Kriz anında "yedek var" cümlesi rahatlatıcıdır, ama o cümlenin arkasında "ve şu adımlarla iki saatte ayağa kalkarız" cümlesi yoksa rahatlama erken olmuş demektir.

Yedekleme kurulumunun başarısı, üretilen kopya sayısıyla değil, geri dönüş süresiyle ölçülür. Kimse size kaç gigabayt yedek aldığınızı sormaz; işin durduğu gün kaç saat sonra açıldığınızı sorar.

Yedek nerede duruyor?

En sık görülen kurulum şu: yedek, verinin durduğu sunucunun ikinci diskine ya da aynı makinenin başka bir klasörüne alınıyor. Bu, disk bozulmasına karşı bir koruma sağlar, başka hiçbir şeye karşı sağlamaz. Sunucu yanarsa, çalınırsa, elektrik kaynaklı bir arıza anakartı götürürse yedek de aynı kutunun içindedir.

Bir adım ileri gidip yedeği ofisteki başka bir makineye ya da ağdaki bir depolama cihazına alan firmalar var. Bu daha iyi, ama fidye yazılımı senaryosunda yetmiyor. Fidye yazılımı bulaştığı makineden ağa açılır ve erişebildiği her şeyi şifreler. Yedek klasörü o makineden görülebilen bir paylaşımdaysa, virüs onu da şifreler. Sabah geldiğinizde hem sistem hem yedek okunamaz haldedir. Bu, teorik bir risk değil; küçük işletmelerde en sık görülen veri kaybı biçimi.

Bu yüzden yedeklemede genel kabul gören basit bir kural var: verinin en az üç kopyası bulunsun, bu kopyalar en az iki farklı ortamda tutulsun, ve en az bir kopya fiziksel olarak başka bir yerde olsun. Buradaki "başka yer" bulut olabilir, bankadaki kasada duran bir disk olabilir, muhasebecinin ofisi olabilir. Önemli olan, ofisteki bir felaketin ya da ağdaki bir bulaşmanın o kopyaya ulaşamaması.

Ulaşamamanın bir de yazma tarafı var. Yedeğin durduğu yer, sistemin normal çalışması sırasında üzerine yazılamaz veya silinemez olmalı. Yedek alan hesabın yedekleri silme yetkisi varsa, o hesabı ele geçiren de siler. Bilgi işlem sorumlunuza sorulacak somut soru şudur: "Sunucudaki bir kullanıcı ya da bir zararlı yazılım, yedekleri silebilir mi?"

Dosyalar yedeklendi, veritabanı yedeklenmedi

İkinci klasik hata neyin yedeklendiğiyle ilgili. Yedekleme çoğu zaman klasör mantığıyla kurulur: şu dizinler kopyalansın. Oysa muhasebe programınızın, ERP'nizin, web sitenizin ya da stok sisteminizin asıl verisi bir veritabanında durur. Veritabanı çalışırken dosyası sürekli değişir; bu dosyayı öylece kopyalamak çoğu zaman geri yüklenemeyen, yarım bir kopya üretir. Veritabanının kendi yedek alma yöntemiyle, tutarlı bir anlık görüntü olarak alınması gerekir.

Aynı gözden kaçma başka yerlerde de olur. Sistemin ayar dosyaları, lisans bilgileri, sunucudaki zamanlanmış görevler, e-posta kutuları, ortak sürücüdeki taranmış evraklar, muhasebe programının yerel makinedeki veri klasörü, çalışanların masaüstündeki Excel dosyaları. Bunların hiçbiri "sunucu yedekleniyor" cümlesinin içinde otomatik olarak yer almaz.

Yapılacak iş sıkıcı ama basittir: işin durmasına yol açacak sistemlerin listesini çıkarmak ve her biri için verinin fiziksel olarak nerede durduğunu tek tek yazmak. Bu liste bir kere çıkarılır, yılda bir gözden geçirilir. Listede olmayan hiçbir şeyin yedeklendiğini varsaymayın.

Bozuk yedek sessizce birikir

Yedekleme işlerinin can sıkıcı bir özelliği var: bozulduklarında ses çıkarmazlar. Disk dolar, bir parola değişir, bir klasörün adı değişir, program güncellemesinden sonra görev çalışmaz olur. Yedek almayı üç ay önce bırakmış bir sistem, klasöründe üç ay önceki dosyalarla gayet mevcut görünür. Kimse bakmadığı sürece her şey yolunda sanılır.

Çözüm iki parçalı. Birincisi, yedekleme işinin sonucunun bir yere bildirilmesi: başarılıysa da başarısızsa da bir bildirim düşsün. Yalnızca hata durumunda bildirim gönderen kurulumlar risklidir, çünkü bildirim mekanizmasının kendisi bozulduğunda sessizlik "her şey yolunda" gibi okunur. İkincisi, birinin bu bildirimlere fiilen bakması. Kimsenin okumadığı bir uyarı e-postası, olmayan uyarıyla aynı şeydir.

Buna ek olarak yedek dosyalarının okunabilirliğinin düzenli olarak sınanması gerekir. Boyutun beklenen aralıkta olması, arşivin açılabilmesi, veritabanı yedeğinin bütünlük kontrolünden geçmesi. Bunlar otomatikleştirilebilir işlerdir ve bir kez kurulduktan sonra kendiliğinden döner.

Geri dönüş bir tatbikattır

Bir yedeğin gerçekten çalıştığının tek kanıtı, o yedekten çalışır bir sistem kurulmuş olmasıdır. Bu yüzden ciddi kurulumlarda düzenli aralıklarla geri dönüş tatbikatı yapılır: boş bir sunucuya ya da geçici bir sanal makineye yedek yüklenir, sistem ayağa kaldırılır, birkaç gerçek kayıt açılıp doğruluğu kontrol edilir, sonra ortam silinir.

Tatbikatın asıl kazancı yedeğin sağlamlığını görmek değil, eksik adımları bulmaktır. Tatbikatlarda genellikle şunlar ortaya çıkar: geri yüklemek için gereken bir lisans anahtarı kimsede yok, uygulamanın veritabanına bağlanma parolası yalnızca ayrılan bir çalışanın notlarındaydı, kurulum sırası yanlış yapılınca sistem açılmıyor, sunucunun işletim sistemi sürümü artık indirilemiyor. Bunları kriz anında keşfetmek ile sakin bir salı günü keşfetmek arasında büyük fark var.

Tatbikatın çıktısı da yazılı olmalı: adım adım, sırasıyla, kimin yapacağı belli, gereken parola ve anahtarların nerede tutulduğu belirtilmiş bir metin. Bu metnin bir kopyası dijital olmayan bir yerde de bulunmalı, çünkü sistemler kapalıyken sistemin içindeki dokümana bakamazsınız. Yılda bir kez tekrarlanan, bir saatlik bir işten söz ediyoruz.

Kaç saatlik veri kaybını göze alıyorsunuz?

Yedekleme aslında teknik değil, ticari bir karardır ve iki soruya iner. Birincisi: sistem çöktüğünde ne kadar geriye dönmeye razısınız? Gece yarısı yedek alınıyorsa ve arıza akşam beşte olduysa, o günkü tüm siparişler, teklifler ve kayıtlar gitmiş demektir. Bunu kabul ediyorsanız sorun yok; kabul etmiyorsanız yedekleme sıklığının artması gerekir. İkincisi: sistem kaç saat kapalı kalabilir? Yarım gün mü, iki gün mü? Bu cevap, yedeğin nerede ve hangi biçimde tutulacağını doğrudan belirler, çünkü uzak bir depodan büyük bir veriyi indirip kurmak saatler alır.

Bu iki soruya cevap veren kişi bilgi işlem değil, işletme yönetimidir. Bilgi işlemin işi, verilen cevabı mümkün kılan kurulumu yapmak ve maliyetini söylemektir. Bu konuşma yapılmadığında ortaya çıkan şey, kimsenin bilinçli olarak seçmediği bir risk seviyesidir: yedek gecelik alınır, kimse sormaz, bir gün bir günlük veri kaybedilir ve o zaman bunun hiç kararlaştırılmamış olduğu anlaşılır.

Son olarak sorumluluğun bir isme bağlı olması gerekir. "Yedekler alınıyor" cümlesinin öznesi bir yazılım değil bir kişi olmalı; bildirimleri okuyan, tatbikatı takvime koyan, yeni bir sistem devreye girdiğinde onu yedekleme kapsamına ekleyen bir kişi. Bu kişi dışarıdan hizmet aldığınız firma da olabilir, ama o zaman da sözleşmede yedekleme sıklığının, saklama süresinin ve geri dönüş sorumluluğunun açıkça yazılı olması gerekir. Dışarıya verilen iş, tarif edilmediği sürece verilmiş sayılmaz.

Kısaca

• Yedeğin varlığı değil, o yedekten geri dönülebildiğinin denenmiş olması önemlidir; denenmemiş yedek yedek sayılmaz.
• En az bir kopya, ofisteki ağdan erişilemeyen ayrı bir yerde durmalı; aynı sunucudaki veya aynı ağdaki kopya fidye yazılımına karşı korumaz.
• Klasör kopyalamak yetmez: veritabanları kendi yöntemiyle, tutarlı biçimde yedeklenmeli; ayarlar, e-postalar ve yerel makinelerdeki veriler listeye eklenmeli.
• Yedekleme sessizce bozulur; sonucun düzenli bildirilmesi ve bu bildirimlere fiilen bakan biri olması gerekir.
• Kaç saatlik veri kaybını ve kaç saatlik duruşu göze aldığınız, bilgi işlemin değil yönetimin kararıdır; bu karar verilmeden doğru kurulum tasarlanamaz.