Logical dump, physical ve transaction log restore farklı hedef ve zincir gerektirir. Arayüzde Different Location seçeneği yalnız bazı motor/yöntem/kayıt birleşimlerinde sunulur. İlk kabul için yeni ve izole database kullanın; canlı database’in üzerine dönüş ayrı planlanı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.
Bazı laboratuvar görüntüleri gizlilik incelemesi için yayından çıkarılmıştır. Yazılı adımları izleyin ve kendi ortam değerlerinizi kullanın.
Laboratuvar kapsamı: mevcut katalog ekranı canlı veri kurtarma testi yerine geçmez. Bu çalışma sırasında restore gönderilmedi; hedef formu yalnız kullanılabilir ve uygun kayıt bulunduğunda gösterilir.
Kaynak motor, instance, database, yöntem ve kurtarma tarihi
Erişilebilir Full ve gerekli log/WAL/artımlı zincir
Uyumlu hedef motor ve benzersiz database adı
Şema, veri ve uygulama kabul sorguları
01
1. Kaynak kaydın yöntemini doğrulayın
Home → Backups → Backup List içinde doğru database işini bulun. Job Type, instance/database adı, Last Backup ve yöntemi karşılaştırın. Not Yet Backup veya eksik obje bulunan bir kaydı kullanılabilir nokta saymayın. Ajan database kaydı ile OpenShift database kaydının hedef formları farklıdır.
Motor ve Last Backup değerlerini karşılaştırın. Not Yet Backup kullanılabilir kurtarma noktası anlamına gelmez. Büyüt ↗
Beklenen sonuç
Doğru motor ve yöntem için geçerli kayıt belirlenir.
02
2. RESTORE içinde tarih ve zinciri seçin
Action → Restore ile Step One açın. Instance/database öğesini açıp uygun Full ve bağlı noktaları inceleyin. Seçilen kurtarma hedefi için bütün parçaların erişimini kontrol edin. pg_dump tek dump anına döner; PITR için yalnız tarih seçmek yeterli değildir, doğrulanmış base backup ve log/WAL zinciri gerekir.
PostgreSQL pitr_test kaydında Method: PGDUMP ve Full noktaları. Database adındaki pitr ifadesi PITR desteğinin kanıtı değildir. Büyüt ↗
Beklenen sonuç
Kurtarma noktası ve gerekli zincir eksiksizdir.
03
3. Ajan akışında ayrı hedef seçin
Step Two içinde sunuluyorsa Different Location seçin. Hedef ajan/instance, yeni database adı ve veri/log dizinlerini motorun formuna göre doldurun. Seçenek yoksa Original Location ile test yapmaya geçmeyin; yönteme uygun izole restore planını teknik ekiple netleştirin. SQL Server AG’ye doğrudan overwrite veya otomatik join/seed varsaymayın.
PostgreSQL PGDUMP → Different Location: Restore Agent, Database Name ve Instance. Hedef adı boş bırakıldı; Summary ve Restore gönderilmedi.
Beklenen sonuç
Kaynak üretim verisine dokunmayan hedef belirlenir.
04
4. OpenShift database hedefini hazırlayın
Database kaydında Target Namespace, Target Service / Host, Port, Target Database, Database Username, Credential Secret ve Password Key alanlarını kontrol edin. Hedef instance ve boş test database’i önceden hazır olmalıdır. PostgreSQL logical restore temizleme/yeniden oluşturma işlemleri içerebilir; mevcut verinin bulunduğu hedefi kullanmayın. Secret değerlerini ekran çıktısına taşımayın.
Beklenen sonuç
Hedef servis, yetki ve boş database hazırdır.
05
5. Summary ile kapsamı son kez karşılaştırın
Kaynak database, yöntem, tarih, hedef sunucu/database ve dosya yollarını karşılaştırın. Hedef çakışması veya overwrite riski varsa durun. Restore yalnız bu değerler ve gerekli zincir doğrulandıktan sonra onaylı test hedefi için gönderilir. Bir önizleme ekranı başarılı restore kanıtı değildir.
Beklenen sonuç
Onaylanan kaynak ve hedef açıkça kayıt altındadır.
06
6. Görev sonucunu motorla karşılaştırın
EraBackup görev durumunu hedef motorun hata kaydı ve database durumuyla karşılaştırın. OpenShift akışında Job/Pod sonucunu da inceleyin. Başarısız işi aynı hedefe art arda göndermeyin; kısmen oluşmuş database’i DBA ile değerlendirin. Otomatik AG join/seed veya log sonlandırma davranışını varsaymayın.
Komut örneği
oc -n <TARGET_NAMESPACE> get jobs,pods
Beklenen sonuç
Görev sonucu ve hedef database durumu tutarlıdır.
07
7. Veri ve uygulama kabulünü tamamlayın
Beklenen şema, tablo, kritik kayıt sayımı, karakter seti ve kullanıcı yetkilerini kontrol edin. SQL Server için DBA’nın uygun bütünlük kontrolünü; PostgreSQL/MySQL için kritik sorgu ve uygulama testini tamamlayın. Kurtarma noktası, sürümler, süre ve sonucu belgeleyin; uygulamayı üretim hedefine yönlendirmek ayrı geçiş işlemidir.
Beklenen sonuç
Kullanılabilir veri ve uygulama kabulü belgelenir.
MERAK EDİLENLER
Logical dump zaman noktasına dönüş sağlar mı?
Tek başına hayır. Dump kendi anına dönüş içindir. PITR, motora uygun base backup ve kesintisiz log/WAL/binlog zinciriyle ayrıca doğrulanır.