Yazılım yedekleme stratejisi, günlük bir dosya oluştuğunu görmekten ibaret değildir. Hangi verinin ne kadar kaybının kabul edilebileceğini ve sistemin ne kadar sürede geri döneceğini kanıtlar.
Önce veri envanteri
Veritabanı, yüklenen dosyalar, yapılandırma, gizli anahtarlar, uygulama sürümü ve dış sistemde tutulan kritik kayıtlar ayrı listelenir. Yalnızca veritabanını yedeklemek, kullanıcı belgeleri dosya sistemindeyse eksik kurtarma üretir.
İki hedef
- RPO: En fazla ne kadar yeni veri kaybı kabul edilebilir?
- RTO: Hizmet ne kadar sürede geri dönmelidir?
Bu hedefler yedek sıklığını, kopya sayısını ve kurtarma mimarisini belirler. Her sistem için aynı değer ekonomik olmayabilir.
Kopyaları ayırın ve koruyun
Yedekler üretim sistemiyle aynı disk veya aynı kimlik bilgisine bağımlı kalmamalıdır. Ayrı ortam, değiştirilemez kopya, şifreleme ve erişim sınırı fidye yazılımı ve kullanıcı hatasına karşı dayanıklılığı artırır. Şifreleme anahtarının kurtarma planı ayrıca saklanır.
Saklama ve bütünlük
Günlük, haftalık ve aylık saklama katmanları iş ihtiyacına göre belirlenir. Başarılı iş mesajı yerine dosya boyutu, bütünlük ve aktarım sonucu izlenir. Sessizce boş veya bozuk yedek oluşması alarm üretmelidir.
Geri yükleme provası
İzole ortamda veritabanı ve dosyalar birlikte geri alınır; uygulama açılır, kritik kayıt okunur ve süre ölçülür. Bakımlı yazılım altyapısı için veri hacmi ve süre hedeflerinizi paylaşabilirsiniz.
Yedek değişiklik kontrolü
Yeni dosya alanı, veritabanı, şifreleme anahtarı veya dış servis eklendiğinde yedek kapsamı otomatik güncellenmeyebilir. Mimari değişikliklerin teslim kriterine yedek ve kurtarma etkisini ekleyin. Yedek görevinin sahibi ayrıldığında erişim ve bildirimleri devredin. Geri dönüş provasında yalnızca yöneticinin değil, iş kullanıcısının seçilen kayıt ve belgeyi açması sağlansın. Teknik olarak tamamlanan kurtarma iş açısından eksik kalabilir.