İş hedefini ölçülebilir tanımlayın
Ne kadar veri kaybının ve hizmet kesintisinin kabul edilebilir olduğunu uygulama sahibiyle belirleyin. Son başarılı yedeğin tarihi ile gerçekten geri yüklenebilen son veri noktası aynı olmayabilir. İşlem sürelerini tahmin yerine provada ölçün.
Prova kapsamını yazın: tek site mi, veritabanı mı, posta mı, bütün sunucu mu? Tek bir statik dosyayı geri getirmek, dinamik bir müşteri uygulamasının veya tüm AdaPanel kurulumunun kurtarıldığını göstermez.
Kurtarma girdileri kontrol listesi
| Girdi | Doğrulanacak nokta |
|---|---|
| Dosya paketi | Beklenen sürüm, bütünlük ve okunabilirlik |
| Veritabanı yedeği | Doğru motor, uyumlu sürüm ve gereken yedek zinciri |
| Ortam ayarları | Bağlantılar ve sırlar için güvenli erişim |
| Çalışma zamanları | PHP, .NET veya uygulamaya özel bağımlılıklar |
| İzinler ve görevler | Dosya kimlikleri ve arka plan işlerinin sahipliği |
Üretimi etkilemeden geri yükleyin
- Ayrı bir hedef hazırlayın; üretim DNS ve veritabanı bağlantısına yanlışlıkla bağlanmayacağını doğrulayın.
- Yedeği seçip kaynak tarihini ve bütünlük bilgisini kaydedin. Yedek paketinin içeriğini varsaymak yerine envanterini inceleyin.
- Dosyaları ve veri motorunun belgelerine uygun veritabanı yedeğini geri yükleyin; hesap ve izin eşlemelerini düzeltin.
- Ortamı test değerleriyle bağlayın; e-posta, ödeme ve webhook gibi gerçek dış etkileri engelleyin.
- Uygulamayı başlatın ve kritik işlemleri tekrar edin; başlangıç ve bitiş saatlerini kaydedin.
Dosya sayısı yerine uygulama tutarlılığını ölçün
Örnek bir kullanıcıyla giriş, beklenen kaydı okuma, güvenli test kaydı oluşturma ve dosya indirme gibi işlemleri deneyin. Veritabanındaki dosya referansları gerçekten geri gelen yüklemelerle eşleşmelidir. Kayıt sayısının benzemesi tek başına tutarlılık kanıtı değildir.
Canlı yazılan dosya ve veriyi farklı anlarda kopyalamak uyuşmazlık yaratabilir. Veritabanı motorunun desteklediği yedek yöntemini ve uygulamanın tutarlı kesit alma ihtiyacını değerlendirin. Bütün veritabanları için aynı dosya kopyalama yöntemini kullanmayın.
Prova raporundan bakım işine geçin
Rapor; seçilen yedeği, geri gelen veri zamanını, toplam süreyi, başarısız kontrolleri ve eksik bağımlılıkları göstermelidir. Eksik anahtar veya bilinmeyen parola bulunduysa canlı olay yaşanmadan önce erişim sürecini düzeltin.
Prova ortamındaki müşteri verisini saklama politikasına göre kaldırın ve geçici erişimleri kapatın. Büyük uygulama, şema veya barındırma değişikliğinden sonra aynı provayı yenileyin; geçen yılki başarılı test bugünkü paketin kanıtı değildir.
Sık sorulan sorular
Yedekleme başarılı mesajı yeterli mi?
Hayır. Ayrı ortamda geri yükleme ve uygulama kabul testi gerekir. Paketin oluşması ile kullanılabilir kurtarma farklı sonuçlardır.
Prova canlı sitenin üzerine mi yapılır?
Normal prova için ayrı hedef kullanın. Üretime geri yükleme farklı risk ve bakım planı gerektirir.
Veritabanı dosyasını kopyalamak her zaman yeterli mi?
Hayır. Motorun desteklediği yedekleme ve geri yükleme yöntemini kullanın; aktif dosyaların kopyası tutarlı bir yedek olmayabilir.
Kurtarma süresini nasıl öğrenirim?
Bağımlılıkları hazırlamadan uygulama kabulüne kadar geçen gerçek süreyi provada ölçün. Yalnız dosya indirme süresini raporlamayın.