Agent-based PostgreSQL and OpenShift logical-database paths are separate workflows. PgDump/PgDumpAll logical output, PgBase physical chains and WAL archives are different recovery acceptance scopes. A PostgreSQL 17+ native incremental option does not establish ready support for every release.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Some lab screenshots are withheld pending privacy review. Follow the documented steps and use your own environment values.
Real-screen scope: PostgreSQL Attribute, PGDUMP Full points and the Different Location form from the earlier authorized lab inspection are reused unchanged. The Attribute agent had a read timeout; the name pitr_test is not PITR evidence. No new capture or backup/restore was performed. These images do not validate PgBase/WAL/PITR or live OpenShift acceptance.
Engine, agent/master releases and instance identity
Database scope, method and access privileges
Full base, log chain and repository access
Isolated destination, collisions and application acceptance
01
1. Identify record method and source identity
Compare host, instance/database, Method and date for the PostgreSQL job in Backup List. A Not Yet Backup entry is not a usable point. Do not handle Full dumps, physical bases and log chains as the same restore method.
Expected result
Method, selection and acceptance evidence are recorded.
02
2. Match Full and dependent points
Inspect the correct database and Full point under Action → Restore. PGDUMP returns to one dump time; the earlier real pitr_test PGDUMP entry is not WAL/PITR evidence. A PgBase/native or WAL chain needs every required piece and a compatible destination release.
Earlier PGDUMP pitr_test Full points. The pitr name does not establish WAL/PITR support; no new restore was executed. Enlarge ↗
Expected result
Method, selection and acceptance evidence are recorded.
03
3. Check the method-specific destination form
The inspected PgDump and PgBase paths offer Original Location/Different Location, while PgDumpAll offers only Original Location. Match Restore Agent, Instance and any new Database Name to the correct source. Do not treat physical-instance restore as a single-database logical import. Use a clean isolated destination for the first test.
Earlier PGDUMP Different Location form: Restore Agent, Database Name and Instance. The destination name is empty; Summary/Restore was not submitted.
Expected result
Method, selection and acceptance evidence are recorded.
04
4. Prepare destination release and data dependencies
Compare destination engine/tools, extensions, roles, tablespace/data paths, permissions and capacity. For physical restore validate major-release/layout compatibility and stopped-test-instance requirements. OpenShift logical recovery separately prepares namespace/service/Secret and a clean test database; it does not imply PVC or whole-cluster recovery.
Expected result
Method, selection and acceptance evidence are recorded.
05
5. Validate Summary and the time target
Compare source method, point, Restore Agent, instance and destination database against Summary. If PgBase Point In Time is present, check the valid range and time zone; the field does not supply missing WAL. Do not submit Restore until destination cleanup/recreation effects are understood. No new Restore was submitted in this inspection.
Expected result
Method, selection and acceptance evidence are recorded.
06
6. Compare engine and data state
Compare EraBackup task results with PostgreSQL engine logs, database access and any recovery/replay state. Inspect a partially failed destination with the DBA; do not blindly resubmit restore to the same target. Queueing or a success notification is not data-integrity acceptance.
Expected result
Method, selection and acceptance evidence are recorded.
07
7. Document data and application acceptance
With the data owner, compare test queries, schema, sample rows, consistency and application connections. Record actual recovery time and data loss, releases, backup chain and destination identity. Separate standalone-database acceptance from cluster/HA failover acceptance. No production connection or DNS cutover was performed while preparing this guide.
Expected result
The selection and relevant acceptance evidence are recorded.
COMMON QUESTIONS
Does a successful task mean the application is ready?
Not by itself. Engine integrity, required log chains, data queries and application access need separate validation; HA/topology acceptance is assessed separately.