How to Back up Nexus for Active/Standby Failover

Note:  These instructions are written under the assumption a tool like rsync is being used for replication.  If you are using SAN replication the simplest solution would be to just replicate the entire sonatype-work directory. 

Note 2: These instructions describe all directories present in the Nexus Pro 2.11.x work directory.  If you are using an earlier version, or using Nexus OSS, or not making use of all features in Nexus then some of these may not be present.

Files to Replicate

To set up a standby failover server replicate the following under sonatype-work/nexus to a second (non-running) instance:

  • conf - Contains all of the configuration for Nexus (repositories, ldap setup, configured roles and privileges, etc).
  • db/capabilities/capabilities.h2.db - Present in Nexus 2.8.x only, this stores configuration important information.
  • db/usertoken.h2.db - User access tokens are stored here.  Back this up if you use the Nexus Pro user token feature.
  • db/npm - npm repository metadata is stored here. Back this up if you have any npm type repositories.
  • health-check - Stores repository health check reports
  • logs - In the case of a catastrophic failure the logs may contain valuable diagnostic information.
  • nuget/odata.h2.db - Stores metadata about NuGet repositories, used to provide the NuGet feeds.  Back this up if you use NuGet.
  • plugin-repository - This is where you install Nexus plugins not provided by Sonatype.
  • proxy - Contains meta information about artifacts in storage, such as last access time, who deployed them, etc. (note: if you're on nexus 2.0 or later this folder is deprecated, no need to backup)
  • storage - This contains all artifacts in Nexus, both hosted and artifacts cached through proxy repositories
  • template-store - Customized settings templates are stored here
  • timeline/persist - This is the storage area for system feed events.
  • trash - Temporary storage location for deleted artifacts. Useful if something was deleted by mistake.
  • iq - Contains Nexus Firewall audit information. 

Don't Replicate These Files

There are certain files and directories that should not be replicated to the failover instance.

Search indexes

It is likely that the replication will catch them in an inconsistent state, and this may cause trouble in the failover nexus instance when it starts up:

  • timeline/index - This index will be rebuilt automatically when the failover Nexus is started up
  • indexer - This is the search index, which is used to support searching in the Nexus UI. It is not critical, since Maven builds do not use it.
  • indexer-pro - If you've installed the optional custom metadata plugin then this index will also be present.

Nexus Lock File

  • nexus.lock - This file is present when nexus 2.7+ is running to prevent concurrent use of the work directory

Access Database

  • access/ips.db.h2.db - Records access to Nexus Professional. This does not need to be backed up.

Analytics Database

  • db/analytics/analytics.h2.db - Records non-sensitive analytics usage information.  This does not need to be backed up.

Smart Proxy Message Broker

There is persistent storage for the smart proxy message broker. You should also leave this out, it will get rebuilt on startup of the new instance:

  • broker

Felix OSGI Cache

  • felix-cache - Contains cached information about OSGI plugin bundles. This will be recreated automatically at startup.

 

Activating the Failover Nexus

When you bring up the failover instance you'll want to kick off a repair index task against all repositories so that the search indexes will be rebuilt. This can be done under "administration/scheduled tasks" in the UI.

Note that indexes are not used in Maven builds, they are only needed for supporting search in the UI. So your failover server will work as soon as it comes on line.

Rsync Tips

If you decide to use rsync, then use "rsync -avP <source> <dest>" to do the copy. This can be done while the original Nexus is running. After it completes, shut down Nexus and run "rsync -avP --del <source> <dest>". This will sync up any changes that happened since the first rsync completed.

If your original system has a slow disk you man need to use "ionice -c3 rsync", this will prevent rsync from consuming all disk bandwidth.

Reducing the Backup Size

The size of sonatype-work/nexus/storage can be very large in some instances.  In order to reduce the size of the backup, it is generally OK to limit the backup under this directory to your hosted repositories.   Group repositories do not contain anything that needs backing up in their storage directories, and the contents of proxy repositories will be automatically fetched from their remotes as your builds run.

Have more questions? Submit a request

5 Comments

  • 0
    Avatar
    Alcatel Lucent

    I found out that the passive server won't start if logback*.xml files are kept in the sonatype-work/nexus/conf directory. I had to delete them for the server to start correctly.

    From the wrapper.log :

    java.lang.IllegalStateException: Could not create logback.xml as /opt/sonatype-work/nexus/conf/logback.xml

    [...]

  • 0
    Avatar
    Alcatel Lucent

    Note also that you forgot to mention the directory template-store. :)

    Thank you.

  • 0
    Avatar
    Himanshu Gautam

    Would this still work if someone is using a smart proxy?

  • 0
    Avatar
    Moser

    Are there any differences Nexus 3?

  • 0
    Avatar
    Peter Lynch

    We are closing this article for comments.

    If you have a support license, please contact us by submitting a support ticket.

    If you do not have a support license, please use our Nexus Users List or our other free support resources.

Article is closed for comments.
Powered by Zendesk