Teşhis, düzeltme ve veri kurtarma kabulü ayrı aşamalardır. Bu rehber servis restart, queue/state silme, snapshot cleanup, sertifika doğrulamasını kapatma veya üretim restore talimatı değildir; gerçek neden kurulu sürüm ve doğru run kanıtıyla doğrulanır.
Ekran görüntüleri 16 Ekim 2026 tarihli gerçek laboratuvar arayüzünden alınmıştır. Arayüz İngilizcedir; açıklamalar seçtiğiniz dilde sunulur. Gösterilen kaynak adları, tarihler ve ayarlar örnektir; kendi ortamınızın değerlerini kullanın.
Görsel/işlem sınırı: önceki yetkili incelemenin gerçek hata ekranları kullanılır; yeni hata üretimi veya canlı log toplama yapılmadı. Ekranlar kök nedenin veya düzeltmenin kabulü değildir. Komutlar operatörün doğru node/servis için değerlendireceği read-only örneklerdir; bu çalışmada çalıştırılmadı.
Platform/sürüm ve kaynak/hedef kimliği
Job/run/backup ID ve zaman aralığı
İlgili node, servis ve kanıt kaynağı
Maskelenmiş destek özeti ve izole kabul planı
01
1. Zaman çizelgesini ve kimlikleri oluşturun
İlk belirti, job/run/sub/backup ID, platform, kaynak/hedef ve son iyi zamanı kaydedin. Master, node ve database saat dilimlerini karşılaştırın; UTC ile yerel zamanı karıştırmayın. Aynı policy’nin farklı nesillerini veya farklı testleri tek olay gibi birleştirmeyin.
Önceki gerçek hata ekranı, zaman/run/log korelasyonuna başlangıç örneğidir; terminal log çıktısı veya düzeltme kanıtı değildir. Büyüt ↗
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
02
2. Doğru node ve servis logunu seçin
Repository için era-repository; replikasyon runbook’unda era-replication-controller, era-replica, era-replication-relay, era-replication-scheduler ve EraBackupWeb journal kaynakları belgelenir. Paketler arası servis adlarını doğrulayın. SQL/Oracle/DB2 gibi motor logları ilgili database sunucusunda ayrıca okunur; bütün hata Master’da oluşmaz.
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
03
3. Dar zaman aralığında read-only kayıt toplayın
İlgili servis için hata öncesi ve sonrasını kapsayan journal çıktısını okuyun. Örnek komut yerel read-only kontroldür; buradaki node’da servis varmış gibi körlemesine çalıştırmayın. Gereksiz tüm disk/log dökümü yerine sınırlı zaman aralığı kullanın. Logları temizleme, rotate etme veya servis restart bu adımda yapılmaz.
4. Notification ve Process Steps ile korelasyon yapın
Bildirimdeki iş, run ve backup kimliklerini engine loglarıyla eşleştirin. AD event API’sinde backup_id/job_id/job_type idempotency anahtarıdır; progress ve terminal olaylar ayrıdır. OpenStack/Safir’de quiesce, snapshot ve resume/compensation fazlarını zaman çizelgesine ekleyin. Geç gelen bildirim veya yüzde 100 tek başına kök neden/başarı kanıtı değildir.
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
05
5. Platforma özel dosyaları yalnız gerekli kapsamda inceleyin
Replikasyon controller runbook’u /var/lib/erabackup/replication-controller/logs/JOB_ID.log; VMware belgesi /var/log/erabackup/vmware-replication/policy-ID/ yolunu tarif eder. Gerçek kimliği kullanın ve state/config dosyalarını log diye değiştirmeyin. policy-ID.work/ geçici manifest ve root-only secret içerebilir; destek paketine körlemesine eklemeyin.
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
06
6. Bulguyu, varsayımı ve hassas veriyi ayırın
Hata mesajını doğrudan gözlem, olası nedeni hipotez olarak kaydedin. Token, Authorization başlığı, parola/app password, OTP, private key ve connection string secret değerlerini paylaşmadan önce çıkarın; gerekli kimlikleri tutarlı takma adla eşleyin. Kaynak kopyada OTP/SMTP debug çıktısı görüldüğünden auth loglarını özellikle kontrol edin; orijinal kanıtı yetkili yerde koruyun.
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
07
7. Destek özetini ve tekrar kabulünü hazırlayın
Sürüm/topoloji, zaman aralığı, job/run/backup ID, etki, ilk hata, ilgili maskelenmiş satırlar ve yapılan kontrolleri özetleyin. Düzeltme sonrası görev/katalog/veri kabulünü ayrı belgeleyin. Bu rehber otomatik support bundle veya belirli SIEM/export desteği varsaymaz; bu çalışma log toplamadı/göndermedi, kayıt silmedi veya işi yeniden çalıştırmadı.
Beklenen sonuç
Bulgu, zaman ve ilgili iş kimliği kaydedilir.
MERAK EDİLENLER
Hata mesajı tek başına kök neden midir?
Hayır. Aynı mesaj farklı erişim, kaynak veya veri yolu sorunlarından doğabilir. Zaman, run kimliği, servis ve veri durumu birlikte incelenir.