Veeam Yedekleme Sistemi Kurulumu ve Kurtarma Testi

Bu projeyi Sistem Kuşu kurulmadan önce, kurumun BT ekibinde çalıştığım dönemde ben yürüttüm.

Bir felaket anında kurumun elinde geri dönecek tek bir güvenilir nokta yoktu; yedekleme yazılımı da işletim sistemi de yıllardır güncellenmemişti. Yedekleme altyapısını, sunucu işletim sistemi yükseltmesiyle birlikte sıfırdan kurduk.

Sorun

Kurumun VMware altyapısında sistematik bir yedekleme çözümü yoktu. Yedekleme için ayrılan sunucu eski bir Windows Server 2016 üzerinde çalışıyordu ve üzerindeki yedekleme yazılımı da yıllardır güncellenmemişti. Sunucuların hiçbiri düzenli ve test edilmiş bir yedeğe sahip değildi.

Bu tablonun en sessiz tarafı şu: yedekleme kurulu olmayan bir ortam, arıza çıkana kadar yedekleme kurulu bir ortamdan farksız görünür. Eksik, ancak ihtiyaç duyulduğu gün fark edilir ve o gün geç kalınmış olur.

Neden bu yol?

Yedekleme yazılımını mevcut sunucunun üzerine kurup devam etmek daha hızlı olurdu. Bu yolu seçmedik: geri dönüşün dayandığı katmanın, kurtarmaya çalıştığı sistemlerden daha eski olmaması gerekir. Yıllardır güncellenmemiş bir işletim sistemi, yedeklemenin kendisini ikinci bir risk kalemine çevirir.

Bu yüzden sıralamayı tersine kurduk: önce sunucuyu Windows Server 2022’ye yükselttik, yedekleme yazılımını temiz bir sistem üzerine sıfırdan kurduk. Maliyeti birkaç saatlik ek iş oldu; karşılığında yedekleme altyapısı, koruduğu ortamdan daha yeni bir temele oturdu.

Nasıl kurduk?

Sunucu yükseltmesinin ardından Veeam Backup & Replication’ı sıfırdan kurup sanallaştırma altyapısındaki sunucuların tamamını kapsama aldık. Yedekleme planı iki ritimde çalışacak şekilde yapılandırıldı: hafta içi her gün mesai saatinden sonra artımlı (incremental), hafta sonu tam (full) yedek.

Kurulumun kendisi 1-2 saat sürdü. Asıl emek, hangi verinin ne sıklıkla ve ne kadar süre saklanacağının kararlaştırılmasındaydı; bu karar bir yazılım ayarı değil, kurumun hangi veriyi ne kadar süre kaybetmeyi göze aldığının cevabıdır.

Son adım geri yükleme testiydi: yapılandırma bittikten sonra yedeklerden fiilen geri dönüş yapılarak sistemin çalıştığı doğrulandı.

Devreye alındıktan sonra

Kurum, sunucu veya sanal makine seviyesinde bir sorun yaşandığında geri dönebileceği bir noktaya sahip oldu; günlük artımlı yedekleme sayesinde en kötü senaryoda kaybedilecek veri bir günlük.

Bu yedekleme standardı kurumun kendi dokümantasyonuna da işlendi, yani hangi sunucunun hangi sıklıkla yedeklendiği tek bir kişinin hafızasında kalmadı: dokümantasyon sunucusu projesi o çalışmayı anlatıyor.

Bu projede uyguladığımız mimarinin arkasındaki yöntemi, 3-2-1-1-0 kuralını ve kurtarma süresi hedeflerinin nasıl belirlendiğini kurumsal veri yedekleme ve felaket kurtarma rehberimizde anlatıyoruz.