Test edilmemiş bir yedek, güvence değil varsayımdır. Ve varsayımların ortak özelliği şudur: doğru olup olmadıklarını en kötü anda öğrenirsiniz — geri dönmek zorunda kaldığınız gün.
Kısa cevap: geri yükleme tatbikatı nedir?
Geri yükleme tatbikatı, mevcut yedeğinizi canlı sisteme dokunmadan ayrı bir ortama geri yükleyerek iki şeyi ölçmektir: ne kadar sürede döndüğünüz ve dönen verinin eksiksiz olup olmadığı. Yedeklerin alınıyor olması bu iki sorunun cevabını vermez; yalnızca dosyaların bir yerde durduğunu gösterir. Tatbikat çoğu işletme için birkaç saatlik bir çalışmadır ve yılda iki kez tekrarlandığında, felaket senaryosunu bilinen bir süreye indirger.
Tatbikatın 5 adımı
| Adım | Ne yapılır? | Ölçülen |
|---|---|---|
| 1. Senaryo seçimi | "Dün gece sunucu tamamen kayboldu" gibi net bir varsayım | Kapsamın netliği |
| 2. Ortam hazırlığı | Ayrı bir test ortamı kurulur; canlıya dokunulmaz | Hazırlık süresi |
| 3. Geri yükleme | Dosyalar, veritabanı ve yapılandırma geri getirilir | Toplam süre |
| 4. Doğrulama | Site açılıyor mu, veriler tam mı, akışlar çalışıyor mu | Bütünlük |
| 5. Kayıt | Süre, eksikler ve karşılaşılan engeller yazılır | Bir sonraki tatbikatın girdisi |
Dördüncü adımda en sık atlanan kontrol şudur: sitenin açılması yeterli değildir. Kullanıcı girişi, form gönderimi, ödeme adımı ve e-posta çıkışı ayrı ayrı denenmelidir. Dosyaları geri gelmiş ama veritabanı bağlantısı eski sunucuyu gösteren bir kurulum, "geri yüklendi" sayılmaz.
Ölçülecek iki rakam
Tatbikatın çıktısı bir "başarılı/başarısız" değil, iki sayıdır:
- Geri dönüş süresi. Olayın fark edilmesinden sistemin çalışır hâle gelmesine kadar geçen süre. Bu rakam, kesinti maliyetinizi doğrudan belirler ve iş sürekliliği planınızın temelidir.
- Veri kaybı penceresi. Son yedek ile olay anı arasındaki süre. Günde bir yedek alıyorsanız, en kötü senaryoda bir günlük veri kaybedersiniz. Bu pencerenin kabul edilebilir olup olmadığı iş kararıdır, teknik karar değil.
Bu iki rakam yazılı hâle geldiğinde, yedekleme tartışması "yeterli mi" belirsizliğinden çıkar ve somut bir kabul edilebilirlik sorusuna dönüşür. İki kavramın ayrıntısını yedekleme ve felaket kurtarma yazımızda ele almıştık.
Tatbikatta ortaya çıkan tipik sorunlar
- Yedek eksik kapsamlı. Dosyalar var, veritabanı yok; ya da veritabanı var, yükleme klasörü yok. En sık karşılaşılan bulgudur.
- Yapılandırma dosyaları taşınmamış. Sunucu ayarları, sertifikalar, cron tanımları ve e-posta yapılandırması yedek kapsamında değildir. Site geri gelir ama çalışmaz.
- Yedek bozuk veya eksik yazılmış. Arşiv açılmıyor ya da tabloların bir kısmı boş. Bu, yalnızca açmayı denemekle anlaşılır.
- Şifre ve erişim eksikliği. Yedeği geri yükleyecek kişinin sağlayıcı paneline erişimi yoktur; süre, teknik nedenlerle değil idari nedenlerle uzar.
- Süre beklenenden çok uzun. Büyük dosyaların indirilmesi ve veritabanının içe aktarılması, tahmin edilenin katları sürebilir.
- Şifreleme anahtarı bulunamıyor. Yedek şifreli, anahtar ise yalnızca eski sistemde saklanmış.
Bu altısının hepsi, gerçek bir olayda öğrenilirse maliyetlidir; tatbikatta öğrenilirse yalnızca bir düzeltme kalemidir.
Ne sıklıkta yapılmalı?
- Yılda en az iki kez tam tatbikat (dosya + veritabanı + yapılandırma).
- Çeyrekte bir hafif doğrulama: yedeğin varlığı, boyutu ve açılabilirliği kontrol edilir.
- Her büyük değişiklikten sonra: sunucu taşıma, sürüm yükseltme, yeni bir sistem eklenmesi.
- Yedekleme yapılandırması değiştiğinde mutlaka bir doğrulama yapılmalıdır.
Netişlem uzman görüşü: en çok karşılaştığımız bulgu, kapsamın eksik olması
Tatbikat yaptığımız işletmelerde en sık ortaya çıkan sorun, yedeğin bozuk olması değil; kapsamının eksik olması. Dosyalar düzenli yedekleniyor ancak veritabanı ayrı bir sistemde tutuluyor ve kimse onu kontrol etmemiş. Ya da her ikisi de var, ancak e-posta hesapları ve sunucu yapılandırması kapsam dışında. Bu tabloda "yedeğimiz var" cümlesi teknik olarak doğru, pratik olarak yanıltıcı oluyor.
İkinci gözlemimiz, geri dönüş süresinin neredeyse hiç ölçülmemiş olması. İşletmeler "yedekten döneriz" diyor ama kaç saatte döneceklerini bilmiyor. O rakam ölçüldüğünde, çoğu zaman beklenenin belirgin biçimde üzerinde çıkıyor ve bu, iş sürekliliği planını doğrudan değiştiriyor.
Üçüncüsü, tatbikatın bir başarısızlık testi gibi görülmesi. Oysa tatbikatta sorun bulmak amaçtır; sorunsuz geçen bir tatbikat, ya çok iyi hazırlanmışsınız ya da yeterince derin bakmamışsınız demektir. Bulgu üretmeyen tatbikat, genellikle ikinci gruba giriyor.
Tatbikat kontrol listesi
- Senaryo yazılı ve kapsamı net.
- Test ortamı canlıdan tamamen ayrı.
- Geri yükleme yalnızca yedekten yapıldı (canlıdan kopyalama yok).
- Dosyalar, veritabanı ve yapılandırma birlikte geri getirildi.
- Site açılıyor; ana sayfa dışındaki sayfalar da kontrol edildi.
- Kullanıcı girişi, form ve ödeme akışı denendi.
- E-posta gönderimi test edildi.
- Zamanlanmış görevlerin tanımları kontrol edildi.
- Toplam süre kaydedildi.
- Veri kaybı penceresi hesaplandı.
- Eksikler ve engeller yazıldı; sorumlu ve tarih atandı.
- Bir sonraki tatbikat takvime alındı.
Sık sorulan sorular
Tatbikat canlı sistemi riske atar mı?
Doğru yapıldığında hayır. Geri yükleme ayrı bir ortama yapılır ve canlı sisteme hiç dokunulmaz. Riski ortadan kaldıran tek kural şudur: tatbikat sırasında canlı sistem üzerinde hiçbir değişiklik yapılmaz.
Sağlayıcım yedek alıyor, ben ayrıca tatbikat yapmalı mıyım?
Evet. Sağlayıcının yedeği olması, sizin geri dönebileceğiniz anlamına gelmez; kapsam, süre ve talep süreci farklı olabilir. Tatbikat, sağlayıcının yedeğini kullanarak da yapılabilir — ölçtüğünüz şey, o yedekle ne kadar sürede döneceğinizdir.
Küçük bir site için de gerekli mi?
Ölçek küçüldükçe tatbikat da kısalır; küçük bir sitede bu iş bir saat sürebilir. Ancak gerekliliği değişmez: yedeğin çalışıp çalışmadığı, sitenin büyüklüğünden bağımsız bir sorudur.
Yedeği geri yükleyebilecek kaç kişi olmalı?
En az iki. Tek kişiye bağlı bir geri yükleme kabiliyeti, o kişi ulaşılamadığında yok hükmündedir. Gerekli erişimler ve adımlar yazılı olmalı, ikinci kişi de tatbikata katılmalıdır.
Tatbikatta sorun bulursam ne yapmalıyım?
Bulgu, tatbikatın başarısı sayılır. Her bulguya bir sorumlu ve tarih atanır, düzeltme sonrası kısa bir doğrulama yapılır. Önemli olan bulguların bir listede kalmayıp kapatılmasıdır.
Sonuç
Yedekleme, alınan kopya sayısıyla değil geri dönebilme yeteneğiyle ölçülür. Yılda iki kez yapılan birkaç saatlik bir tatbikat, "yedeğimiz var" cümlesini iki somut rakama dönüştürür: kaç saatte döneriz ve ne kadar veri kaybederiz. Bu iki rakamı bilen işletme, kriz anında karar vermek zorunda kalmaz.
Tatbikatınızı birlikte planlamak isterseniz bize ulaşın. Kurumsal yedekleme, SLA garantisi ve sunucu yönetimi çözümlerimizi inceleyebilirsiniz.