Yedekleri Test Etmenin Net Yolu: Restore Doğrulama Rehberi

Yedek (backup) almak, felaket senaryosunda kurtarma yapabilmenizle aynı şey değildir. Bir yedek dosyası bozuk olabilir, şifre anahtarı değişmiş olabilir, veritabanı şeması uyumsuz kalmış olabilir ya da restore süresi gerçekte hedeflediğiniz RTO’yu (kurtarma süresi) aşabilir. Bu rehberde, yedeklerin gerçekten çalıştığını nasıl doğrulayacağınızı restore test üzerinden net bir planla anlatıyorum.

Hedefiniz; “yedek alınıyor” cümlesini “yedekten geri dönebiliyoruz ve doğruluyoruz” seviyesine taşımak. Bunun için dosya sistemi, veritabanı, kontrol paneli (Plesk/cPanel vb.) ve uygulama katmanında uygulanabilir kontrol adımlarını göreceksiniz.

1) Test hedeflerini tanımlayın: RPO ve RTO olmadan ilerleme olmaz

Yedek testinin ilk çıktısı, başarı/başarısızdan çok ölçüm olmalıdır. Aksi halde test yapıyor olsanız bile iyileştirme kararı veremezsiniz.

RPO (Recovery Point Objective) ölçümü nasıl yapılır?

• RPO’nuzu belirleyin: Örn. “son 15 dk içinde oluşan veri kaybını kabul ediyorum”.
• Test sırasında, restore edeceğiniz noktayı bilerek seçin. (Örn. son tam yedek + belirli log (binlog/WAL) aralığı)
• Restore sonrası kontrol ettiğiniz “veri zaman damgalarını” kayıt altına alın.

RTO (Recovery Time Objective) ölçümü nasıl yapılır?

• Restore süresi tek başına yetmez; uygulamayı ayağa kaldırma süresini de ölçün.
• Uygulama ayağa kalkana kadar şu adımları zamanlayın:
• yedek dosyasının kopyalanması
• restore komutu / panel restore işlemi
• veritabanı migrasyonu/şema kontrolü
• uygulama ayarlarının doğrulanması
• servislerin (web/app/worker) tekrar ayağa kalkması

Aşağıdaki tablo, pratik test çıktısı formatını verir:

2) Test stratejisi seçin: Tam restore mi, kademeli mi?

Her yedeği her gün tam restore etmek maliyetli ve zaman alıcıdır. Bu yüzden “farklı katmanlarda farklı sıklık” yaklaşımı kullanın.

Önerilen test sıklığı (genel, uygulanabilir şablon)

• Günlük: veritabanı (DB) ve kritik dosyalar için “restore doğrulama” (tam sisteme dönmeden)
• Haftalık: uygulama ortamını ayağa kaldıracak şekilde tam restore
• Aylık: farklı bir sunucuda/ortamda (ör. farklı VDS ya da farklı VM) “uçtan uca geri dönüş”

Bu şablonun nedeni net: Günlük test, bozulmuş yedeği erken yakalar. Haftalık/aylık test ise restore sonrası uygulama uyumluluğunu sınar.

Tam restore ile kademeli test farkı

• Tam restore: Dosya sistemi + DB + uygulama config’leri ile gerçek senaryo
• Kademeli test: DB loglarının (binlog/WAL) uygulanabilirliğini doğrulama; dosya bütünlüğünü (hash) doğrulama

3) Dosya sistemi (files) testini boşa düşürmeyin: bütünlük + doğrulama

Dosya yedeği alındıktan sonra “dosya var” demek yeterli değildir. Bozuk arşiv, eksik izinler ya da yanlış ownership (kullanıcı/grup) restore sonrası uygulamayı patlatabilir.

Doğrulama adımları (restore öncesi)

1. Yedek dosyasının boyutu ve hash’i kontrol edin.
2. Arşiv içeriğini açıp temel klasör yapısının geldiğini doğrulayın.
3. Dosya izinleri ve ownership beklenen değerlerle uyumlu mu bakın.

Restore test adımları (dosya katmanı)

• Yedeği ayrı bir test dizinine geri yükleyin (prod’a dokunmadan).
• Uygulamanın kullandığı kritik dizinleri doğrulayın:
• uygulama kodu/temalar eklentiler
• upload/media klasörleri
• config dosyaları (örn. env dosyası şablonu)
• Basit bir doğrulama yapın:
• örnek bir görselin varlığı
• örnek bir endpoint’in statik içerik çekebilmesi

Net kontrol listesi (dosya)

• [ ] Arşiv açılıyor
• [ ] Kritik dosyalar (ör. uploads) var
• [ ] İzin/owner beklenenle aynı
• [ ] Konfig kopyalanıyor (ve env anahtarları doğru)

4) Veritabanı restore testinin kalbi: schema + data + transaction point

DB yedeklerinde en sık görülen sorunlar; yanlış restore sırası, eksik log zinciri, şema uyumsuzluğu ve kullanıcı/rol (privilege) problemleri.

MySQL/MariaDB için restore doğrulama

• Tam yedeği geri yükleyin (snapshot/dump).
• Ardından log/binary log zincirini hedef noktaya kadar uygulayın.
• Uygulamanın beklediği şemaya göre kontrol edin.

Net doğrulama sorguları

Aşağıdaki tarz kontrolleri restore sonrası mutlaka yapın: - Kritik tabloda veri satırı var mı? - En güncel kayıt timestamp’i test noktasıyla uyumlu mu? - Uygulamanın kullandığı view/index/foreign key’ler var mı?

PostgreSQL için restore doğrulama

• Restore edilen taban (base backup) sonrası WAL (Write-Ahead Log) segmentlerinin hedef noktaya kadar uygulandığından emin olun.
• Şema sürümü (migration) kontrolü yapın.

DB testinde başarı ölçümü

Sadece restore komutu “başarılı” dönse bile; uygulama beklenen query’leri çalıştırmayabilir. Bu yüzden testten şu iki kanıtla çıkın: - DB katmanı doğrulaması: kritik sorgular çalışıyor - Uygulama katmanı doğrulaması: ilgili sayfa/endpoint doğru içerik döndürüyor

5) Uygulama ve konfig testleri: restore sonrası ayağa kalkma planı

Yedek restore ettiğinizde sistemin ayağa kalkmaması, genelde “yedek bozuk” değil, “restore sonrası config farklı” kaynaklıdır.

Kontrol edilmesi gereken konfig bileşenleri

• Uygulama config’leri (örn. APP_ENV, DB connection string, cache endpoint)
• Dosya yolları (path) farklı olabilir (test sunucusunda dizinler aynı değilse)
• Kullanıcı/izinler (DB kullanıcıları, dosya sahipliği)
• Şifreler (şifreleme anahtarları, token secret’ları)

Kritik nokta: secret’ler

Yedek içinde secret varsa: aynı şifreyle restore edebilmeniz gerekir. Yedek içinde secret yoksa: restore sonrası uygulama “veriyi okuyamaz” hale gelebilir. Bu nedenle test planında secret’lerin nereden geldiğini net yazın.

Uygulama ayağa kalkma test akışı

1. Web servis (nginx/apache) ayağa kalkıyor mu?
2. Uygulama sunucusu (app) ayağa kalkıyor mu?
3. Worker/queue gerekiyorsa çalışıyor mu?
4. 3-5 kritik endpoint doğrulanıyor mu?

Endpoint doğrulaması için örnek (genel)

• Anasayfa: beklenen içerik ve görseller yükleniyor mu?
• Login: doğrulama akışı çalışıyor mu?
• Bir ödeme/aksiyon akışı varsa: en azından “state okuma” çalışıyor mu?

6) Nerede test edeceksiniz? İzole ortam ve maliyeti kontrol eden yaklaşım

Restore testinin başarılı olması kadar, test sırasında risk almamanız da önemlidir. Bu nedenle test ortamını prod’tan izole edin.

İzolasyon seçenekleri

• Aynı sağlayıcıda ayrı bir VDS/VPS
• Aynı ağ içinde farklı bir VM
• Mümkünse staging alanı (ayrı domain/subdomain)

Test ortamı “benimle aynı mı” sorusu

• Aynı işletim sistemi sürümü: paket bağımlılıklarını azaltır
• Aynı PHP/Node/Python versiyonu: uygulama uyumluluğu artar
• Aynı kontrol paneli sürümü: Plesk/cPanel restore davranışları farklı olabilir

7) Rutinleştirin: yedek test prosedürü ve kanıt dosyaları

Yedek testini bir defalık iş yaparsanız iki hafta sonra unutulur. Bunun yerine prosedür ve kanıt mekanizması kurun.

Prosedür şablonu (kopyala-kullan)

• Test tarihi/saat: YYYY-MM-DD HH:MM
• Test türü: dosya / DB / uçtan uca
• Restore edilen yedek: dosya adı + timestamp
• Ortam: staging VDS/VPS
• Süreler:
• restore başlangıç
• restore bitiş
• servis ayağa kalkış
• endpoint doğrulama bitiş
• Sonuç:
• başarılı/başarısız
• hata mesajları
• Aksiyon:
• düzeltme (örn. log zinciri eksik)
• tekrar test tarihi

Kanıt (evidence) neleri içermeli?

• Restore logları
• 3-5 endpoint çıktısının doğrulanmış hali (ekran görüntüsü veya basit rapor)
• Kritik DB sorgu sonuçları (satır sayısı, son kayıt timestamp)

8) Yaygın sorunlar ve net çözüm yönleri

Yedek testinde en çok karşılaşılan hataları net gruplandırmak, hızlı teşhis sağlar.

“Restore oldu ama uygulama hata veriyor”

Sık nedenler: - config/env farklı - dosya izinleri farklı - secret anahtar uyuşmazlığı - cache/queue hazır değil

Çözüm yönü: - restore sonrası config dosyalarını karşılaştırın - uygulamanın hatasını loglardan okuyun - dosya ownership ve permission’ı normalize edin

“DB restore tamamlandı ama veri yok”

Sık nedenler: - yanlış yedek seti seçildi - log zinciri hedef noktaya uygulanmadı - migrasyonlar (migration) restore edilmedi

Çözüm yönü: - yedek seti timestamp kontrolü - schema/migration adımlarını test akışına ekleyin

“Restore süresi RTO’yu aşıyor”

Sık nedenler: - yedek dosyası çok büyük - restore işlemi tek thread - depolama (disk) yavaş - network aktarımı gecikiyor

Çözüm yönü: - kademeli yedek (incremental) + uygun restore planı - hedef RTO’ya göre yedek boyutu ve aktarım yolunu optimize edin

Sonuç: İlk hedefiniz restore’i kanıtlamak olsun

Yedeklerin çalıştığını anlamanın en net yolu, restore edip sonra doğrulamaktır. Prod üzerinde risk almadan; günlük DB/dosya doğrulama, haftalık uçtan uca test ve aylık farklı ortamda geri dönüş planı uygulayın. Ayrıca her testten ölçüm (RPO/RTO), kanıt ve aksiyon çıkarın.

Başlamak için bugün tek bir adım belirleyin: Mevcut yedeklerden birini seçin, staging bir ortamda restore edin ve 3 kritik endpoint ile DB sorgusunu doğrulayın. Bu ilk test, sonraki iyileştirmelerinizi tamamen veriyle şekillendirir.