pg_probackup3 allows running a database instance directly from a backup, inspecting and restoring specific data without requiring a full restore, using the fuse command.
This command implements the
FUSE (Filesystem in User Space) mechanism,
mounting a virtual representation of the backup directory.
Postgres Pro interacts with this mounted
directory as if it were an actual PGDATA directory,
while proxying all file system requests to the backup files. Since changes
are written to the cache rather than the backup, the original backup remains
unchanged, and all operations are read-only.
The FUSE mechanism does not provide all the
capabilities required for production environment. It is thus recommended
to use fuse for one-time operations only. The performance
of fuse operations
may vary significantly depending on your storage type (S3, NFS, SSD).
Figure 3.1. The pg_probackup3 FUSE Mechanism
The key use cases for the fuse command are as follows:
Restore deleted data from a particular date (for example, using pg_dump).
Investigate data from a certain point in time.
Provide a read-only production-like environment when a full restore would be time-consuming.
Roll back to a specific moment in time to test and debug application failures.
Run reports on a backup without the overhead of a full restore, as an alternative to replication.
Support developer databases on FUSE without the need to perform a full multi-gigabyte restore.
On ALT Linux, the user running pg_probackup3
must be a member of the fuse group. See the
ALT Linux documentation
for details.
To use the mounted backup as PGDATA, set
mnt_path as the path for the
-D parameter when starting
Postgres Pro with
pg_ctl start.
To ensure sufficient disk space for FUSE operations, use the
--cache-dir option to specify a custom directory for
cache storage.
Mounting a backup chain requires pre-generated file maps. To enable file map generation, use one of the following methods:
For details on the fuse command and
its parameters, refer to the section called “Commands”.