nexus-public
nexus-public copied to clipboard
Nexus - backup
hi,
This is a request for confirmation regarding the Nexus backup mechanism.
At our company we are reviewing our backup process for Nexus and we would like confirmation from your side regarding the process that we are setting up.
So, our Nexus is running on 'Linux RHEL' (VM ware) which has Legato software installed that takes a daily backup of the full Nexus installation. This version is kept for 2 weeks, so in Legato we can select few version to rollback to in case of disaster. I guess this complete backup of Nexus should do fine in case of restore, or do you see any issues/concerns? Once Nexus would be recovered from backup, are there any actions to be taken to sync the blobs with the databases?
Hi @loeki-loek thanks for opening an issue. Backup and restore for Nexus Repository is a little trickier than just traditional backup, as you have both a database and a storage system to keep in sync. Options for backup and recovery are covered in detail on our help site. Take a look at our Deployment Pattern Library - it has a list of composable patterns you can use to plan. Pro customers can engage with our support and Customer Success groups for additional consultation.
hi,
Yes, we are investigating on that part as well and see what our company solutions can offer. Coming back to the backup part, need to mention that we are using orientdb. So, in your opinion, when we have the full back and would need to restore due to e.g. data corruption, is having a full back up of the filesystem good enough? And do we need to run any additional tasks, like reconcile or..?
Hi @loeki-loek - the details and specifics matter. It's hard to tell what you mean by "a full back up of the filesystem," so it's challenging to provide precise guidance. There are two key things you will need in a restore event - a consistent point-in-time snapshot of the database (found in the sonatype-work/nexus3/db folder) and an equally consistent, matching point-in-time snapshot of any and all blobstore locations (the default is a File blobstore under sonatype-work/nexus3/blobs/default, but these can - and typically should be - in other locations, including NFS partitions, or S3 buckets using the S3 blobstore type). If you take a disk-like snapshot of the former using an external tool, it's not guaranteed to be consistent. We find in practice OrientDB isn't in a stable enough state at arbitrary times. The backup task is intended to get a consistent export of OrientDB. The next challenge is getting a backup of the latter - all of the separate blobstore locations. These are well suited for traditional disk-like backup tools; the challenge here becomes correctly getting a snapshot that's close enough to be consistent with your database backup. Getting close is fine, and resolving any differences is possible with the Repair - Reconcile component database from blob store task. Note that task does have limitations on the maximum number of days it can work back from, as well as limits on formats.