Veri yedekleme ve geri yükleme nasıl planlanır: kaydınız şu anda kaç yerde duruyor

Veri yedekleme ve geri yükleme planı, kaydın ömrünün her anında kaç yerde durduğunu ve kaybolursa hangi kopyanın onu geri getireceğini yazar. Envanterin uzunluğunu kaydın izlediği yol belirler; o yol hangi deponun neyi tutacağına karar verilirken çizilir. AlgoKlima’da kapsama dışında açılan servis kaydı sunucuya ulaşana kadar tek nüshadır; o saatlerde alınan yedeklerin hiçbirine girmez.

Yedek planı “ne sıklıkla” sorusundan önce “kayıt şu anda kaç yerde” sorusuna cevap verir

Satıcıya sorulan soru genellikle sıklıktır: yedek ne kadar sık alınıyor. Cevap gelir, plan tamam sayılır, konu kapanır. Kapanmayan şey sorunun taşıdığı varsayımdır. Sıklık sorusu, kaydın nerede durduğunun zaten bilindiğini kabul eder ve yalnız o bilinen yerin ne kadar sık kopyalandığını ölçer. Envanter bilinmiyorsa sıklık cevabı hiçbir şeyi güvenceye almaz; yalnız bilinen yere ne olacağını söyler.

Envanterin sabit olmaması işi zorlaştırıyor. Aynı kayıt açıldığı anda başka bir yerde, saatler sonra başka bir yerde, gece geçtiğinde yine başka bir yerde durur. Yer sayısı da yol boyunca değişir: kimi anda tek, kimi anda değil. Bu yüzden plan tek bir “yedek” satırıyla kapanmaz. Kaydın izlediği yolun her durağı ayrı bir satırdır ve her satırın kendi cevabı vardır.

İşlettiğimiz AlgoKlima’da bu yol açıkça görülüyor. Servis kaydı sahada açılıyor ve telefonun yerel kuyruğunda tutuluyor; bağlantı geri geldiğinde veritabanına ulaşıyor. Yedek ancak sunucudaki veritabanından alınabilir. Yani kaydın ömrünün bir bölümü, yedek alma işleminin hiç uzanamadığı bir yerde geçiyor. Takvim bu bölümü göremez, çünkü takvim yalnız kendi eriştiği depoyu tarar.

Depoların ayrılması yalnız sahaya özgü değil. Şu an inşa ettiğimiz Secretum’da karakter kaydı ile o kaydın ürettiği görsel ayrı depolarda duruyor; kaydı geri yüklemek dosyayı geri getirmiyor. Kayıt ile dosyanın ayrı kalemler olduğunu ve devir masasında nasıl ayrı sınandığını yazılım teslim alırken neyi devraldığınızı yazdığımız devir listesinde ayrıca kurduk.

“Yedek neyi kaçırır” sorusu devir listesinin sorusudur ve orada cevaplanır. Bu yazının sorusu daha önce geliyor: kayıt şu anda kaç yerde duruyor. Envanter cevaplanmadan kaçan kalem zaten ölçülemez, çünkü neyin kaçtığını görmek için önce neyin nerede olduğunu bilmek gerekir.

Envanteri çıkarmanın görünürdeki alternatifi barındırma sağlayıcısının paneline bakmaktır: orada bir yedek listesi durur ve tarihleri okunur. O liste sağlayıcının eriştiği diskin kopyalanma kaydıdır; kaydınızın yolculuğunu değil, sağlayıcının gördüğü yüzeyi anlatır. Panelde her tarih yeşil görünürken sahada açılmış bir kaydın hiçbir satırda geçmemesi mümkündür ve panel bunu size söylemez. Envanteri kaydın izlediği yol belirler.

Kaydın yalnız sunucuda açıldığı ve hiçbir dosya taşımadığı bir sistemde envanter tek satırdır. O satırı yazmak kısa bir iştir ve plan gerçekten sıklık sorusuyla devam edebilir. Ayrımı yapmadan sıklığa geçmek ise, envanteri tek satır olmayan bir işletmede planı en zayıf yerinden boş bırakır.

Kapsama alanının dışında açılan kayıt bağlantı dönene kadar tek nüshadır

Saha işinin geçtiği yerler sinyalin zayıf olduğu yerlerdir. Teknisyenin işi çoğu zaman binanın en alt katındaki kazan dairesindedir ve kapsama alanı orada biter. İşletip geliştirmeyi sürdürdüğümüz AlgoKlima tam bu koşula göre kuruldu: teknisyen bağlantı beklemeden kaydı açıp kapatabiliyor, kayıt telefonun yerel kuyruğunda tutuluyor ve bağlantı geri geldiğinde veritabanına ulaşıyor. Kuyruğun nasıl çalıştığını, kaydın hangi sırayla ilerlediğini sahada çevrimdışı çalışan uygulamayı anlattığımız yazıda yazdık.

Sonuç şu: bağlantı dönene kadar o kayıt yalnız telefonda duruyor. Sunucunun o kayıttan haberi yok. Kayıt bir taslak değil; tamamlanmış bir servis kaydı ve tek nüsha.

Yedek planı açısından bunun bedeli tek cümleye sığıyor. Bu pencere boyunca alınan sunucu yedeklerinin hiçbiri o kaydı içermez. İçeremez, çünkü yedek sunucudaki veriyi kopyalar ve kayıt sunucuda henüz yoktur. Bu, yedeğin kötü yapılandırılmış olmasıyla ilgili bir kusur değil; yedeğin ne olduğunun doğrudan sonucu.

Bundan çıkan başka bir sonuç daha az beklenendir: yedeğin sıklığını artırmak pencereyi değiştirmez. Gece alınan yedeği öğlene de çekseniz, aralığı daha da kısaltsanız, telefonda bekleyen kaydın durumu aynı kalır. Sıklık sunucudaki verinin kopyalanma aralığını kısaltır; sunucuda olmayan veriye dokunmaz. Yedek planlarının en pahalı yanlış anlaşılması burada yaşıyor: pencere bir yedek ayarıyla kapatılabilir sanılıyor.

Kaydın sunucuda açıldığı bir uygulamada bu pencere hiç yok; bedeli ise şudur: bağlantı yokken kayıt hiç oluşmaz, teknisyen işini bırakıp sinyal aramak zorunda kalır. Pencereyi kapatmanın yolu kaydı sahada açılamaz kılmaktan geçiyorsa, kapatılan şey pencere değil işin kendisidir.

Plan pencereyi kapatamaz, adlandırabilir: cihaz da bir konumdur

Pencerenin uzunluğunu ne belirliyor sorusunun cevabı yedek takvimi değil. Kapsama alanının ne zaman geri geldiği belirliyor. Bu, yazılımın da işletmenin de doğrudan yönetemediği bir değişken: bina, kat, saha koşulu. Yönetilemeyen bir değişkenin uzunluğu plana bir süre olarak yazılamaz; ama varlığı yazılabilir ve yazılmalıdır.

Pencereyi kullanıcı disiplinine bağlamak da işe yaramıyor. “Teknisyen akşam ofise dönünce gönderir” satırı bir plan satırı değil, bir temennidir; kaydın nerede durduğunu değişmiş göstermez, yalnız sorumluluğu insana devreder. Plan, teknisyen doğru davransa bile kaydın o saatlerde nerede olduğunu yazmak zorundadır.

Bu yüzden yedek planı telefonu bir konum olarak yazar. Konum listesinde sunucu, yedek ortamı ve cihaz yan yana durur. Cihaz satırının yanına da o konumdaki kaybın adı yazılır: telefonun kaybolması, uygulamanın silinmesi, cihazın değiştirilmesi. Bu durumların hepsinde, pencerede bekleyen kaydı hiçbir sunucu yedeği geri getiremez. Cümle sert görünüyor ve öyle olması gerekiyor; planın işi kaybın sınırını okunur kılmak.

Cihaz tarafında ayrıca bir yedek alındığını söylemiyoruz; böyle bir kalem varsa onu kendi kurulumunuzun belgelerinden okursunuz. Aynı sebeple bu yazı AlgoKlima’nın yedek takvimini de anlatmıyor: plana yazılacak takvim sizin kurulumunuzun takvimidir.

Pencereyi adlandırmanın pratik karşılığı bir soru listesidir. Sahada bir günde kaç kayıt açılıyor, bu kayıtların ne kadarı kapsama alanının dışında başlıyor, kapsama alanına dönüş tipik olarak ne zaman oluyor. Bu soruların cevabı sizin sahanızdan çıkar ve plana o cevaplarla yazılır; yazının verebileceği şey soruların kendisidir.

İşin tamamı kapsama içinde dönen ekiplerde cihaz satırı “yok” diye yazılır, silinmez. Silinen satır ile boş satır aynı şey değil: boş satır o kaybın sizde olamayacağını kaydeder, silinen satır sorunun hiç sorulmadığını.

Kaydın ömrü boyunca onu geri getirebilecek kopya değişir

Yedek planlarının çoğu kaydı tek bir hâlde düşünür: sunucuda duran bir satır. Oysa aynı kayıt ömrünün her aşamasında farklı sayıda yerde durur ve her aşamada onu geri getirebilecek kopya başkadır. Planı okunur kılan şey bu aşamaları yan yana koymaktır; her satır aynı sorulara cevap verir.

Sayarken bir ayrımı korumak gerekiyor: envanterde satır tutan şey depodur, ekran değil. Ofis panelinin ekrana bastığı okumaları hızlandıran önbellek veritabanından türetilir; kendi başına bir kopya değildir ve envanterde satır tutmaz. Türetilmiş veriyi kopya saymak, envanteri olduğundan güvenli gösterir.

Tablonun alt satırları plan aşamasının satırlarıdır: yedek alınmış ve geri yüklenmiş bir kaydın envanterde nasıl görüneceğini gösterirler. Tabloyu kendi planınızı kurarken iskelet olarak kullanabilirsiniz; satırların hangi depolara karşılık geldiğini sizin kurulumunuz doldurur.

Pencere sunucuda yeniden açılır: kuyruk boşaldığı andan yedek alındığı ana kadar

Kayıt veritabanına ulaştığında rahatlama gelir: artık sunucuda, güvende. Rahatlama erken. Kayıt tek nüsha olmaktan çıkmadı; yalnız yer değiştirdi. Bir sonraki yedek alınana kadar o kaydı içeren tek depo sunucudaki veritabanıdır. Sunucu tarafındaki bir kayıp o anda gerçekleşirse, geri dönülecek yedekte o kayıt yoktur.

Bu pencerenin uzunluğunu yedek takvimi belirler ve işte sıklık sorusunun gerçekten anlamlı olduğu tek yer burasıdır. Sıklığı artırmak sahadaki pencereye dokunmaz, ama sunucudaki pencereyi kısaltır. Sorunun yanlış olmadığını, yalnız yanlış yere sorulduğunu görmek planı baştan kurar: sıklık, envanterin belirli bir satırının cevabıdır, planın tamamının değil.

Telefondaki nüshanın kuyruk boşaldıktan sonra kalıp kalmadığı ayrı bir sorudur ve cevabı yazılımın verdiği bir karardır. Sizin planınız açısından bu satır boş bırakılamaz: cevabı satıcınızdan alın ve plana yazın. Nüsha kalıyorsa sunucu kaybında elinizde bir şey vardır; kalmıyorsa yoktur. Bu hâller birbirine hiç benzemiyor ve aradaki farkı ancak yazılı bir cevap gösterir.

Envanter sayılırken sık yapılan bir hata daha var: aynı veritabanına bağlı arayüzleri ayrı kopya saymak. Ofiste açılan panel ile sahadaki uygulama aynı veriyi okur; ekranlar ayrıdır, depo değil. Ekranı kopya sayan bir envanter, tek bir depo kaybında geriye ne kalacağını olduğundan iyimser gösterir. Sayım kuralı basit: ne kadar depo varsa o kadar satır.

Bu sayım kuralının satın alma tarafında da karşılığı var. Yeni bir arayüz eklemek envanterinizi güçlendirmez; yeni bir depo eklemek ise plana yeni bir satır, yeni bir kayıp ihtimali ve yeni bir geri yükleme sorusu getirir. Depo eklemeye değer olduğu durumlar var; ama kararın bedeli plan satırında görünür olmalı, sonradan arıza gününde değil.

Yedek bir kopyadır, geri dönüş bir provadır

“Yedeğimiz var” cümlesi çoğu zaman doğrudur ve çoğu zaman soruyu cevaplamaz. Alınmış ama hiç geri yüklenmemiş bir yedek, geri yüklenebildiğinin kanıtı değildir; denenmemiş bir varsayımdır. Dil bunu taşıyabilir: “yedek var” yerine “yedek alınıyor” demek, cümleyi kanıtın olduğu yere geri çeker.

Aradaki farkı kapatan şey provadır. Prova, yedeği ayrı bir ortama geri yüklemek ve geri gelen kaydı işin her yüzünden okumaktır. Devir masasında yapılan yeniden kurma provasıyla karışmaması gerekiyor: devir provası yalnız teslim anında yapılır ve sistemin sizde yeniden kurulabildiğini ölçer. Buradaki prova tekrarlanır ve yedeğin geri yüklenebildiğini ölçer. Devir provasının nasıl kurulduğunu devir listesi yazımızda ayrıntısıyla yazmıştık; bu yazıdaki prova ondan sonra gelen, işletme boyunca tekrar eden bir iştir.

AlgoKlima için provanın okuma listesi somut. Geri yüklenen veritabanı, ofisten okunduğunda da sahadan okunduğunda da müşteriyi ve cihazı tek kayıt olarak gösteriyor mu; garanti ile bakım kalemleri hâlâ ilgili cihazın altında duruyor mu. Cevaplar evetse yedek yalnız alınmış değil, geri yüklenebilir olduğunu da göstermiştir. Cevap hayırsa yedek dosya olarak yerinde durup işletme olarak boş çıkmıştır ve bunu arıza gününde öğrenmek en pahalı öğrenme biçimidir.

Okumanın ayrı bir ortamda yapılması da bir gereklilik. Yedeği çalışan sistemin üstüne geri yüklemek provayı sınamaya değil kayıp riskine çevirir; çalışan kayıtların üstüne eski bir kopya yazılır. Ayrı ortam, provanın yanlış çıkmasına izin verdiği için provadır. Yanlış çıkamayan bir sınama zaten sonuç üretmez.

Provanın tekrarlanan bir satır olması önemli. Tek seferlik prova yalnız o günün yedeğini kanıtlar. Sistem değişir, yeni alanlar eklenir, depolar ayrılır; geçen ay geri yüklenebilen bir yedek bu ay eksik geri yüklenebilir. Plan bu yüzden provayı tekrar eden bir satır olarak yazar.

Bir sınırı da olduğu gibi bırakalım. Yedeği de geri yüklemeyi de sağlayıcının yaptığı, sizin kendi başınıza geri yükleme yapamadığınız bir kurulumda “yedek var” cümlesi satıcının beyanıdır, sizin kanıtınız değil. Bu durumda planın yazabileceği şey provanın kendisi değil, provayı kimin isteyeceği ve sonucun size hangi biçimde gösterileceğidir.

Prova neyi ölçer: geri dönülen an ile arıza anı arasında hangi kayıtlar var

Provanın ürettiği asıl bilgi bir kayıt listesidir. Yedek alındığı andan sonra veritabanına ulaşmış kayıtlar o yedekte yoktur; geri yükleme yapıldığında da gelmezler. Bu kayıtlar bir arıza sonrasında sessizce eksilir, çünkü sistem çalışır durumda açılır ve eksik olan şey bir hata mesajı vermez. Prova, o listenin hangi işlerden oluştuğunu arıza olmadan önce gösterir: hangi servis çağrıları, hangi cihaz kayıtları, hangi güncellemeler.

Listenin uzunluğunu bu yazıda bir sayıya bağlamıyoruz, çünkü uzunluk sizin işinizin yoğunluğuna ve yedek aralığınıza göre değişir. Ölçünün adı plana yazılır, değeri her işletmenin kendi verisinden çıkar.

Listenin planı geri beslemesi de provanın işi. Aradaki kayıtlar sizin işinizde katlanılabilir bir kayıpsa yedek aralığı olduğu gibi kalır. Katlanılamıyorsa değişecek şey yedek aralığıdır ve o karar artık bir tahmine değil, provanın çıkardığı listeye dayanır. Sıklık sorusu böyle cevaplanabilir hâle geliyor: envanterden sonra, prova listesinden okunarak.

Arıza anında telefonda bekleyen kayıtlar ayrı bir soru doğuruyor. Sunucu geri yüklendikten sonra kuyrukta bekleyen kayıtlar geri yüklenmiş veritabanına akar mı, akarsa hangi hâlde akar. Bu sorunun cevabını bir yazı veremez; cevabı kendi sisteminizde koştuğunuz prova verir. Provayı kurarken bu satırı listeye ekleyin: geri yüklenmiş sunucuya karşı bekleyen kuyruk ne yapıyor.

Kaydın hangi depolarda duracağı, hangi deponun neyi tutacağı, hangi arayüzün hangi depoyu okuyacağı; bunların hepsi henüz hiçbir kayıt açılmadan önce verilen kararlar. Devralınan bir sistemde bu kararların size ne bıraktığını mimarinin koddan önce geldiğini anlattığımız yazıda ayrıca açtık.

Bu kararları nasıl verdiğimizi, depolama düzenini ve tek veritabanına kaç arayüzün bağlanacağını sistem mimarisi sayfasında yazdık.