Web sitesi yedekleme ve geri yükleme planı
Dosya, veritabanı ve yapılandırma yedeklerini planlayın. RPO, RTO ve örnek geri yükleme kontrol listesiyle kurtarma sürecini doğrulayın.
Yedekleme, dosya kopyasının oluşmasıyla tamamlanmaz. Veritabanı, yüklenen dosyalar ve gerekli yapılandırmaların birlikte geri getirilebildiği düzenli olarak sınanmalıdır.
Bu rehberde neler var?
Neyi kaybedebileceğinizi belirleyin
Bir içerik sitesinde birkaç saatlik yazı değişikliği ile sipariş alan bir uygulamadaki birkaç saatlik işlem kaybı aynı etkiye sahip değildir. Kabul edilebilir veri kaybını ve hizmetin ne kadar süre kapalı kalabileceğini iş sahibiyle belirleyin.
RPO, geri dönüşte kabul edilen veri kaybının zaman aralığını; RTO, hizmeti geri getirmek için hedeflenen süreyi anlatır. Örneğin “en fazla bir saatlik veri kaybı” hedefi varsa günde bir yedek almak bu hedefi tek başına karşılamaz. Bunlar planlama hedefleridir; gerçekleşen süreyi testte ölçün.
Yedek kapsamını yazın
- Uygulama dosyaları ve sürüm bilgisi.
- Veritabanı ve tutarlı bir geri yükleme yöntemi.
- Kullanıcıların yüklediği dosyalar.
- Sunucu ve uygulama yapılandırmasının gerekli kısımları.
- Zamanlanmış işler ile bağımlı hizmetlerin envanteri.
Gizli anahtarları ve parolaları açık arşivlerde tutmayın. Yedek erişimini sınırlandırın ve şifreli saklama yöntemini planlayın. Aynı sunucudaki tek kopya, sunucu veya disk kaybında yeterli olmayabilir.
Karar tablosu: durumunuzu değerlendirin
Dar ekranda tüm sütunları görmek için tabloyu yatay kaydırabilirsiniz.
| Durum | Nasıl yorumlanır? | Sonraki adım |
|---|---|---|
| Veri kaybı toleransı | Son kullanılabilir yedek ile olay anı arasında kaybedilebilecek işler önemlidir. | Yedek sıklığını işin ne kadar kaydı yeniden üretebildiğine göre belirleyin. |
| Kurtarma süresi | Hizmetin ne kadar süre kullanılamayacağı operasyonu etkiler. | İndirme, kurulum, geri yükleme ve doğrulamayı birlikte zamanlayın. |
| Yedek bağımsızlığı | Aynı erişim veya arıza alanı bütün kopyaları etkileyebilir. | Depolama ve erişim ayrımını değerlendirin; aynı diskteki ikinci klasörü ayrı koruma saymayın. |
Geri yüklemeyi ayrı ortamda deneyin
Test için üretimden ayrılmış bir ortam kullanın. Yedeği açın, veritabanını yükleyin, gerekli yapılandırmaları tamamlayın ve uygulamanın kritik akışlarını kontrol edin. Test ortamının gerçek müşterilere e-posta, bildirim veya ödeme isteği göndermesini engelleyin.
Yedek tarihini, işlemi yapan kişiyi, geçen süreyi ve eksik bulunan dosyaları kaydedin. Rastgele birkaç dosyanın açılması yerine form gönderimi, yönetim girişi ve örnek kayıt okuma gibi anlamlı kontroller seçin.
Saklama ve olay planını işletin
Günlük, haftalık ve daha eski geri dönüş noktalarının kaç gün saklanacağını belirleyin. Bir sorun hemen fark edilmeyebilir; yalnızca son kopyayı tutmak hatalı veriyi bütün yedeklere taşıyabilir. Yedek işinin başarısızlığı için bildirim kurun.
Olay anında kimin karar vereceği, hangi yedeğin seçileceği, geri yükleme sonrası hangi kontrollerin yapılacağı ve kullanıcıların nasıl bilgilendirileceği önceden yazılı olmalı. Sunucu teklifinde yedek hizmeti varsa bu işlerin hangisinin sağlayıcıya ait olduğunu ayrıca sorun.
Yedek dosyası var ama uygulama açılmıyor
AÇIKLAMALI ÖRNEK · TEMSİLÎ SENARYO
Bir ekip veritabanı yedeğini almış, fakat yüklenen dosyaları ve uygulamanın çalışması için gerekli yapılandırmayı kapsam dışında bırakmış olsun. Veritabanını geri yüklemek bazı kayıtları getirir; kullanıcı belgeleri eksik kalır ve servis bağlantıları çalışmayabilir. Tatbikat, yedeğin dosya olarak bulunmasından daha geniş bir kontrol gerektirir.
Ayrı bir ortamda uygulama kurulup temsilî birkaç işlem yürütülür: oturum açma, eski kaydı görüntüleme ve dosya indirme gibi. Kurtarma süresi ilk dosyayı kopyalamaktan değil, hizmetin kullanılabilir hale gelmesine kadar ölçülür. Eksikler kaydedilip yedek kapsamı güncellenir. Test ortamındaki hassas verilerin kimlerin erişimine açık olduğu da kontrol edilerek tatbikat tamamlanır.
Kurtarma tatbikatının sonuç tutanağı
Geri yükleme testinden sonra yalnızca “başarılı” yazmayın. Kullanılan yedeğin tarihi, geri getirilen uygulama sürümü, veri kapsamı ve gerçek geçen süre birlikte kaydedilsin. Yedeğin alınma zamanı ile kullanılabilir hizmetin geri geldiği zaman farklı bilgilerdir.
Örneğin dosyalar açıldığı hâlde veritabanındaki son kayıtlar eksik olabilir. Ya da uygulama açılır ama yüklenen görseller yanlış dizinde kaldığı için görünmez. Kabul listesine içerik okuma, dosya erişimi ve uygulamanıza uygun kritik bir iş akışı ekleyin.
- Yedek dosyası ve gerekli erişimler bulunabildi mi?
- Geri yüklemeyi dokümana bakarak başka bir kişi yapabildi mi?
- Veri kaybı ve süre, belirlenen hedef içinde kaldı mı?
- Eksikler için sorumlu ve düzeltme tarihi belirlendi mi?
Tatbikatın amacı yalnızca sistemi sınamak değil, olay anında gereken bilginin tek bir kişiye bağlı kalmasını da önlemektir.
Uygulama kontrolü ve dikkat edilecek nokta
KENDİ ÇALIŞMANIZA UYGULAYIN
- Veritabanı, kullanıcı dosyaları ve yapılandırma bağımlılıklarını yedek envanterine yazın.
- Bir yedeği gerçekten geri yükleyip kullanıcı açısından kritik işlemleri çalıştırın.
- Tatbikat sonunda yedek tarihi, eksikler, toplam süre ve düzeltme sahibini kaydedin.
Sık sorulan sorular
Snapshot ile yedek aynı şey mi?
Anlık görüntü yararlı olabilir; ancak aynı altyapıya bağımlılık ve tutarlılık koşulları değerlendirilmelidir. Tek başına bağımsız kurtarma planı yerine geçeceğini varsaymayın.
Geri yükleme testi ne sıklıkla yapılmalı?
Verinin önemi ve değişiklik sıklığına göre planlayın. Altyapı veya yedekleme yöntemi değiştiğinde testi yenileyin.
Yedekleme ile arşivleme aynı mı?
Amaçları farklı olabilir. Yedek hizmeti geri getirmeye, arşiv ise geçmiş veriyi belirli koşullarda korumaya odaklanır. Saklama, erişim ve geri çağırma gereksinimlerini ayrı tanımlayın; birini diğerinin otomatik karşılığı saymayın.
Bu rehber Takipci.gen.tr tarafından hazırlanmıştır. Temsilî senaryolar ve hesaplamalar yöntemi açıklamak içindir; ölçülmüş müşteri sonucu veya başarı garantisi değildir. Yayın ve kaynak yaklaşımımız.