Recommended upgrade-strategy for containerized firod

Need Help
1

Hi!

I’ve been using a docker image from Docker Hub running 0.14.5.2 or 0.14.5.3 with a balance >0.
now that 0.14.6.0 has gone live i wonder what the best approach would be in order to upgrade my docker instance without loosing my balance/addresses/history.

after taking a brief look at the dockerfile it seems like a volume is defined for “/home/firod/.firo” so i could tar-backup its contents through e.g.

$ mkdir ~/mybackups
$ docker run --rm --volumes-from firod -v ~/mybackups:/backup debian:stretch
$ bash -c "cd /home/firod/ && tar -cvjf /backup/210426_firod.tar.bz2 ./.firo && md5sum /backup/210426_firod.tar.bz2 > /backup/210426_firod.tar.bz2.md5"

plus get the current instances volume path through $ docker inspect <ContainerID> | jq --raw-output .[].Mounts.

After that I assume I should be ok to issue
$ docker rm firod && docker pull firoorg/firod
followed by
$ docker run --detach -v /path/to/former-firod-volume:/home/firod/.firo --name firod firoorg/firod
to start my updated firod instance.

Does this workflow seem legit or are any further migration-scripts needed during the upgrade process?

Many thanks in advance for your advice on this! <3

1 Like
2

hmmm… looking at my actual instance I find that:

  • /home/firod/.firo/blocks contains a lot of data (~ 50GiB)
  • /home/firod/.firo/wallet.dat might be enough to back up?
  • inspection reveals NO volume and NO mounts :face_with_raised_eyebrow:

especially my last point makes me wonder if the volume directive for /home/firod/.firo in dockerfile is not doing what i thought it would so?!?

the resulting .json when calling inspect firod shows (among many other lines):

  • "Mounts": [],
  • "Volumes": null,

can anybody confirm this so far?

does this mean that the synced blockchain data as well as my wallet.dat will be lost if i didn’t backup them before executing $ docker rm firod ??? to it looks like this would be the case :grimacing: but as i’m no expert in containerization i’d like to ask for a second/third opinion please…

1 Like
3

I’ll get someone in here to assist.

1 Like
4

appreciated!

in the meantime i learned that it’d be way simpler to use
docker cp firod:/home/firod/.firo/blocks /mybackup/ (to hopefully save myself from a full resync) and
docker cp firod:/home/firod/.firo/wallet.dat /mybackup/ and
that the db doesnt compress well, so zstd would be a better choice in regards to time/effort ratio (but would require a second step).

should i then be able to just copy my wallet.dat and the blocks folder back into the new/updated container in the same manner?

1 Like
5

after trying around further it appeared that copying back wallet.dat into an updated container is fine but i could not figure a way to re-use (copy back) the folder /home/firod/.firo/blocks without breaking the container.

so do i really have to perfom a complete chain-sync after each version update?!?
guess i’m missing something here and i’d really like to know how to get this working without downloading the entire chain again and again…

6

Depending on the entrypoint of your container, you could try entering an interactive session to the container, shutting down firod, then exporting the filesystem using docker export. You can then untar /home/firod/.firo somewhere else, then map that new directory to a new container run. Be careful and save the wallet.dat first (using docker cp, which it seems you’ve already done).

You have to be careful with docker containers and making sure your mappings are setup and working.

7

Thanks for your hints!
I’m using the official (?) container offered through Docker Hub and I was assuming its using the github-repositories dockerfile which defines ENTRYPOINT [ "/usr/bin/firod" ] .
I’m still uncertain how I would do what you suggest as I think there is no way of entering an interactive session of an existing container in which i can shutdown firod.
Would you mind giving some examples? My setup pretty much sticks to what is described here.

9

Oh Yikes! Yeah, you can’t shutdown firod, the whole container will die.
Backing up the wallet.dat is pretty much your only hope, although you should still try docker export, hopefully it can recover on next startup when you map the directories properly.
What I recommend doing is: docker exec firod firo-cli backupwallet “/home/firod/.firo/backup-wallet.dat”
Then: docker cp firod:/home/firod/.firo/backup-wallet.dat .

This way there’s no chance the wallet is damaged because you’re copying an open file, if you just copy the wallet.dat (you should copy it anyway just in case).

Then do the docker export if you want to save the blockchain.

Make sure that next time you run the firod container you map your local directory where you saved your wallet.dat and blockchain over to /home/firod/.firo/ with -v. I’m actually surprised that’s not in the docs. Easily remedied though. :wink:

10

I just played around with the container. If your user name is “antip”, you should run the container like this (I’m on WSL2):
mkdir ~/.firo
docker run --detach --name firod -v /home/antip/.firo:/home/firod/.firo firoorg/firod
On windows you can do (drop into powershell or cmd):
mkdir firodocker
docker run --detach --name firod -v C:\Users\antip\firodocker:/home/firod/.firo firoorg/firod

Tested it both ways… seems to work, and should make upgrades easier.

11

The volume tag has been added to the Docker documentation.

Credit to @norsegaud