Yedekleme ve geri yükleme: Yazılım sürekliliğinin gerçek testi

Yedekleme panelinde her gece yeşil bir işaret görünüyor. Bir gün kayıtlar yanlışlıkla silindiğinde dosyanın mevcut olduğu anlaşılıyor, fakat uygulamanın ihtiyaç duyduğu ekler ve yapılandırma aynı pakette bulunmuyor. Veri tabanı geri geliyor; çalışan sistem geri gelmiyor. Yedekleme ile geri yükleme arasındaki fark, böyle bir olayın ortasında öğrenilmemelidir.

Yazılım sürekliliği için soru “Yedek alıyor muyuz?” ile bitmez. Neyin korunduğu, hangi zamana dönülebileceği, geri dönüşü kimin yapacağı ve sonucun nasıl doğrulanacağı belirlenmelidir. Bir kopyanın varlığı önemli bir başlangıçtır; işletmenin yeniden iş yapabilmesi daha kapsamlı bir hedef oluşturur. Bu hedefin kanıtı, planlı ve kontrollü geri yükleme denemesidir.

Önce kaybın iş açısından anlamını konuşun

Bir günlük kayıt kaybı her işletmede aynı sonucu doğurmaz. Bazı bilgiler başka bir kaynaktan yeniden oluşturulabilir; bazı işlemleri tekrar elde etmek çok güç olabilir. Kayıp toleransını tanımlamak için hangi işin hangi veriye bağlı olduğunu inceleyin. Kritik kayıtlar ile yeniden üretilebilir özetlerin aynı koruma ihtiyacına sahip olduğu varsayılmamalıdır.

Hizmetin ne kadar süre kullanılamayabileceği ayrı bir sorudur. Veri kaybının kabul edilebilir aralığı ile çalışmaya dönme hedefi birbirine karıştırılmamalıdır. Çok yeni bir yedeğiniz bulunabilir, ancak büyük hacmi geri yüklemek uzun sürebilir. Tersine sistem hızla açılabilir fakat eski veriyle çalışıyor olabilir. İki hedef birlikte değerlendirilmelidir.

İşletme hedef belirlerken teknik uygulanabilirliği de konuşur. İstenen süreler mevcut altyapı ve bütçeyle sağlanamıyorsa bunu baştan görmek gerekir. Kâğıtta kısa süre yazmak hazırlığı oluşturmaz. Hangi alternatif iş yönteminin kullanılacağı, ne kadar süreyle sürdürülebileceği ve hangi işlemlerin bekleyeceği açıkça belirlenebilir.

Uygulamanın tamamını envantere alın

Veri tabanı çoğu uygulamanın merkezindedir, ancak bütün sistem değildir. Yüklenen belgeler, görseller, yapılandırmalar, zamanlanmış işler ve gerekli bağlantı bilgileri başka yerlerde bulunabilir. Kaynak koddan yeniden üretilebilecek bileşenler ile ayrıca korunması gereken veriler ayrılır. Bir parçanın varlığı diğerinin güncel olduğunu kanıtlamaz.

Envanterde her öğenin sahibi, konumu, korunma yöntemi ve geri dönüşteki rolü yazılır. Hesap erişimi veya şifreleme anahtarı olmadan kullanılmayacak bir kopya pratikte eksik kalabilir. Bu bilgileri yedeğin yanına açık metinle koymak yerine uygun erişim ve kurtarma düzeni oluşturulur. Kurtarma için gereken yetki, günlük geliştirme yetkisiyle aynı olmak zorunda değildir.

Dış servislerde tutulan bilgiler de değerlendirilmelidir. İşletme hangi veriyi kendisi dışarı aktarabilir, sağlayıcının saklama koşulları nedir ve hangi davranış doğrudan işletmenin kontrolünde değildir? Sağlayıcının bir özelliği bulunduğunu duymak yerine hesabın etkin ayarlarını kontrol etmek gerekir. Varsayımlar envanterde açıkça işaretlenir.

Otomatik yedekleme takip edilmeyen yedekleme değildir

İnsanların hatırlamasına bağlı düzenler kolayca aksayabilir. Uygun otomasyon bu yükü azaltabilir, fakat işin başarısızlığının fark edilmesi yine planlanmalıdır. Başarı ve hata bildirimlerinin nereye gittiği, kimin kontrol ettiği ve beklenmeyen boyut değişiminin nasıl yorumlandığı belirlenir. Bildirim üretilmesi, birinin onu değerlendirdiği anlamına gelmez.

Yedeğin düzenli oluşması ile içeriğinin kullanılabilir olması farklı kontrollerdir. Boş veya eksik veri de teknik olarak başarıyla kopyalanabilir. Yönteme uygun bütünlük kontrolleri ve geri yükleme denemeleri bu nedenle gereklidir. Bir aracın başarılı sonucu, işletmenin tüm kritik bilgisinin korunduğuna dair sınırsız güvence gibi sunulmamalıdır.

Saklama düzeni de amaca göre kurulur. Yanlış silme hemen fark edilmeyebilir; yalnızca en son kopyayı tutmak daha eski doğru duruma dönmeyi engelleyebilir. Öte yandan bütün kopyaları süresiz saklamak maliyet ve veri yönetimi yükü yaratır. Tarih aralıkları, saklama süresi ve silme koşulları işletmenin ihtiyaçlarıyla birlikte kararlaştırılır.

Kopyaları aynı olaydan etkilenmeyecek biçimde düşünün

Çalışan sistemle aynı erişim ve aynı depolama sınırında tutulan tek kopya, bazı arızalarda yeterli koruma sağlamayabilir. Yanlış silme, hesap sorunu veya zararlı işlem hem sistemi hem kopyayı etkileyebilir. Yedeklerin ayrılığı ve kimlerin değiştirebildiği, korunmak istenen olay türüne göre değerlendirilir. Her yapı için aynı yöntem uygun olmayabilir.

Koruma düzeninin güvenliği yalnızca depolama konumundan ibaret değildir. Okuma, silme ve geri yükleme yetkileri gözden geçirilir; erişim gerektiğinde izlenebilir olmalıdır. Şifreli kopyada gerekli anahtarların kaybı da kurtarma sorununa dönüşebilir. Anahtar kurtarma yöntemi yetkili kişilerin kullanabileceği, ancak gereksiz erişime açılmayan bir düzende tutulur.

Birden fazla kopyanın bulunması bu kontrolleri gereksiz yapmaz. Aynı eksik veri birçok yere kopyalanmış olabilir. Amaç yalnızca sayıyı artırmak değil, belirlenen kayıp senaryolarına karşı çalışabilir seçenek oluşturmaktır. Seçilen düzenin hangi olayları karşıladığı ve hangi sınırlamaları bıraktığı anlaşılır biçimde yazılmalıdır.

Geri yükleme denemesini üretimden ayırın

Deneme, canlı sisteme kontrolsüz veri yazmamalıdır. İzole bir ortam hazırlanır; dış bildirimler, ödeme bağlantıları ve otomatik işler güvenli biçimde ele alınır. Geri gelen uygulamanın gerçek müşterilere mesaj göndermesi veya canlı kayıtlara müdahale etmesi önlenmelidir. Ortamın yalnızca deneme için kullanıldığı ekip tarafından anlaşılmalıdır.

Kurgusal bir proje yönetimi uygulamasını düşünün. Veri tabanı geri yüklendiğinde proje listesi açılıyor, fakat ilgili sözleşme dosyaları görüntülenmiyor olsun. Ana sayfanın açılmasıyla denemeyi başarılı saymak bu eksikliği saklar. Proje kaydı, ilişkilendirilmiş belge ve yetkili kullanıcının erişimi birlikte denendiğinde eksik dosya depolaması fark edilir.

Denemede kullanılan veri gerçek kişilere aitse erişim ve saklama koşulları korunur. Test ortamına taşınması veriyi önemsiz hâle getirmez. İş bittikten sonra ortamın ve kopyaların nasıl kaldırılacağı planlanır. Ekran görüntüsü veya rapor hazırlarken de gereksiz kişisel bilgi paylaşılmaz; doğrulama kanıtı amaca uygun sınırlanabilir.

Dosyanın açılması yerine işin tamamlanmasını doğrulayın

Doğrulama listesi uygulamanın işlevine göre hazırlanır. Önemli kayıtlar bulunabiliyor mu, bağlı dosyalar açılıyor mu, kullanıcı yetkileri doğru mu? Yeni bir işlem güvenle oluşturulabiliyor mu? Kritik raporun örnek hesabı beklenen sonucu veriyor mu? Kontroller, geri yüklenen uygulamanın yalnızca teknik olarak başlamadığını göstermelidir.

Tarih ve zaman tutarlılığına da bakılır. Farklı anlara ait veri ve dosyalar birlikte kullanıldığında eksik bağlantılar oluşabilir. Hangi zamana dönüldüğü ve hangi işlemlerin kapsam dışında kaldığı açıkça kaydedilir. İşletmenin sonradan tamamlayacağı işler varsa bunların nasıl bulunacağı ve yeniden işleneceği belirlenir.

Bütün kontrolleri tek bir kişinin hatırlamasına bağlamayın. Yazılı adımlar başka yetkili bir kişi tarafından takip edilebilir olmalıdır. Deneme sırasında anlatılmadan yapılamayan adımlar dokümana eklenir. Kullanılan komutların yanında ön koşullar, karar noktaları ve beklenen sonuç da açıklanır; yalnızca teknik satır listesi yeterli olmayabilir.

Süreyi ve karar noktalarını kaydedin

Geri yükleme süresi yalnızca dosya kopyalamanın süresi değildir. Olayın değerlendirilmesi, doğru kopyanın seçilmesi, ortamın hazırlanması, verinin taşınması ve doğrulama zaman alabilir. Denemede bu adımlar ayrı görüldüğünde iyileştirmenin nerede gerektiği anlaşılır. Toplam sonucu tek bir araç çıktısına indirgemek gerçek hazırlığı olduğundan güçlü gösterebilir.

Geri dönüş kararı yetkili bir kişi tarafından verilir. Yeni sistemde bazı kayıtlar oluşmuşken eski duruma dönmek veri kaybı yaratabilir. Canlı olayda mevcut verinin korunması ve yapılacak işlemin etkisinin incelenmesi önemlidir. Acil durumda bütün adımların yeniden tartışılmaması için karar yetkileri önceden belirlenir; yine de her olayın koşulu değerlendirilir.

İşletmeye dönüş duyurusu da planın parçasıdır. Sistemin hangi tarihteki veriye döndüğü, kullanıcıların hangi işleri kontrol edeceği ve açık sınırlamalar anlaşılır biçimde paylaşılır. Teknik kurtarmanın bitmesi, iş kayıtlarının tamamlandığı anlamına gelmeyebilir. Kalan operasyon işlerinin sahibi ve takip yöntemi belirtilir.

Denemeden çıkan eksikler plana dönsün

Eksik dosya, erişilemeyen hesap veya beklenenden uzun bir adım bulunduğunda düzeltme işi açılır. Sorumlu, hedef ve tekrar denenecek kontrol belirlenir. Aynı eksikliği her dönem rapora yazmak yerine düzeltmenin doğrulandığı görülebilmelidir. Yeni bir modül veya depolama alanı eklendiğinde envanter ve deneme kapsamı güncellenir.

Yedek ve geri yükleme düzenini özel yazılım projesinin teslim koşullarına bağlamak, bu sorumlulukların yayından sonra unutulmasını azaltır. İşletmenin elinde yalnızca bir yedek bulunduğu bilgisi değil, hangi koşulda ne yapılacağını anlatan uygulanabilir bir plan olmalıdır. Denemenin değeri güven verici bir rapor üretmekten çok eksikleri gerçek ihtiyaç ortaya çıkmadan görmektir.

Geri yükleme ile hatalı işlemi düzeltmeyi karıştırmayın

Her yanlış kayıt için bütün sistemi eski bir tarihe döndürmek uygun olmayabilir. Arada doğru işlemler oluşmuşsa bunları da kaybetme riski vardır. Bazen belirli kaydın kontrollü düzeltilmesi veya sınırlı bir verinin ayrı ortamdan alınması değerlendirilir. Uygun yöntemi seçmek için olayın kapsamı ve mevcut verinin durumu incelenmelidir.

Bu ayrım işletmenin beklentisini de etkiler. “Yedekten alırız” cümlesi tek bir dosyanın bulunmasını veya bütün veri tabanının geri çevrilmesini anlatıyor olabilir. Hangisinin mümkün olduğu ve hangi hazırlığı gerektirdiği somutlaştırılır. Deneme sırasında farklı kurtarma ihtiyaçlarını konuşmak, gerçek olayda gereksiz geniş bir müdahale yapılmasını önlemeye yardımcı olur.

Yetkili kişi bulunamadığında plan durmasın

Birincil sorumlu izinli veya erişilemez olduğunda alternatif yetkilinin hangi adımları yapabileceği belirlenir. Bu kişi gerekli hesaplara kontrollü biçimde ulaşabilmeli ve hangi kararları tek başına veremeyeceğini bilmelidir. Herkese bütün erişimi açmak yerine görev ve yetki düzeni tanımlanır. Kurtarma planı belirli bir kişinin sürekli çevrimiçi olmasına dayanmamalıdır.

İletişim listesi uygulamanın içinde tutuluyorsa uygulama erişilemezken nasıl bulunacağı düşünülmelidir. Aynı durum kurulum yönergeleri ve hesap kurtarma bilgisi için de geçerlidir. Gerekli dokümanın kontrollü alternatif erişimi hazırlanabilir. Son denemede kullanılan erişimlerin hâlâ geçerli olup olmadığı dönemsel olarak gözden geçirilir; personel değişikliği bu kaydın güncellenmesini gerektirebilir.

Sık Sorulan Sorular

Hosting sağlayıcısının yedeği yeterli mi?

Sağlayıcının sunduğu kapsam, saklama süresi, erişim ve geri dönüş yöntemi incelenmelidir. Hizmetin varlığı uygulamanın bütün bileşenlerinin kapsandığını göstermez. İşletmenin ihtiyaçlarıyla karşılaştırıp geri yükleme denemesi yapmak, yeterliliği varsaymak yerine doğrulamaya yardımcı olur.

Yedekleme ne sıklıkta yapılmalı?

Kabul edilebilir veri kaybı, işlem sıklığı ve kullanılan yönteme göre belirlenmelidir. Her uygulama için tek doğru aralık yoktur. Planlanan sıklığın gerçekten uygulandığı ve geri dönülebilecek zamanın işletmenin beklentisiyle uyumlu olduğu kontrol edilmelidir.

Senkronize klasör bir yedek sayılır mı?

Senkronizasyon bazı ihtiyaçlara yardımcı olabilir, fakat silme veya bozulma diğer kopyalara da taşınabilir. Sürüm geçmişi, saklama ve ayrılık özellikleri değerlendirilmeden tam kurtarma çözümü sayılmamalıdır. Seçilen aracın hangi kayıp senaryosunu karşıladığı açıkça anlaşılmalıdır.

Geri yükleme denemesini canlı sitede mi yapmalıyız?

Kontrolsüz biçimde canlı verinin üzerine yazılmamalıdır. İzole ortam ve güvenli bağlantı ayarlarıyla deneme yapılabilir. Bildirim, ödeme ve zamanlanmış işlerin gerçek işlemleri etkilememesi sağlanır. Canlı kurtarma gerektiren bir olay ise yetkili kişilerce ayrıca planlanır.

Deneme başarılıysa bir daha yapmak gerekir mi?

Uygulama, veri hacmi, erişimler ve bağlı hizmetler değişebilir. Önceki başarı gelecekteki bütün koşulları kanıtlamaz. Tekrar düzeni işin kritikliğine göre belirlenir; önemli değişikliklerden sonra kapsam yeniden incelenebilir. Amaç güncel sistemi kurtarabilecek hazırlığı korumaktır.