Web Sitesi Yedeği Gerçekten Çalışıyor mu? Geri Yükleme Testi Rehberi

Bir web sitesi yedeğinin var olması, sitenin gerektiğinde geri döndürülebileceğini tek başına göstermez. Kullanılabilir bir yedek; doğru dosyaları, veri tabanını, yüklenen görselleri ve proje yapılandırmalarını içermeli, yetkili ekip tarafından erişilebilmeli, ayrı bir ortamda geri yüklenebilmeli ve kritik işlevlerin çalıştığı kontrol edilmelidir.

Bu nedenle bakım teklifindeki “yedekleme yapılır” maddesini yalnızca yedek dosyasının oluşturulmasıyla değerlendirmeyin. Şu sorunun da yazılı yanıtını isteyin: Bu yedek en son ne zaman geri yüklendi ve sonuç nasıl doğrulandı?

Bu rehber, teknik ayrıntılara hâkim olmayan bir proje sorumlusunun bile yedekleme kapsamını değerlendirebilmesi, geri yükleme testini planlayabilmesi ve sonucu kayıt altına alabilmesi için hazırlanmıştır.

Yedek Almak ile Geri Yükleyebilmek Aynı Şey Değildir

Yedek almak, belirli bir andaki verilerin ve sistem bileşenlerinin kopyasını oluşturmaktır. Geri yükleme ise bu kopyadan çalışır bir sistem üretme sürecidir. İki işlem birbirine bağlıdır; fakat aynı başarı ölçütüne sahip değildir.

Bir yedekleme işlemi panelde “başarılı” görünebilir, ancak şu sorunlardan biri bulunabilir:

• Veri tabanı dışa aktarımı eksik veya bozuk olabilir.
• Site dosyaları alınırken sonradan yüklenen görseller kapsam dışında kalmış olabilir.
• Projenin çalışması için gereken yapılandırma bilgileri eksik olabilir.
• Yedek dosyasına erişim yetkisi yalnızca artık kullanılmayan bir hesapta kalmış olabilir.
• Yedek, mevcut sunucu veya yazılım sürümüyle uyumsuz olabilir.
• Dosyalar geri gelse bile formlar, kullanıcı işlemleri veya entegrasyonlar çalışmayabilir.

NIST’in SP 1339 yedekleme rehberi, etkili yedek yönetimini yalnızca kopya oluşturmakla sınırlamaz; yedeklerin test edilmesini ve kurtarma çalışmaları sırasında gözden geçirilmesini de sürecin parçası olarak ele alır. Rehber operasyonel teknoloji ortamlarına yönelik olsa da burada kullanılan temel ayrım web projeleri için de yararlıdır: yedeğin varlığı ile kurtarma hazırlığının doğrulanması farklı kontrollerdir.

Önce Yedek Kapsamını Yazılı Hâle Getirin

“Web sitesi yedekleniyor” ifadesi hangi varlıkların kopyalandığını açıklamaz. Sadece görünen sayfaları oluşturan dosyalar değil, sitenin içerik ve işlevlerini taşıyan diğer bileşenler de değerlendirilmelidir.

Kumsal Ajans projelerinde kapsam doğrultusunda şu varlıklar yedeklenir:

• site dosyaları;
• veri tabanı;
• yüklenen görseller ve diğer medya;
• proje yapılandırmaları.

Her projede aynı teknik yapı bulunmayabilir. Statik bir kurumsal site ile üyelik, özel kullanıcı rolleri, form kayıtları veya üçüncü taraf entegrasyonlar içeren bir web yazılımının kurtarma gereksinimleri aynı değildir. Bu nedenle yedek envanterinde yalnızca “dosya” ve “veri tabanı” kutularını işaretlemek yerine, sitenin çalışması için zorunlu varlıkların proje özelinde listelenmesi gerekir.

Şu soruları cevaplayın:

1. İçerikler ve kullanıcı kayıtları hangi veri tabanında bulunuyor?
2. Sonradan yüklenen görseller ve belgeler hangi dizinde veya depolama hizmetinde tutuluyor?
3. Projenin çalışması için gereken yapılandırmalar nasıl korunuyor?
4. Harici servislerin erişim bilgileri yedeğin parçası mı, yoksa ayrı ve güvenli bir devir sürecine mi tabi?
5. Kaynak kodun güncel sürümü hangi depoda tutuluyor?

Parolaları veya gizli anahtarları açık bir kontrol formuna yazmayın. Formda bu erişimin sahibi, saklandığı güvenli kanal ve yetkili kişi belirtilmelidir.

Yedeğin Konumu ve Erişim Sorumlusu Belli Olmalı

Bir yedek mevcut olsa bile ihtiyaç anında kimse ona erişemiyorsa kurtarma süreci başlayamaz. Yedeğin nerede tutulduğu, hangi hesapla yönetildiği ve hizmet ilişkisi değiştiğinde erişimin nasıl devredileceği bakım kapsamının parçası olmalıdır.

Kumsal Ajans uygulamasında yedekler güvenli sunucu veya harici depolama alanlarında tutulur ve yalnızca yetkili teknik ekip erişebilir. Bunun proje belgesindeki karşılığı şu alanlarla açıklanmalıdır:

• depolama sorumlusu;
• erişim yetkilisi veya rolü;
• müşteri, ajans ve hosting sağlayıcısı arasındaki sorumluluk ayrımı;
• erişim değişikliğinde uygulanacak devir yöntemi;
• yedeğin silinmesi veya erişilememesi durumunda bildirim süreci.

“Hosting firması yedekliyor” ifadesi de tek başına yeterli değildir. Sağlayıcının hangi varlıkları, hangi koşullarda ve ne kadar süre tuttuğu sözleşmeden veya hizmet panelinden doğrulanmalıdır. Ajansın kendi bakım yedeği ile hosting sağlayıcısının altyapı yedeği aynı kapsamı ve aynı sorumluluğu taşımayabilir.

Sıklık ve Saklama Süresini Projenin Değişim Hızına Göre Belirleyin

Her web sitesi için geçerli tek bir yedekleme sıklığı veya saklama süresi yoktur. Günde çok sayıda sipariş, kullanıcı kaydı ya da içerik değişikliği oluşan bir sistem ile nadiren güncellenen kurumsal tanıtım sitesinin veri kaybı etkisi farklıdır.

Kumsal Ajans’ta sıklık ve saklama süresi, projenin güncellenme sıklığına ve risk seviyesine göre belirlenir. Karar verirken şu noktalar değerlendirilmelidir:

• Yeni veri ne sıklıkta oluşuyor?
• En son yedekten sonraki kayıtların kaybı işletmeyi nasıl etkiler?
• Hangi değişikliklerden önce ek yedek gerekir?
• Yedek dosyalarının boyutu ve depolama maliyeti nedir?
• Eski bir yedeğin saklanmasını gerektiren operasyonel veya sözleşmesel ihtiyaç var mı?
• Üçüncü taraf hizmetlerin kendi yedekleme ve dışa aktarma sınırları nelerdir?

Bu soruların yanıtı proje teklifinde veya bakım planında tanımlanmalıdır. “Günlük yedek her zaman yeterlidir” ya da “uzun süre saklamak her zaman daha güvenlidir” gibi genellemeler yerine, kabul edilebilir veri kaybı ve kurtarma ihtiyacı proje sahibiyle birlikte değerlendirilmelidir.

Geri Yükleme Testini Mümkün Olduğunda Ayrı Ortamda Yapın

Çalışan bir canlı sitenin üzerine deneme amacıyla yedek yüklemek yeni veri kaybına veya hizmet kesintisine yol açabilir. Bu nedenle Kumsal Ajans geri yükleme testini mümkün olduğunda ayrı bir test ortamında gerçekleştirir.

Ayrı ortam şu faydaları sağlar:

• Canlı veriyi değiştirmeden yedek açılabilir.
• Eksik dosya veya veri tabanı hataları ziyaretçileri etkilemeden incelenebilir.
• Formlar ve entegrasyonlar gerçek müşterilere bildirim göndermeyecek şekilde sınanabilir.
• Yazılım ve sunucu uyumluluğu canlıya müdahale etmeden görülebilir.
• Geri yükleme adımları ve karşılaşılan eksikler kayıt altına alınabilir.

Test ortamı herkese açık bırakılmamalı; yetkisiz erişim ve arama motoru indekslemesi engellenmelidir. Form ve entegrasyon kontrollerinde gerçek müşteri verisi yerine tanımlı test verileri kullanılmalıdır.

Geri yükleme, planlanan önemli bir değişiklikten önceki güvenli yayın süreciyle de ilişkilidir. Hangi işlemin ayrı ortamda denenmesi gerektiği; değişikliğin veri, kullanıcı işlemleri, entegrasyonlar ve canlı hizmet üzerindeki etkisine göre belirlenmelidir.

Geri Yükleme Testini Yedi Adımda Uygulayın

1. Test amacını ve kapsamını belirleyin

Tam site kurtarma mı, yalnızca veri tabanı geri dönüşü mü, yoksa belirli dosyaların doğrulanması mı test ediliyor? Kullanılacak yedeğin tarihi ve seçilme nedeni kaydedilmelidir.

2. Yedeğe erişimi doğrulayın

Yetkili teknik ekip yedek dosyasını gerçekten indirebiliyor veya geri yükleme sürecinde kullanabiliyor mu? Dosyanın varlığı, boyutu ve beklenen bileşenleri kontrol edilmelidir.

3. Test ortamını hazırlayın

Canlı ortamdan ayrılmış, erişimi sınırlandırılmış ve arama motorlarına kapalı bir ortam oluşturun. Harici servislerin gerçek bildirim veya işlem üretmesini engelleyin.

4. Dosyaları, veri tabanını ve yapılandırmaları geri yükleyin

İşlem sırası projeye göre değişebilir. Teknik ekip uyguladığı adımları ve karşılaştığı hataları bakım kaydına eklemelidir. Eksik bir bileşen görülürse yalnızca hatayı düzeltmek değil, yedekleme kapsamını da güncellemek gerekir.

5. Kritik işlevleri kontrol edin

Kumsal Ajans süreçlerinde geri yükleme sonrasında şu alanlar proje kapsamına göre kontrol edilir:

• sayfaların açılması ve doğru içeriği göstermesi;
• markaya özel yönetim paneline yetkili erişim;
• görsellerin ve belgelerin yüklenmesi;
• formların gönderimi ve kayıt/bildirim akışı;
• kullanıcı girişi ve diğer kullanıcı işlemleri;
• üçüncü taraf entegrasyonlar;
• veri bütünlüğü;
• çok dilli projelerde ilgili dil içerikleri ve geçişler.

Yalnızca ana sayfanın açılması başarılı geri yükleme için yeterli kabul edilmemelidir. Projenin ticari veya operasyonel açıdan kritik kullanıcı görevleri de çalıştırılmalıdır.

6. Teknik sonuç ile iş kabulünü ayırın

Testi teknik ekip uygular. Proje sorumlusu ise belirlenen kontrolleri inceleyerek sonucu onaylar. Teknik ekibin “işlem tamamlandı” demesi ile proje sahibinin kritik işlevlerin kabul ölçütlerini karşıladığını doğrulaması iki ayrı kayıttır.

7. Sonucu ve sonraki işlemi kaydedin

Başarılı, kısmen başarılı veya başarısız sonucu açıkça yazın. Eksik varlık, hata mesajı, çalışmayan işlev, yapılan düzeltme ve yeniden test tarihi kayda eklenmelidir. Test başarısızsa bu durum yedeği sessizce “başarılı” kabul etmek yerine yedekleme planının iyileştirilmesi için kullanılmalıdır.

CISA #StopRansomware rehberi, kritik veri yedeklerinin erişilebilirlik ve bütünlüğünün kurtarma senaryosunda düzenli olarak test edilmesini önerir. Bu öneri her projeye aynı takvimi dayatmaz; sıklığın risk, değişim hızı ve kaynaklara göre tanımlanması gerekir.

Doldurulabilir Geri Yükleme Test Tutanağı

Bu forma parola, gizli anahtar veya kişisel veri yazmayın. Yalnızca erişimin hangi güvenli kanalda ve hangi yetkili rolde bulunduğunu kaydedin.

Anonimleştirilmiş Gerçek Geri Yükleme Örneği

Bir projede yapılan hatalı güncellemenin ardından bazı içerikler erişilemez hâle geldi. Doğrudan canlı sistem üzerinde farklı yedekleri denemek yerine son sağlam olduğu düşünülen yedek ayrı test ortamına alındı.

Teknik ekip dosyaları, veri tabanını, görselleri ve proje yapılandırmalarını geri yükledi. Ardından sayfalar, yönetim işlevleri ve veri bütünlüğü kontrol edildi. Yedeğin kullanılabilir olduğu doğrulandıktan sonra canlı sisteme geri dönüş uygulandı ve kritik işlevler yeniden test edildi.

Bu örnek belirli bir kurtarma süresi, kesintisiz çalışma veya sıfır veri kaybı garantisi sunmaz. Gösterdiği nokta şudur: doğru yedeği seçmek ve ayrı ortamda doğrulamak, canlı sisteme geri dönüş kararını daha kontrollü hâle getirir.

Bakım Teklifindeki Yedekleme Maddesine Sorulacak Sorular

Bir bakım teklifini incelerken aşağıdaki soruların açık yanıtlarını arayın:

1. Hangi dosya, veri ve yapılandırmalar yedekleniyor?
2. Yedekler nerede tutuluyor ve kim erişebiliyor?
3. Sıklık ve saklama süresi hangi proje riskine göre belirleniyor?
4. Önemli güncellemelerden önce ek yedek alınıyor mu?
5. Geri yükleme testi ayrı ortamda yapılabiliyor mu?
6. Testi kim uyguluyor ve kim onaylıyor?
7. Başarılı sayılması için hangi kullanıcı görevleri çalıştırılıyor?
8. Test sonucu, eksikler ve düzeltmeler nerede kaydediliyor?
9. Hosting sağlayıcısının yedeği ile bakım hizmetindeki yedek aynı mı?
10. Hizmet veya sağlayıcı değiştiğinde yedek ve erişimler nasıl devrediliyor?

Bu soruların yanıtları bakım hizmetinin kapsamına göre değişebilir. Esas olan, belirsiz “yedekleme dahil” ifadesini varlık, sorumluluk, sıklık, test ve kabul alanlarına ayırmaktır. Ücretsiz hata desteği, yıllık bakım ve yeni geliştirme sınırlarını değerlendirmek için web sitesi bakım ve destek rehberini da inceleyebilirsiniz.

Sonuç: Yedeği Dosyayla Değil, Çalışan Geri Dönüşle Değerlendirin

Güvenilir bir web sitesi yedekleme süreci dört soruya cevap verir: Ne yedekleniyor, nerede ve kimin sorumluluğunda tutuluyor, nasıl geri yükleniyor ve başarılı sonuç nasıl onaylanıyor?

Yedek kapsamını proje varlıklarıyla eşleştirin. Sıklık ve saklama süresini değişim hızı ile risk seviyesine göre belirleyin. Mümkün olduğunda ayrı test ortamında geri yükleme yapın. Sayfaların yanında yönetim paneli, formlar, kullanıcı işlemleri, entegrasyonlar, görseller ve veri bütünlüğünü kontrol edin. Teknik uygulama ile proje kabulünü ayrı kaydedin.

Bu yaklaşım, yedeklemeyi arka planda çalıştığı varsayılan bir işlem olmaktan çıkarır; ihtiyaç anında uygulanabilecek, sorumlusu ve sonucu belli bir kurtarma sürecine dönüştürür. Kumsal Ajans ile projenize özel bakım, yedekleme ve geri dönüş kapsamını planlamak için hizmet detaylarını proje ihtiyaçlarınıza göre birlikte belirleyebilirsiniz.