How to restore a deleted component in Sonatype Nexus 3

Question

In Nexus Repository Manager 2 you could move deleted assets/components on the server from the .trash-folder to repository to restore anything you might have deleted. This is because Nexus stored Components as individual files on disk.

Sonatype Nexus 3 stores Components as blobs. My guess would be that with Nexus 3 the deletion marks the component as deleted in some column in the database. Is the solution to connect to the database with Sonatype provided instructions and manipulate the database data?

Sonatype support in this case has this information: https://support.sonatype.com/hc/en-us/articles/115002930827-Accessing-the-OrientDB-Console

In short connect with:

Unix

java -jar ./lib/support/nexus-orient-console.jar

Windows

java -jar lib\support\nexus-orient-console.jar

Mac

.install4j/jre.bundle/Contents/Home/jre/bin/java -jar ./lib/support/nexus-orient-console.jar

Exit console:

exit

The Nexus Repository Manager I'm using is version 3.2.0-01 and the nexus-orient-console.jar is in that release too.

Cabinda

Answer 1

If you want to restore a soft deleted repository and blobs, the solution is to create the blob store with the original name and also create the same name of the repository. Then run the "repair - reconcile component database from blob store" task.

Note: you can change the blob store name and the repository as well. In the blob replace all properties files with new repo name.

This method is applicable for moving blob store and repo to other nexus server.

Levant

the question was how to restore a deleted component. I'm not really interested in restoring a whole repository and the associated blob store. – Cabinda

Answer 2

In theory, this could help: https://community.sonatype.com/t/how-to-undo-asset-soft-delete-in-nxrm3/271/9

Disclaimer… the following instructions use an implementation detail of the current blob store. As such, they are not officially supported, and they won’t work if the implementation changes.

Associated with each blob in the blob store there is a properties file. So for instance A particular blob file will consist of two files:

fac5e64d-831b-4b58-98c9-3dd0e4bd1b59.bytes fac5e64d-831b-4b58-98c9-3dd0e4bd1b59.properties

Within the properties files you’ll see content like this:

#2018-08-22 08:33:33,965-0500
#Wed Aug 22 08:33:33 CDT 2018
@BlobStore.created-by=admin
size=40
@Bucket.repo-name=maven-releases
creationTime=1534944813965
@BlobStore.created-by-ip=127.0.0.1
@BlobStore.content-type=text/plain
@BlobStore.blob-name=org/foo/bar/project/1.2.3/project-1.2.3.jar
sha1=30d7edff3bc3f5e601be9529460b7bd573b1a8b7
deleted=true

The “@Bucket.repo-name” property shows which repository the blob is associated with. The “deleted=true” indicates the blob is in soft deleted state.

To restore the soft deleted file, locate the properties file and remove the

deleted=true

line. Then schedule and run a “repair: reconcile component database from blobstore” task.

There are some limitations associated with the reconcile task

Interfluve

Answer 3

This is going to be very difficult to do. Records are created in a few different tables, along with hashes and attributes. I would advise against what you are trying to do, as it could get messy. If you WERE to do this, you would want to take a look at how records are created in the component and asset tables, and recreate that best you can (if even possible).

I would however like to know more about your use case. It sounds like what you'd desire is a bit of a "trash can" in Nexus Repository so that you can restore deleted items. If you could explain why, that would be helpful.

Fordham

Thanks. The majority of deletions in my case are done with Tasks. There's a possibility that a released component would have a snapshot dependency that suddenly is deleted when running the cleanup tasks on snapshot repositories. There was also the unfortunate "I deleted a wrong release" situation with Nexus2 that was easily corrected with moving the arfifact from the .trash folder to it's previous repository. – Cabinda

I dont know how common this problem is but it would surely help me maintaining the repositories and keeping the disk usage in check. On a side note, I wish the deletion tasks would log the deleted components not just the number of deletions. Indeed, I would love a "trash can" type feature where I could see the to-be-permanently-deleted-components before I run the compact blob store -task. From this "trash can" I could possibly restore components. – Cabinda

Thanks for the explanations, I've sent this to a few people internally to look at. – Fordham

We are interested in this as well. Will it be put on the feature list of Sonatype Nexus OSS 3.x? – Balsam