pgBackRest safety

Backups are designed to run against an online PostgreSQL cluster, but they are privileged production operations. They read the whole cluster, consume system resources, write to the repository, and can affect which old backups and WAL remain under the configured retention policy.

Risk levels

Level	Commands	Main concern
Low risk	`make backup-info`	Metadata may be sensitive; verify config and stanza
Operational	`make backup-check`	Exercises stanza and archive communication against the selected environment
Configuration-changing	`make backup-stanza-create`	Creates repository stanza metadata for the configured cluster
Production-impacting	`make backup-full`, `make backup-diff`, `make backup-incr`, `make backup`	Database, disk, network, WAL, and repository load; retention effects

None of the supplied commands or server operations restores or overwrites the PostgreSQL data directory.

Protect access

A physical backup can expose data beyond every table-level application grant. Protect it as production data:

keep the server backup API restricted to superadmin;
restrict shell access to the PostgreSQL host;
restrict read and write access to the pgBackRest repository and configuration;
protect repository credentials and encryption material;
avoid copying sensitive info, check, or failure output into public logs and tickets;
audit who can change schedules, retention, stanza configuration, and PostgreSQL’s archive_command.

The Make targets use operating-system and repository permissions, not komp.ac authorization. A user with sufficient shell access can invoke them even if that user has no komp.ac account.

Verify the target before every manual command

Before running stanza creation, a backup, or a check, verify:

the host and environment;
the pgBackRest binary and version;
the configuration file path;
the stanza name;
pg1-path and the PostgreSQL port and user;
the repository path or remote repository destination;
available database and repository capacity;
whether another pgBackRest job is already running.

Make variable overrides affect only that Make invocation. Server environment variables affect the server after restart. PostgreSQL’s archive_command is configured separately. These three places can drift, causing backups and archived WAL to be sent to different stanzas or repositories.

Control production impact

Monitor PostgreSQL latency, storage throughput, CPU, network traffic, generated WAL, and repository free space while establishing the schedule. Full backups normally have the greatest cost; differential and incremental jobs reduce copied data but still scan and process cluster state.

The supplied example enables start-fast=y and process-max=4. These values affect backup behavior and resource use; they are not performance recommendations for every deployment. Benchmark and monitor the actual host before adopting them unchanged.

Do not launch overlapping jobs casually. The server prevents overlap only among asynchronous operations in one process. It cannot see Make invocations, schedulers, direct pgBackRest commands, or another server replica.

Retention is part of safety

The supplied example sets retention values, but the deployed configuration is authoritative. Retention determines the available recovery window and repository capacity requirements.

Before changing retention or running unusual manual schedules, understand which backup chains and WAL may become eligible for expiration. Never assume that “the last incremental succeeded” means an older recovery point is still retained.

Monitor at least:

the age and status of the newest full, differential, and incremental backups;
continuity of WAL archiving;
repository free space and growth;
failed backup and check output;
the oldest recovery point required by policy;
successful isolated recovery rehearsals.

Treat checks correctly

pgbackrest check is a health check for the configured stanza, repository, PostgreSQL connection, and archiving path. It is valuable after initial setup, after configuration changes, and on a schedule.

It does not prove that every retained chain is complete, that all required WAL can be replayed, that recovery meets the recovery-time objective, or that komp.ac data is valid after recovery. Only a controlled recovery rehearsal can provide that evidence.

Recovery stays outside komp.ac

An external recovery procedure should at minimum cover stopping writers and PostgreSQL, preserving the current state, selecting the backup and WAL target, filesystem ownership, isolated validation, PostgreSQL promotion, rebuilding the external Search index, and controlled reopening of traffic. Those are operator responsibilities, not actions performed by the komp.ac backup service.

Use pgBackRest commands for the exact supported Make targets and pgBackRest server operations for the authenticated API behavior. Logical-dump security and artifact handling are documented separately under pg_dump.