Veritabanınızı doğru yöntemle koruyun. Kurtarma zincirini planlayın.
Ajan tabanlı veritabanı politikasını ve OpenShift PostgreSQL/MySQL logical streaming yolunu ayrı hazırlayın; kaynak, yöntem, saklama ve ilk yedek kabulünü kontrol edin.
Bu rehber PostgreSQL, MySQL/MariaDB ve SQL Server için yöntem seçimini anlatır. Oracle, IBM DB2 ve MongoDB arayüz seçenekleri her sürüm ve topolojide doğrulanmış destek anlamına gelmez. Logical dump, physical backup ve transaction/WAL zincirini birbirinin yerine kullanmayın.
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.
Laboratuvar kapsamı: ekranlar form ve mevcut kayıtları gösterir. Ajan keşfi read timeout verdi; canlı database seçim ekranı eklenmedi. Yeni database yedeklemesi veya uçtan uca restore yapılmadı. OpenShift canlı kaynak seçimi cluster yeniden kurulduğunda doğrulanmalıdır.
Motor sürümü, işletim sistemi ve standalone/cluster topolojisi
Ajan veya OpenShift adapter sürümü ve repository erişimi
Kaynak database, gerekli yetkiler ve güvenli kimlik bilgisi referansı
RPO, saklama süresi ve izole restore hedefi
01
1. Motoru ve kurtarma hedefini belirleyin
Hangi database’in, hangi tarihe ve hangi hedefe döneceğini belirleyin. Logical dump belirli bir dump anını korur; sürekli zaman noktasına dönüş için ayrıca doğrulanmış log/WAL/binlog zinciri gerekir. Always On, replica ve DAG gibi topolojileri genel tek sunucu politikasıyla eşitlemeyin.
Beklenen sonuç
Motor, yöntem ve kabul hedefi yazılıdır.
02
2. Agent Policy içinde kaynağı tanımlayın
Home → Policies → Agent Policy → Create Agent Policy yolunu açın. Doğru Agent, Policy Name ve Storage seçin. Policy Type olarak SQL, ardından işletim sisteminin sunduğu SQL Type değerini seçin. Kaynak ajan çevrim dışıysa önce erişimi düzeltin; kayıtlı ajan adı başarılı bağlantı kanıtı değildir.
Agent Policy → Attribute: SQL ve PostgreSQL seçili; test politika adı ve repository tanımlı. Ajan alanı Select Agent durumunda ve read timeout hatası görünür; bu taslak geçerli bir bağlantı örneği değildir ve kaydedilmedi. Büyüt ↗
Beklenen sonuç
Database motoru ve kaynak ajan doğru eşleşir.
03
3. Instance ve tek test database’ini seçin
Clients adımında kayıtlı instance’ı ve database listesini inceleyin. İlk kabul için tek küçük test database’i seçin. Instance hesabı ve portunu güvenli bağlantı kaydından yönetin; parolayı politika adına veya komut satırına koymayın. SQL Server Always On için gerçek kaynak replica, sağlık ve backup preference davranışı eşleşen sürümde ayrıca test edilmelidir.
Beklenen sonuç
Seçilen instance ve database kapsamı nettir.
04
4. Yedekleme yöntemini veriyle eşleştirin
PostgreSQL için pg_dump, pg_dumpall ve physical/pg_basebackup farklı kurtarma kapsamlarıdır. MySQL/MariaDB logical dump tutarlılığını tablo motorlarıyla değerlendirin; single-transaction her tablo türü için garanti değildir. MSSQL Transaction Backup (Truncate Logs/Keep Logs) seçeneklerini DBA ile belirleyin; log zinciri ve recovery model doğrulanmadan değiştirmeyin.
Beklenen sonuç
Yöntemin ürettiği veri ve gereken kurtarma zinciri bilinir.
05
5. OpenShift logical yolunu ayrı yapılandırın
OpenShift PostgreSQL/MySQL için VM Policy → OpenShift yolunu kullanın. Clients içinde tek database Pod seçin; Advanced Settings içinde Application-consistent database, Database engine, Namespace, Service / Host, Port, Database, Username, Credential Secret, Password Key ve Adapter Image alanlarını doldurun. İlk PostgreSQL logical testte PITR kapalı ve Full seçilidir. Bu yol pg_dump veya mysqldump üretir; PVC blok kopyası değildir.
Komut örneği
sudo systemctl status era-openshift-database-scheduler --no-pager
oc -n <NAMESPACE> get pods,svc,jobs
Beklenen sonuç
Ajan akışı ve Kubernetes Job akışı karıştırılmaz.
06
6. Saklama ve ilk Full çalışmasını planlayın
Advanced Settings ve Schedules içinde saklama ve zaman penceresini RPO’ya göre düzenleyin. Full nokta ile ona bağlı log/artımlı veriyi birlikte koruyun. Özeti kontrol edip yalnız onaylı test kaynağı için politikayı kaydedin ve uygun Full eylemini başlatın. PostgreSQL PITR kapalı logical yolda Incremental seçmeyin; her çalışma yeni dump oluşturur.
Beklenen sonuç
Planlı test işi ve saklama zinciri tanımlıdır.
07
7. Katalog kaydını restore ile kabul edin
Bildirim ve görev sonucunu Backup List/katalogdaki motor, instance, database, yöntem ve tarihle karşılaştırın. OpenShift için Job sonucunu ve repository dump objesini de doğrulayın. Yeni ve izole hedefe geri yükleyerek tablo, kayıt ve uygulama sorgularını karşılaştırın. Yalnız Last Backup tarihi veya yüzde 100 bildirimi veri kabulü sayılmaz.
Veritabanı Backup List kayıtları. Motorlar ve tarihler mevcut laboratuvar kayıtlarıdır; yeni yedekleme yapılmadı. Büyüt ↗
Beklenen sonuç
Yedek kaydı ve izole veri doğrulaması birlikte belgelenir.
MERAK EDİLENLER
Her veritabanı aynı adımlarla korunur mu?
Hayır. Motor, yöntem, sürüm, ajan ve cluster topolojisine göre seçim ve kabul değişir. İlk denemeyi küçük bir test database’iyle yapın.