Skip to main content

Configuring Blob Stores

The files of a repository are stored in blob stores. Review the Storage Guide and Storage Planning for information on blob store types and planning storage requirements.

Best Practice

We recommend that you map your blob stores outside the $data-dir directory and set the read/write to be accessible by the server. This separates the repository content from your Nexus Repository instance files making the process of backing up easier to manage.

Blob Store Display

The nx-all or nx-blobstore privileges are required to access this configuration in the Nexus Repository.

Click on a specific row to see the Path to the file system storage (for file system blob stores) and the Soft Quota of the selected blob store.

The following fields appear in the blob store display:

  • Name

    The blob store's name is displayed in repository administration.

  • Path

    The location where the blob store is located.

  • Type

    The type of the blob store backend. The following options are available:

  • State

    The health status of the blob store.

    Started - indicates the blob store is running as expected.

    Failed - indicates a configuration issue and, as a consequence, the blob store failed to initialize.

  • Blob Count

    The number of blobs or files currently stored in a blob store.

  • Total Size

    For most blob stores, this is the approximate amount of space of the disk used in bytes. For object storage, this number does not include blobs marked for expiration but not yet removed.

  • Available Space

    A blob store's remaining storage capacity.

Creating a New Blob Store

Configure a new blob store by navigating to Administration→ Repository→ Blob Stores in Nexus Repository. You may not modify an existing blobstore except to modify the soft quota. You cannot delete a blob store in use by a repository or group.

  1. Select the Create Blob Store button.

  2. Select the Type from the drop-down.

  3. Provide a Name for your blob store.

  4. For file system blob stores, input the Path to the desired file system location. For cloud blob stores, see the S3, Azure, or Google Cloud blob store topics for full details on available fields.

  5. Set the Soft Quota when required; see the soft quota section below for details about this configuration.

  6. Select Save.

Soft Quota

Use soft quotas to monitor a blob store and alert when the storage space exceeds the set limit. Running out of storage space may end up corrupting blobs as they are being saved. Soft quotas do not block read or write operations on the blob store. Limits are set in Megabytes (MB).

There are 2 constraint types to choose from:

  • Space Used

    Issues an alert when a blob store exceeds your quota limit for total bytes used.

  • Space Remaining

    Issues an alert when the space available for new blobs drops below your quota limit.

Soft quota violations are available in the following locations:

  • A WARN message is entered in the logs.

  • Under Administration → Support → Status, soft quotas' statuses are aggregated in the Blob Stores status.

  • A REST API endpoint.

Blob Store Types

The following sections cover specific information for each supported file system or blob store type.

File-Based Blob Store

The path to the blob store must be fully accessible by the operating system user account that is running Nexus Repository.

NFS v4 File System

Versions of NFS older than v4 are not supported.

The recommended settings for an NFS v4 server in /etc/exports are as follows:

/srv/blobstores 10.0.0.0/8(rw,no_subtree_check)

The recommended settings for mounting the NFS filesystem on the node:

defaults,noatime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,vers=4.1

AWS Elastic File System (EFS)

EFS acts as a limitless NFS v4 server and is an option when Nexus Repository is running in AWS. Mount the EFS volume with the same settings as NFS v4.

EFS performance is lower than a dedicated NFS server.

Cloud-Based Object Blob Store

Only using cloud-based object stores when running Nexus Repository in that environment. Trying to use an object store when not in the cloud environment will negatively affect performance and corrupt your instance.

Promoting a Blob Store to a Group

To promote a blob store to a group, select the Convert to Group button. This launches the promotion process to add your blob store to a group for more flexibility. Follow the on-screen prompts to create the blob store group, which will contain the previously concrete blob store and to which you can add other blob stores.

You cannot undo promoting a blob store to a group.

What is a Fill Policy?

When configuring a blob store group, you will be asked to select a fill policy (i.e., the write policy). A fill policy is a method that the blob store group uses to choose a member for writing blobs. You can change the fill policy at any time.

Available fill policy choices include the following:

  • Round Robin - Incoming writes alternate between all blob stores in the group. This is useful when you have several blob stores available and you want each of them to receive a roughly equal number of writes. This does not balance based on any metric.

  • Write to First - All incoming writes are given to the first writeable blob store (skipping blob stores in a read-only state). If you need to direct all blobs to a specific blob store (e.g., you have a blob store for a new empty disk), then this fill policy will ensure that the new blob store gets all the writes.

Removing a Blob Store from a Group

Use the task, Admin - Remove a member from a blob store group, to remove a blob store from a group. While you may add members to the group dynamically, removing a blob store requires a task to ensure that repositories still have access to their artifacts. The task moves components stored there to other blob stores in the group.

Splitting Blob Stores

File-based blob stores may begin to exceed the available space when many large repositories are configured to use the same storage. In this case, you want to split the blob store by moving repositories to another storage location as a new blob store. This is done using a change repository blob store task.

Review the documentation to learn more about the change repository blob store task.

Moving a Blob Store

The path of a blob store cannot be modified after it has been created. The recommended method to move the blob store to a new location is to create a new blobstore pointing to the new destination and use a task to transfer the components to it over time.

Use the following steps to move a blob store to a new location:

  1. Backed up your blob store.

  2. Create a new blob store with the storage path set to the new location.

  3. Promote the original blob store to a blob store group. This is not the newly created one.

  4. Set the group's fill policy to Write to First

  5. Add the new blob store created in Step 2 to the group blob store underneath the original blob store

  6. Schedule and run the following task to remove the original blob store from the group

    Admin - Remove a member from the blob store group

  7. The contents from the original blob store are moved to the new blob store before the original blob store is removed from the group

Migrating Blobs to the Cloud Using Vendor Tools

We recommend using your cloud vendor's tools to migrate to a cloud blob store. Often these tools provide faster and more cost-effective methods for migrating large amounts of data quickly. Consult your cloud vendor representative for guidance when migrating multiple terabytes of content to avoid prolonged downtime and high costs.

Back up your blob store before proceeding with any migration.

Updating the Database Configuration

After using vendor-specific tools, you must update the blob store configuration in your database to match the new type of blob store and its new location.

  1. Create the new blob store in your Sonatype Nexus Repository instance.

  2. Shut down your Nexus Repository instance

  3. Run a SQL query like the following:

    delete from blob_store_configuration where name = '<blob store name>'; -- the name of the blob store which was moved to S3/Azure

-- update the reference to the new S3 blob store
update blob_store_configuration
set name = '<blob store name>'
where type = '<S3 or Azure Cloud Storage or Google Cloud Storage>'
and name = '<name of the new blob store>';

  4. Re-start your Nexus Repository instance.

  • Amazon Web Services (AWS)

    AWS DataSync is an online data transfer and discovery service that simplifies data migration and helps you quickly, easily, and securely transfer your file or object data to, from, and between AWS storage services.

    See the AWS DataSync documentation for details.

  • Google Cloud Platform

    Storage Transfer Service automates the transfer of data to, from, and between object and file storage systems, including Google Cloud Storage, Amazon S3, Azure Storage, on-premises data, and more. It can be used to transfer large amounts of data quickly and reliably, without the need to write any code.

    See the Google storage transfer service documentation for details.

  • Microsoft Azure

    AzCopy is a command-line utility that you can use to copy blobs or files to or from a storage account.

    See the AzCopy documentation for details.

    The following is a brief overview:

    1. Create an Azure storage container with the name default

    2. Generate a SAS token for the container with the following permissions:

      Read, Write, List, Delete

    3. Install AzCopy

    4. Construct and execute the AzCopy command:

      azcopy copy "/nexus/sonatype-work/nexus3/blobs/default/*" "https://<your_account_name>.blob.core.windows.net/default?<your_sas_token>" --recursive=true

      Replace the placeholders with your details.

    5. Use the list command to verify that the copied files exist in your Azure storage container