Skip to main content

Backup and Restore a PostgreSQL-Backed Deployment

Use this page to plan the database backup and restore process for a Nexus Repository deployment that uses PostgreSQL.

Manage the PostgreSQL database backup and restore process outside Nexus Repository by using PostgreSQL-native tools or the backup capabilities provided by your infrastructure provider.

Coordinate the PostgreSQL database backup with the Nexus Repository blob store and file-system backups so that they can be restored to corresponding recovery points.

Before You Begin

Before backing up a PostgreSQL-backed deployment:

  1. Determine the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for your deployment.

  2. Review the PostgreSQL or infrastructure-provider backup and restore documentation for your environment.

  3. Identify the blob stores that must be backed up or replicated.

  4. Include the required Nexus Repository file-system data in your backup plan.

  5. Plan the PostgreSQL database and repository backups to occur at approximately the same time.

  6. Plan how you will validate the backup by performing a restore.

See Prepare a Backup for information about blob stores, node ID files, and Nexus Repository file-system data.Prepare a Backup

Backup PostgreSQL

Use PostgreSQL-native backup tools or your infrastructure provider's managed database backup service to back up the PostgreSQL database. For PostgreSQL hosted by a cloud provider, use the cloud-native backup options available for the database service.

Nexus Repository does not support a global read-only mode for PostgreSQL-backed deployments. Normal activity, including some download requests, may update metadata in the database. If you require the strongest consistency between the PostgreSQL database and blob stores, stop Nexus Repository during the backup window.

PostgreSQL provides different backup methods. The following examples show two methods that can be used to implement your backup method:

Backup with pg_basebackup

pg_basebackup is a command-line utility in PostgreSQL used to create a physical backup of a PostgreSQL database cluster. It is a fundamental tool for PostgreSQL administrators who need to perform efficient and reliable physical backups, particularly for large databases and for implementing advanced recovery and replication strategies.

See pg_basebackup documentation

pg_basebackup -h remote_server_ip -U backup_user -D /mnt/backups/pg_cluster_backup -P -v -Xs -R

Where,

  • -h remote_server_ip: Specifies the PostgreSQL server hostname.

  • -U backup_user: Specifies the PostgreSQL user used for the backup.

  • -D /mnt/backups/pg_cluster_backup: Specifies the directory where the PostgreSQL backup is stored. This directory must be empty or not exist.

  • -P: Enables progress reporting, which is helpful for monitoring the backup process.

  • -v: Enables verbose output, providing more detailed information about the backup process.

  • -Xs: includes the required WAL files in the backup.

  • -R: creates a recovery.conf file (or postgresql.conf parameters in newer versions) in the backup directory, which is useful for setting up a standby server.

See the current PostgreSQL pg_basebackup documentation for requirements and additional options.

Backup with pg_dump

pg_dump is a command-line utility for backing up a single PostgreSQL database. It creates a consistent backup while the database remains available and does not block other users from reading from or writing to the database. pg_dump can create plain-text SQL dumps or archive-format backups. Archive formats, such as custom format (-Fc) and directory format (-Fd), are restored with pg_restore and support flexible restore options.

See pg_dump documentation

pg_dump -h <hostname_or_ip> -U <username> -d <database_name> -Fc -f <backup_file.sql>

Where,

  • -h <hostname_or_ip>: Specifies the hostname or IP address of the remote server.

  • -U <username>: Specifies the PostgreSQL user

  • -d <database_name>: Specifies the database to back up

  • -Fc: Creates the backup in PostgreSQL custom format.

  • -f <backup_file.sql>: Specifies the backup file.

PostgreSQL custom-format backups are already compressed. Do not gzip or unzip the resulting file.

Restore PostgreSQL-Backed Deployment

Use the PostgreSQL or infrastructure-provider restore process that corresponds to the backup method used for the database.

At a high level, restore the Nexus Repository environment in the following sequence:

  1. Restore the PostgreSQL database using PostgreSQL-native or infrastructure-provider recovery capabilities.

  2. Restore the corresponding Nexus Repository blob storage.

  3. Restore the required Nexus Repository file-system data.

  4. Validate the recovered environment.

  5. If the database and blob storage are out of sync, complete the applicable reconciliation process.

Reconcile Data After Restore

Database and blob storage can become inconsistent when they are restored from different recovery points.

For self-hosted Nexus Repository deployments, Recovery Mode and Data Repair Tasks provide the documented workflow for reconciling database and blob storage inconsistencies.

Disaster Recovery

For disaster recovery deployments, protect or replicate the PostgreSQL database, repository blob stores, and required file-system data.

Review the Deployment Pattern Library to select the appropriate recovery pattern for your deployment.

For AWS deployments, see Backup and Restore in Amazon Web Services for AWS-specific database, blob store, and file-system recovery options.