Yedek almak yetmez: geri dönüşü planlamak

Önce geri getirilmesi gerekenleri belirleyin

Veritabanı çoğu uygulamanın önemli parçasıdır, ancak tek parçası değildir. Yüklenen belgeler, ürün görselleri, uygulama sürümü ve çalışmak için gerekli yapılandırmalar da kurtarma kapsamına girebilir. Birbiriyle ilişkili dosyaların hangi tarihteki veritabanıyla birlikte kullanılacağı açıklanmalıdır. Aksi halde kayıt görünürken ona bağlı belge bulunamayabilir.

Bir envanter hazırlayarak her öğenin sorumlusunu ve geri yükleme önceliğini yazın. Dış hizmetlerde tutulan veriler için dışa aktarma olanaklarını inceleyin. Erişim anahtarlarının kurtarma sırasında nasıl sağlanacağını da planlayın; bu bilgileri sıradan bir yedek açıklamasına açık biçimde koymak doğru değildir.

Veri kaybı ve kesinti için iş hedefi koyun

Son yedekten sonra girilen işlemlerin kaybı işletme tarafından nasıl tamamlanabilir? Bir satış kaydı e-postadan yeniden oluşturulabilirken gün boyunca yapılan yüzlerce stok hareketini elle toplamak zor olabilir. Bu nedenle yedekleme sıklığı, takvim alışkanlığından çok işin veri üretme biçimine göre belirlenmelidir.

NIST'in bilgi sistemleri süreklilik rehberi, kurtarma gereksinimlerinin ve önceliklerinin iş etkisi değerlendirmesiyle ele alınmasını önerir. Uygulamada bunun karşılığı, hangi sürecin ne kadar durabileceğini önceden konuşmaktır. Kabul edilebilir hedefleri yazılı hale getirin; altyapı ve operasyon ekibinin bu hedefi gerçekten karşılayıp karşılayamadığını testle değerlendirin.

Kopyaları aynı soruna maruz bırakmayın

Uygulama dosyalarının yanında duran bir yedek, sunucu diskindeki bazı hatalara karşı yetersiz kalabilir. Aynı hesapla erişilen tüm kopyalar, hesap sorunu yaşandığında birlikte erişilemez olabilir. Yedeklerin nerede tutulduğu kadar kimlerin bunları değiştirebildiği ve silebildiği de önemlidir.

Kopyaların ayrı konumlarda saklanması, erişimlerin ayrılması ve eski sürümlere dönüş imkânı ihtiyaç doğrultusunda değerlendirilmelidir. Saklama süresini belirlerken maliyetin yanında verinin iş değeri ve hassasiyeti de düşünülmelidir. Veri güvenliği planı ile yedek politikasının tutarlı olması, unutulmuş kopyaların kontrol dışında kalmasını önler.

Geri yüklemeyi gerçek bir denemeye dönüştürün

Başarılı yedekleme bildirimi alınması, kurtarmanın başarıyla tamamlanacağını kanıtlamaz. Ayrı ve güvenli bir deneme ortamında yedeği açın. Uygulamanın başlaması, örnek kayıtların görünmesi ve ilişkili dosyaların erişilebilir olması kontrol edilmelidir. İş açısından kritik birkaç işlemi de deneyerek teknik açılış ile kullanılabilirlik arasındaki farkı görün.

Deneme sırasında geçen süreyi ve karşılaşılan eksikleri kaydedin. Eksik bir sunucu ayarı, unutulmuş dosya dizini veya ulaşılamayan erişim bilgisi bu aşamada ortaya çıkabilir. Bakım ve destek planına bu denemelerin tekrarını ekleyin; büyük uygulama değişikliklerinden sonra kapsamın yeniden değerlendirilmesi gerekir.

Bir geri yükleme denemesi için kısa bir kabul listesi hazırlayabilirsiniz: seçilen tarih aralığındaki kayıtlar açılıyor mu, ilişkilendirilmiş belgeler bulunuyor mu ve kullanıcı yetkileri beklenen şekilde çalışıyor mu? Deneme ortamının yanlışlıkla gerçek müşterilere mesaj göndermesini önleyin. İşlemi yapan kişiyle sonucu kontrol eden iş sorumlusunun birlikte değerlendirme yapması, teknik olarak başarılı görünen fakat işletme açısından eksik kalan bir dönüşü yakalamayı kolaylaştırır. Sonucu ve kullanılan yedeği kayıt altına alın.

Kesinti anı için kısa bir çalışma sırası yazın

Sorun yaşandığında aynı anda birçok kişi çözüm üretmeye çalışabilir. Hangi kişinin durumu değerlendireceği, kimlerin bilgilendirileceği ve geri yüklemeye kimin karar vereceği önceden belirlenirse belirsizlik azalır. İlk amaç, mevcut durumu koruyarak sorunun kapsamını anlamak olmalıdır; aceleyle yapılan değişiklikler kurtarma seçeneklerini daraltabilir.

Plan, aşırı uzun bir teknik belge olmak zorunda değildir. İrtibat kişilerinin, erişim yöntemlerinin, geri dönüş sırasının ve kontrol adımlarının bulunduğu anlaşılır bir doküman başlangıç için değerlidir. Müşterilere yapılacak bilgilendirmenin sorumlusu da tanımlanmalıdır. Teknik çalışma ile kullanıcı iletişimi aynı kişinin dikkatini bölmemelidir.

Kurtarma sonrası kayıtları karşılaştırın

Sistem yeniden açıldığında çalışma tamamlanmış sayılmaz. Son yedek ile kesinti arasındaki işlemler belirlenmeli, dış hizmetlerde oluşmuş kayıtlarla karşılaştırma yapılmalıdır. Ödeme, sipariş ve bildirim gibi bağlantılı işlemler tekrarlandığında mükerrer kayıt oluşmaması özellikle önemlidir. Hangi kaydın eksik olduğu anlaşılmadan toplu yeniden gönderim yapılmamalıdır.

Yaşanan olayı kısa bir değerlendirmeye dönüştürün: ne oldu, nasıl fark edildi, ne işe yaradı ve hangi adım iyileştirilecek? Böylece yedekleme, unutulan bir kurulum ayarı olmaktan çıkar. Bulut tabanlı yazılım kullanılsa bile hizmet sağlayıcıyla işletme arasındaki sorumluluk paylaşımı bu değerlendirmeye dâhil edilmelidir.