Re-Setup Open Balena Server and not loose devices

We are planning on using openBalena for our iot project. It’s a great tool !

We still have a few questions on our mind:

  • Let’s say we have a rare case where we are forced to completely re-setup the open balena server. What are the necessary steps we should do before so we do not loose all devices in the field ?

Thanks !

Hey there! I’d like to confirm with the openBalena maintainers, but I believe backing up the database and the environment settings (such as CA certificates, etc) should be enough.

Hello,

Currently we don’t have a procedure in place to migrate an entire openBalena installation into another instance of openBalena. Each service holds it’s data on volumes that could be migrated, but it’s not something that has been tested so we do not have an official or recommended approach.
If you want to avoid losing devices in the field when switching server, there is a way of doing so, albeit not very streamlined. You can use the balena-cli join command which basically enables you to move a local device to an application on another balena server. This will however wipe your device, both the images deployed to it and the data will be lost.

Forgot to add a link to our docs regarding the join command:
https://www.balena.io/docs/reference/cli/#join-deviceip

Keeping around the config directory and the Docker volumes should be enough to spin up an identical server again.

I actually have this same thought, but the answers here are confusing.

Is it postgres+certificate or postgres+certificates+volumes?

I’d like to know the minimal files to backup to regain the access to fleet.

I don’t care about the volumes if they are not required to regain the acccess to fleets. I can just push a new image in case the openBalena fails.

You need all 3; the database contains referenced to the images in the registry, which is held in the volume.

1 Like

Thanks for all answers !
Currently we have everyting setup in containers (virtual machines, vm) . Since everything openBalena related would be inside this vm , i guess it would enough to just backup the whole container in its current state.

I agree with backing up the container, but recently had to deal with a stubborn kernel panic and a too-old volume back-up. The following allowed a full recovery of OpenBalena devices from a non-booting volume (mounted at /mnt) to a replacement instance:

  1. Installation (a few node/ssl dependencies had changed from the official instructions)
sudo -i
apt-get install -y build-essential git docker.io libssl1.0-dev nodejs npm node-gyp nodejs-dev
curl -L https://github.com/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
adduser balena
usermod -aG sudo balena
usermod -aG docker balena
  1. The following transfers the installation including the certificates:
sudo cp -r /mnt/home/balena/* /home/balena/
sudo chown -R balena:balena /home/balena/
  1. To transfer the Docker directory containing all volumes and resources, copy /var/lib/docker while the docker service is not running. The transfer can still work if it is running during the copy, but the newly transferred volumes and other Docker data will not be shown in the CLI until it is stopped and started again.
systemctl stop docker
sudo cp -r /mnt/var/lib/docker* /var/lib/docker
systemctl start docker
  1. Launched: /home/balena/open-balena/scripts/compose up -d

  2. Set up to launch on boot:

crontab -e # Edit periodic scripts; add:

@reboot /home/balena/open-balena/scripts/compose up -d
# Write file and exit