Veri yedekleme ve kurtarma planı nasıl hazırlanır?

1. Önce veriyi ve bağımlı olduğu sistemleri envantere alın

Planın ilk adımı “Her şeyi yedekleyelim” demek değil, işletmenin çalışması için hangi verinin gerçekten gerekli olduğunu görünür kılmaktır. Müşteri ve sipariş kayıtları, muhasebe belgeleri, ürün içerikleri, kullanıcı dosyaları, uygulama veri tabanları, kaynak kodu ve yapılandırmalar farklı sahipliğe ve etkiye sahiptir. Her veri kümesi için sorumlu ekip, bulunduğu sistem, güncellenme sıklığı, hassasiyet düzeyi ve kayıp hâlinde etkilenecek süreç kaydedilmelidir.

Yalnızca ana veri tabanını listelemek yeterli değildir. Bir uygulamanın çalışması; dosya deposuna, kimlik hizmetine, alan adı ayarlarına, zamanlanmış görevlere, şema sürümüne ve dış servis bağlantılarına bağlı olabilir. Veriyi geri getirip bu bağımlılıkları kuramamak, teknik olarak başarılı görünen bir yedeği kullanılamaz hâle getirir. Envanter, verinin yanında sistemi yeniden oluşturmak için gereken belgeleri ve yapılandırmaları da göstermelidir.

• Veri kümelerini, sahiplerini, konumlarını ve bağlı oldukları iş süreçlerini listeleyin.
• Kayıp etkisini operasyon, gelir, müşteri güveni ve yasal yükümlülük açısından değerlendirin.
• Uygulamayı yeniden çalıştırmak için gereken yapılandırma ve bağımlılıkları veriyle birlikte kaydedin.

2. Ne kadar veri ve zaman kaybının kabul edilebilir olduğunu belirleyin

Bütün sistemler aynı sıklıkta yedeklenmek ve aynı hızda geri dönmek zorunda değildir. Önce her kritik süreç için kabul edilebilir veri kaybı aralığını belirleyin. Gün boyunca sürekli işlem alan bir sipariş sistemiyle ayda bir güncellenen bir belge arşivinin aynı hedefe sahip olması gereksiz maliyet veya yetersiz koruma doğurabilir. Teknik ekiplerin “kurtarma noktası hedefi” olarak adlandırdığı bu karar, yedekleme sıklığının iş ihtiyacından türetilmesini sağlar.

İkinci karar, hizmetin ne kadar süre kapalı kalabileceğidir. Kurtarma süresi hedefi yalnızca dosyanın indirilme hızını değil; sorunun anlaşılması, doğru kopyanın seçilmesi, ortamın hazırlanması, verinin geri yüklenmesi ve kontrollerin tamamlanmasını kapsar. Hedefleri yönetim, operasyon ve teknik ekip birlikte belirlemelidir. “Hiç veri kaybolmasın ve sistem hiç durmasın” isteği anlaşılır olsa da mimari, maliyet ve operasyon karşılığı konuşulmadan uygulanabilir bir plan değildir.

3. Tek kopyaya ve tek arıza alanına bağımlı kalmayın

Üretim sistemiyle aynı hesapta, aynı cihazda veya aynı depolama alanında tutulan tek bir kopya ortak bir hatadan etkilenebilir. Donanım arızası, yanlış yetki, yazılım hatası, zararlı işlem veya insan hatası hem asıl veriyi hem yakınındaki yedeği silebilir. Bu nedenle kopyaların konumu, erişim sınırı ve hata alanı birlikte düşünülmelidir. Yerel hızlı kurtarma kopyası ile farklı bir konumda veya ayrı güvenlik sınırında saklanan kopya farklı riskleri karşılar.

Yedekleme mimarisini seçerken verinin büyüklüğünü, değişim hızını, ağ kapasitesini ve geri yükleme süresini hesaba katın. Tam, artımlı ve anlık görüntü türleri farklı avantajlara sahiptir; kullanılan aracın adından çok, beklenen arıza durumunda oluşturduğu kurtarma zinciri önemlidir. Bir zincirin çok sayıda ara adıma bağımlı olması geri dönüşü uzatabilir. Kopyaların ne zaman oluşturulduğu, ne kadar süre tutulduğu ve hangi koşulda silindiği açık bir yaşam döngüsüne bağlanmalıdır.

4. Yedek kapsamını veritabanının ötesine taşıyın

Bir sistem yalnızca satır ve tablolardan oluşmaz. Kullanıcıların yüklediği dosyalar, uygulama sürümü, veri tabanı şeması, altyapı tanımları, alan adı ve yönlendirme ayarları, kuyruklar, zamanlanmış işler ve gerekli anahtarların yeniden oluşturulma yöntemi kurtarma planına dâhil edilmelidir. Yedeklemenin dışında bırakılan tek bir kritik bileşen, verinin tutarlı bir noktada geri yüklenmesini engelleyebilir.

Bununla birlikte gizli anahtarları ve parolaları sıradan bir belgeye kopyalamak güvenli bir çözüm değildir. Hangi gizli bilginin nerede yönetildiği, gerektiğinde kim tarafından nasıl yeniden üretileceği veya güvenli kasadan alınacağı belgelenmelidir. Uygulama sürümüyle veri şemasının uyumu da korunmalıdır. Eski bir yedeğin yalnızca en yeni uygulama sürümüyle açılacağı varsayılmamalı; gerekli geçiş adımları ve uyumlu sürümler kurtarma çalışmasında belirtilmelidir.

5. Yedekleri de üretim verisi kadar sıkı koruyun

Yedek kopya, çoğu zaman üretimdeki hassas bilgilerin tamamını içerir. Bu nedenle daha düşük güvenlikli bir yan depo gibi ele alınmamalıdır. Aktarım ve saklama sırasında şifreleme, en az ayrıcalıkla erişim, güçlü kimlik doğrulama, erişim kayıtları ve düzenli yetki gözden geçirmesi planın temel parçalarıdır. Günlük işlemleri yapan hesabın bütün geçmiş yedekleri silebilmesi, tek bir hesap ele geçirilmesinde koruma katmanlarını etkisiz bırakabilir.

Saklama süresi de güvenlik ve iş ihtiyacıyla uyumlu olmalıdır. Gereksiz yere yıllarca tutulan kopyalar maliyeti ve veri maruziyetini artırabilir; çok erken silinen kopyalar ise geç fark edilen bozulma veya yanlışlığı kurtarılamaz hâle getirebilir. Kişisel ve ticari veriler için geçerli sözleşme, saklama ve silme yükümlülükleri yetkili kişilerce değerlendirilmelidir. Plan, normal silme talebiyle güvenlik veya iş sürekliliği için tutulan yedeklerin nasıl yönetileceğini açıkça tanımlamalıdır.

6. Başarılı görev bildirimini başarılı yedek sanmayın

Bir yedekleme işinin “tamamlandı” mesajı vermesi, kopyanın eksiksiz ve geri yüklenebilir olduğunu kanıtlamaz. Depolama kotası dolabilir, belirli tablolar dışarıda kalabilir, dosya kopyaları yarıda kesilebilir veya uzun süredir bozuk olan veri sorunsuz biçimde çoğaltılabilir. Otomasyon; görevin çalışıp çalışmadığını, son başarılı kopyanın yaşını, beklenen veri miktarını ve olağandışı değişimleri izlemelidir.

Uyarıların kime ulaşacağı ve ne kadar sürede ele alınacağı da belirlenmelidir. Kimsenin takip etmediği günlük e-posta, gerçek bir kontrol mekanizması değildir. Kopyaların bütünlük doğrulaması yapılmalı ve seçili veriler düzenli olarak ayrı bir ortama geri yüklenmelidir. İzleme, yalnızca hata olduğunda değil; yedek beklenen zamanda oluşmadığında veya kurtarma hedefini karşılamayacak kadar eskidiğinde de sinyal üretmelidir.

7. Kurtarma adımlarını kriz anından önce yazın

Veri kaybı sırasında ekip, aynı anda hem sorunun kaynağını araştırıp hem de doğru geri dönüş kararını vermeye çalışır. Önceden hazırlanmış kurtarma çalışma kitabı bu baskıyı azaltır. Olayı kimin yöneteceği, veri yazımının ne zaman durdurulacağı, hangi kopyanın seçileceği, yeni ortamın nasıl hazırlanacağı, dış paydaşlara kimin bilgi vereceği ve hizmetin hangi sırayla açılacağı açıkça yazılmalıdır.

Geri yükleme sonrasında teknik olarak açılan sistem hemen kullanıma sunulmamalıdır. Kayıt sayıları, örnek kullanıcı akışları, dosya erişimi, yetkiler, entegrasyonlar ve zamanlanmış işler doğrulanmalıdır. Kurtarma noktasından sonra oluşan işlemlerin nasıl tespit edileceği ve mümkünse nasıl yeniden işleneceği de planlanmalıdır. Her adımın sahibi, gerekli erişimi ve yaklaşık süresi bilindiğinde toplam kurtarma hedefi daha gerçekçi biçimde değerlendirilebilir.

8. Düzenli tatbikatla planın gerçekten çalıştığını kanıtlayın

Kurtarma ilk kez gerçek kesintide denenmemelidir. Tatbikatlar, üretimi riske atmayan ayrı bir ortamda ve önceden tanımlanmış senaryoyla yapılabilir. Yanlışlıkla silinen tek bir kayıt, bozulmuş dosya deposu, kullanılamayan veri tabanı veya erişilemeyen ana konum gibi farklı olaylar farklı kurtarma adımları gerektirir. Tatbikatta geçen süre, karşılaşılan eksikler ve manuel bağımlılıklar kaydedilmelidir.

Test sonucunda hedef karşılanmıyorsa yalnızca daha hızlı bir araç aramak yerine bütün süreci inceleyin. Eksik erişim, güncel olmayan belge, bulunamayan şifre, yavaş veri aktarımı veya belirsiz karar yetkisi teknik çözüm kadar gecikme yaratabilir. Her önemli sistem değişikliğinde yedek kapsamı güncellenmeli; gerçek olay ve tatbikat öğrenmeleri çalışma kitabına eklenmelidir. Böylece yedekleme sessizce çalışan bir görev olmaktan çıkar, ölçülen ve geliştirilen bir iş sürekliliği yeteneğine dönüşür.