Using Replicated S3 Blob Stores for Recovery or Testing

Should you need to use a replica of a production S3 blob store for recovery or testing purposes, you will also need a copy of the Nexus Respository database that corresponds to the blob store. This database will contain references to the production blob store. Using the database copy unmodified will result in unintended modifications to the production S3 blob store. For this reason, Nexus Repository provides a mechanism to override specific blob store attributes via an environment variable (NEXUS_BLOB_STORE_OVERRIDE) used during Nexus Repository startup. Using this mechanism, you can override the S3 blob store bucket name attribute to point to the replica to avoid unintended modification of the production blob store.

For example, suppose you have a production S3 blob store named nxrm-blob-store that is associated with an S3 bucket named nxrm-bucket-prod. You have set up replication of this bucket to another bucket named nxrm-bucket-stage for testing purposes. In the testing environment, you can restore a backup or snapshot of the production Nexus Repository database and use the following environment variable when starting Nexus Repository to update the S3 blob store bucket name in the staging environment to point to nxrm-bucket-stage instead of nxrm-bucket-prod:

NEXUS_BLOB_STORE_OVERRIDE='{"nxrm-blob-store": {"s3": {"bucket": "nxrm-bucket-stage"}}}'

The NEXUS_BLOB_STORE_OVERRIDE environment variable is expected to contain a JSON representation of a map for which the key is the name of the blob store you are modifying. The value is another map with the same structure as the blob store attributes in the Nexus Repository database. In the case of an S3 blob store, the attributes map key is expected to be "s3" and the value associated with that key is a map of attributes that you wish to override (in our example, it would be "bucket").

Nexus Repository will only attempt blob store overrides where the blob store name in the environment variable matches an existing blob store in the Nexus Repository database. When there is a matching blob store name, Nexus Repository will only make a modification when the attribute value provided is different than the existing value in the Nexus Repository database.

It is important to note that the blob store override environment variable only changes blob store configuration in the Nexus Repository database and does not modify the referenced underlying blob store in any way. It is up to you to ensure that the new S3 bucket in this case contains blob store files that correspond to the Nexus Repository database being used (in this case, a replica of the production S3 bucket). The blob store override environment variable will not do any sort of copying of information from the existing production S3 bucket to the staging S3 bucket.

You can use NEXUS_BLOB_STORE_OVERRIDE to modified several blob stores:

NEXUS_BLOB_STORE_OVERRIDE='{"blob-store-1": {"s3": {...}}, "blob-store-2": {"s3": {...}}, "blob-store-3": {"s3": {...}}}'

You can also modify several attributes for each blob store:

NEXUS_BLOB_STORE_OVERRIDE='{"nxrm-blob-store": {"s3": {"bucket": "nxrm-bucket-stage", "region": "us-east-2"}}}'

The attributes available for override are any attributes that are defined for the blob store configuration in the Nexus Repository database. For S3 blob stores, the most common attributes are as follows: