Skip to main content

Prepare a Backup

Nexus Repository stores data in blob stores and keeps some metadata and configuration information separately in databases. You must back up the blob stores and metadata databases together. Your backup strategy should involve backing up both your databases and blob stores together to a new location in order to keep the data intact.

Complete the steps below to perform a backup:

Blob Store Backup

You must back up the filesystem or object store containing the blobs separately from Nexus Repository.

  • For File blob stores, back up the directory storing the blobs.

    • For a typical configuration, this will be $data-dir/blobs.

  • For S3 blob stores, you can use bucket versioning as an alternative to backups. You can also mirror the bucket to another S3 bucket instead.

Note

For cloud-based storage providers (S3, Azure, etc.), refer to their documentation about storage backup options.

Node ID Backup

Each Nexus Repository instance is associated with a distinct ID. You must back up this ID so that blob storage metrics (the size and count of blobs on disk) and Nexus Firewall reports will function in the event of a restore / moving Nexus Repository from one server to another. The files to back up to preserve the node ID are located in the following location (also see Directories):

$data-dir/keystores/node/

To use this backup, place these files in the same location before starting Nexus Repository.

Database Backup

The databases that you export have pointers to blob stores that contain components and assets potentially across multiple repositories. If you don’t back them up together, the component metadata can point to non-existent blob stores. Your backup strategy must involve backing up both your databases and blob stores together to a new location in order to keep the data intact.

Embedded Databases

Here’s a common scenario for backing up custom configurations in tandem with the database export task:

  1. Configure the appropriate backup task to export databases:

    1. Use the Admin - Export databases for backup task for OrientDB databases

    2. Use the Admin - Backup H2 Database task for H2 databases

  2. Run the task to export the databases to the configured folder.

  3. Back up custom configurations in your installation and data directories at the same time you run the export task.

  4. Back up all blob stores.

  5. Store all backed up configurations and exported data together.

Note

Write access to databases is temporarily suspended until a backup is complete. It’s advised to schedule backup tasks during off-hours.

External Database

Backing up a PostgreSQL database is crucial for resilience. For very large databases, consider using streaming replication or other advanced backup techniques. Always test your backups by restoring them to a test environment.

See the PostgreSQL documentation on backing up the database.

Here's are examples that may be used to implement your methods:

Command-line Utility: 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

  • -h remote_server_ip: Specifies the hostname of the PostgreSQL server.

  • -U backup_user: Specifies the username to connect to the PostgreSQL server. Replace postgres with the appropriate username.

  • -D /path/to/backup/directory: Specifies the directory where the 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.

Command-line Utility: pg_dump

Backs up a database on a remote PostgreSQL server. Creates a binary dump file, which is more efficient for large databases and supports parallel restoration with pg_restore. Ensure that the remote server allows connections from your machine. This pipes the pg_dump output to gzip for compression, saving disk space. To restore, you'll need to unzip the file first.

See pg_dump documentation

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

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

  • -Fc: Specifies the custom format.