Storage Management Best Practices: Part 1 - Components In Motion

August 20, 2020 By Brent Kostak

3 minute read time

New in Nexus Repository 3.26, users now have an effective way to migrate components between two or more Nexus Repository instances with the Import/Export feature. This latest release delivers Nexus Repository Import and Export tasks with full support of all eight formats (Raw, Maven, NuGet, npm, Rubygems, Yum, Docker, and PyPI). Import/Export is available for Nexus Repository Pro users.

Storage management in Nexus Repository Manager is an important topic when scaling development throughput for any organization or team. How specific software components take up storage space, physical relocation of these components within Nexus Repository Manager, and understanding best practices for optimizing available storage once components are no longer needed are the three main areas of operations for running an efficient, scalable repository. 

This is the first part of a new guided “Storage Management Best Practices” series. Diving deeper into Import/Export capabilities, we will be focusing on relocation and moving components within Nexus Repository Manager in this publication. 

Modern Supply Chains and Repository Management

Organizations are working hard to keep up with faster rates of component creation from CI/CD and increased sizes of components from the shift in containerized deployments (e.g. multiple GB of new docker components being created every day). Managing repository content at the blob store level is important for storage, but what about the ability to move repository components between Nexus Repository Manager instances? These new supply chain trends leading to increased throughput of repository content makes it critical for teams to understand how to keep their repository components organized. Especially, when organizations have several different repository manager instances in several different business units/departments. 

Listed below are the three main use cases for Nexus Repository Pro customers when moving components using Import/Export:

  • Self-paced Migration from NXRM 2 to 3: Import NXRM 2 content from the file system directly to their NXRM 3 instance operating concurrently. This solves the issue of customers needing to decommission their NXRM 2 instances while not being able to use the in-place upgrade option.

  • Consolidation of NXRM 3 Repositories or Instances: Consolidate the number of repositories or the number of NXRM 3 instances. Scenarios this use case can address include:
    • Moving components from a slower instance to a faster instance
    • Moving components closer to an instance of a newly formed development team
    • Moving components from on-prem instance to a cloud-hosted instance

  • Distribution of Components to Disconnected Instances: Distribute components between disconnected or remote environments. Scenarios this use case can address include:
    • Airgapped/disconnected environments that have very high-security protection and do not have any network connectivity to what is normally available. 
    • Remote field environments that do not have a good and reliable internet connection. (e.g. offshore industrial locations, or remote research facilities)


Benefits of using Import/Export with Nexus Repository Pro

The advantages of learning best practices for moving components with Nexus Repository Manager are the direct outcomes teams gain by using both the Import and Export scheduled tasks. Below is a chart highlighting customer benefits:

Additional Resources

For further Nexus release details and any questions you may have, please refer to the links below:

Nexus community, support, and quick-start guides at

Tags: Nexus Repository, Product

Written by Brent Kostak

Brent is the Director of Product Marketing connecting developers and DevOps communities to Sonatype Nexus tools and technologies.