Bakım penceresi, yedek geri yükleme testi ve izleme nasıl birlikte planlanır?

Bakım, yedek ve güncelleme için ayrı bir operasyon planı neden gerekir?​

Bir site ya da sunucuda en sık yapılan hata, yedek almakla yedekten dönebilmeyi aynı şey sanmaktır. Oysa yedek, yalnızca veri kopyasıdır; asıl güvence, bu kopyanın gerçekten geri yüklenebilmesi ve geri yüklemenin kabul edilebilir sürede tamamlanabilmesidir. Resmî dokümantasyon da düzenli geri yükleme testi yapmayı, yedeklerin tutarlılığını doğrulamayı ve bu işlemin RTO/RPO hedeflerine uyduğunu kontrol etmeyi önerir. Bu yüzden operasyon planı; yedekleme, geri yükleme, izleme ve bakım penceresini birlikte düşünmelidir.

İşletim planında hangi parçalar birlikte ele alınmalı?​

En pratik yaklaşım, işi dört ayrı başlıkta düzenlemektir:

• Yedekleme: Ne yedeklenecek, ne kadar süre saklanacak, nerede tutulacak?
• Geri yükleme: Test ortamında hangi sıklıkla denenecek, hangi sırayla geri dönülecek?
• Bakım: Güncellemeler ve servis çalışmaları hangi zaman aralığında uygulanacak?
• İzleme: CPU, bellek, disk, HTTP istekleri ve servis sağlığı nasıl takip edilecek?

Bu ayrım önemlidir; çünkü bakım sırasında alınan bir karar, yedekleme penceresini bozabilir, izleme eksikliği de arızayı geç fark etmenize yol açabilir. IIS tarafında web sunucusu, web sitesi ve application pool için sağlık ve performans verileri izlenebilir; bu da hangi katmanda sorun olduğunu ayırmayı kolaylaştırır.

Bakım penceresi nasıl planlanmalı?​

Bakım penceresi, “boş bir zaman” değil, kontrollü değişiklik zamanı olarak düşünülmelidir. Güncellemeleri herkesin aktif olduğu saatlerde uygulamak yerine, belirli bir bakım aralığı belirlemek kesintiyi azaltır ve müdahale etmeyi kolaylaştırır. Microsoft’un bakım penceresi yaklaşımı, güncellemelerin belirlenen zaman aralığında teslim edilmesini ve bu sırada hizmet etkisinin sınırlanmasını amaçlar; benzer şekilde patch yönetim dokümanları da bakım zamanını planlamayı ve güncellemeleri düzenli şekilde uygulamayı önerir.

Bakım penceresi tanımlarken şu sorular net olmalıdır:

• Hangi servisler bu sırada kapalı kalabilir?
• Yama uygulandıktan sonra ilk kontrol adımı ne olacak?
• Sorun çıkarsa geri dönüş planı ne?
• Bakım sırasında izleme kim tarafından yapılacak?

Yaygın hata, bakım penceresini sadece uygulama güncellemesi için ayırıp veri tabanı, cache, DNS veya bağımlı servisleri plan dışı bırakmaktır. Böyle durumlarda bakım biter ama hizmet tam açılmaz.

Yedek stratejisinde nelere dikkat edilmeli?​

İyi bir yedek stratejisi sadece “kaç kopya var” sorusunu değil, “hangi kopya işe yarar” sorusunu da cevaplar. Yedeklerin düzenli aralıklarla kontrol edilmesi, mümkünse test ortamında geri yüklenmesi ve önemli değişikliklerden sonra yeni bir geri yükleme denemesi yapılması gerekir. SQL Server dokümantasyonu da yedekleri güvenli, mümkünse ayrı bir konumda tutmayı ve test geri yüklemeleri yapmayı vurgular.

Pratikte şu kurallar faydalıdır:

• Yedek dosyasını sadece oluşturmakla yetinmeyin, açılabildiğini ve geri döndürülebildiğini test edin.
• Yedeğin saklama süresini veri türüne göre belirleyin; her veri aynı süre tutulmaz.
• En az bir kopyayı ana sunucudan ayrı ve güvenli bir yerde tutun.
• Konfigürasyon değişikliklerini de yedek kapsamına alın; sorun sadece veritabanında olmaz.

Buradaki temel amaç, felaket anında “yedek var mı?” sorusundan “geri dönüş ne kadar sürer?” sorusuna geçebilmektir. Bu yaklaşım, operasyonel riskin daha gerçekçi yönetilmesini sağlar.

İzleme olmadan bakım ve yedek neden eksik kalır?​

İzleme, sorun çıktığında bakmak için değil, sorun çıkmadan önce sinyal yakalamak içindir. Sunucu yükü artmışsa, disk alanı daralmışsa veya uygulama pool’u beklenmedik şekilde yeniden başlıyorsa, bunlar yedekleme ya da bakım planını doğrudan etkileyebilir. Windows Server tarafında Server Manager, performans sayaçları ve olay verileri gösterebilir; IIS tarafında ise web sunucusu, siteler ve application pool’ların sağlık verileri izlenebilir.

İzleme kurulurken özellikle şu metrikler faydalıdır:

• CPU ve bellek kullanımı
• Disk doluluk oranı ve disk gecikmesi
• HTTP hata oranı ve yanıt süresi
• Servis durumu ve yeniden başlama sayısı
• Yedekleme işlerinin başarı/başarısızlık durumu

Bu metrikler birlikte okunmadığında yanlış kararlar çıkabilir. Örneğin disk doluluğu düşük görünse bile log dosyaları hızlı büyüyorsa kısa sürede aynı probleme geri dönülebilir.

Kısa uygulama kontrol listesi​

Bir yönetim planını sade tutmak istiyorsanız şu sırayı kullanabilirsiniz:

• Yedek alınacak sistemleri listeleyin.
• Her sistem için geri yükleme senaryosu yazın.
• Bakım penceresini belirleyin ve değişiklikleri oraya bağlayın.
• İzleme uyarılarını kurun.
• Periyodik test geri yüklemesi yapın.
• Bakım sonrası hizmet doğrulaması yapın.

Bu yaklaşım, tek tek araçlardan çok operasyon akışını düzenler. Araçlar değişebilir; fakat geri yükleme testi, planlı bakım ve ölçülebilir izleme ihtiyacı genelde değişmez.