CODEWITHSUNDEEP
artifactory
Ivan Ermilov
Ivan Ermilov

Reputation: 1829

JFrog Artifactory system restore failing

In our organization we are running Artifactory Pro edition with daily exports of data to NAS drive (full system export). Every night it is running for around 4 hours and write that "system export was successful". The time has come to migrate our instance to PostgreSQL based (running on derby now). I have read that you need to do it with the full system import.

Few numbers:

If you also were pondering why export data volume is more than 2 times bigger than disk space usage, our guess is that docker images are deduplicated (per layer) when stored in the docker registry, but on export the deduplication is not there.

Also, I had success migrating the instance by rsync'ing the data over to another server and then starting exactly the same setup there. Worked just fine.

When starting exactly the same setup on another machine (clean install) and running system import, it fails with the following log: 

[/data/artifactory/logs/artifactory.log] -   "errors" : [ {
[/data/artifactory/logs/artifactory.log] -     "code" : "INTERNAL_SERVER_ERROR",
[/data/artifactory/logs/artifactory.log] -     "message" : "Unable to import access server",
[/data/artifactory/logs/artifactory.log] -     "detail" : "File '/root/.jfrog-access/etc/access.bootstrap.json' does not exist"
[/data/artifactory/logs/artifactory.log] -   } ]
[/data/artifactory/logs/artifactory.log] - }

Full log is here: https://pastebin.com/ANZBiwHC

The /root/.jfrog-access directory is Access home directory (Access uses derby as well).

What am I missing here?

Upvotes: 2

Views: 1194

Answers (1)

Ivan Ermilov
Ivan Ermilov

Reputation: 1829

There are couple of things we were doing wrong according to the Artifactory documentation:

  • Export is not a proper way to backup big instance. In case of running Artifactory with derby, it is sufficient to rsync filestore and derby directories to NAS.
  • Incremental export over several versions of Artifactory is NOT supported. Meaning, that if you had full export on version 4.x.x, then you upgraded over to version 5.x.x, then to version 6.x.x and you had incremental exports along the way... Then your export will NOT be imported into version 6.x.x. After each version upgrade it is necessary to create new full export of the instance.

I resolved the situation by removing the export and doing full system export (around 30 hours). Full system export was successfully imported on another instance (around 12 hours).

P.S. The error is still cryptic to me.

Upvotes: 1

Related Questions