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.
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. Define release, instance and database scope
With the DBA, record PostgreSQL server/client and agent/master releases, host/port, instance and test database. Inventory extensions, charset/collation, roles/privileges and application dependencies. Use small test data for initial acceptance; do not equate cluster/replica topology with a standalone source.
Expected result
Method, selection and acceptance evidence are recorded.
02
2. Verify agent and native-tool access
Validate instance access from the correct agent service, pg_dump/pg_restore or selected physical-method tool versions, and repository capacity. Physical backup/WAL may require different privileges from a logical-dump account. Keep credentials out of screenshots and stop on read timeouts.
Expected result
Method, selection and acceptance evidence are recorded.
03
3. Select the engine and method under SQL
Select Agent, Policy Name and Storage in Agent Policy → Create Agent Policy. Under SQL → PostgreSQL compare PgDump, PgDumpAll, PgBase - Native Block Incremental (PostgreSQL 17+) and PgBase - WAL Incremental / PITR Log Chain with the installed release. Physical choices may be disabled in the inspected edit copy; do not assume create and edit screens are identical.
Earlier real PostgreSQL Attribute draft: SQL/PostgreSQL, sample policy and repository. Agent read timeout is visible; this is not a valid connection or new backup result. Enlarge ↗
Expected result
Method, selection and acceptance evidence are recorded.
04
4. Check Clients selection and consistency
Select only the test database under the registered instance and compare the summary. PgDumpAll includes cluster scope and global roles; do not treat it as a single-database dump. The OpenShift path selects namespace, service and credential Secret references separately; the agent screen is not a substitute.
Expected result
Method, selection and acceptance evidence are recorded.
05
5. Record physical and log-chain prerequisites
For PgBase native incremental, validate PostgreSQL 17+, an appropriate Full base and required combination tools. pgbase_wal requires a suitable base, WAL archiving/retention and an uninterrupted time range. Adding a date to a logical PgDump point does not provide PITR. No new physical chain or WAL replay was executed in this inspection.
Expected result
Method, selection and acceptance evidence are recorded.
06
6. Plan scheduling and initial backup acceptance
Check scheduling and retention actually exposed for the engine/method in Advanced Settings and Schedules. Compare Full-base and dependent log/differential/incremental-chain retention with capacity; do not assume every method applies to each engine. In an approved small test, record task result, repository output and catalog method together.
Expected result
The selection and relevant acceptance evidence are recorded.
07
7. Complete database and application acceptance
Use the separate engine restore guide to validate database startup, schema, sample queries, row counts and application access on an approved isolated target. Active, Last Backup or a success notification alone is not content acceptance. Record backup identity, method, time and the required chain in the report.
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.