Hi There!
I have a working set up based on CS 4.0 on a raspberry PI and I want to migrate it all to a cloud server I have already contracted.
I already have 3 clients, several devices and some uplink and downlink integrations, so I would prefer to migrate, if possible, the whole setup, to avoid any risk of leaving anything behind.
Is there a way to migrate a tull set up?
Thanks
The only two things that need a backup and restore to copy a server is the redis and postgresql databases. You can likely get away with only doing the postgresql backup as redis is mostly for runtime but for safe measures you should do both. For redis you only need to copy the dump file over to your new server. For postgresql there are many ways to do a backup and all of them are documented well but the easiest is just to do a pg_dump to create a file with all the commands necessary to rebuild the database.
Here’s a writeup I made a while ago for backups. I am using docker install on a ubuntu system so the file locations will be different but it will give you an idea:
Backup Process
0) ssh to machine and enter the chirpstack-docker folder
$ ssh <user>@<chirpstack-server>
$ cd chirpstack-docker
1) Ensure Docker is down so no containers try to write while backup occurs.
$ sudo docker compose down
2) Copy redis data dump
$ sudo cp /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb redisbackup.rdb
3) Create a file for psql backup dump
$ touch postgresbackup
4) Start only the postgres container
$ sudo docker compose up postgres -d
5) Exec into the postgres container and use pg_dumpall to create a backup file
$ sudo docker exec -it chirpstack-docker-postgres-1 pg_dumpall -c --no-password -h localhost -U postgres > postgresbackup
Restoral process
0) ssh to machine and enter chirpstack-docker folder
$ ssh <user>@<chirpstack-server>
$ cd chirpstack-docker
1) Ensure Docker is down so no containers try to write while backup occurs.
$ sudo docker compose down
2) Make a copy of current redis database (As a safe measure)
$ sudo cp /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb redisdatareplaced.rdb
3) Delete old data dump and copy backup into volume
$ sudo rm /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb
$ sudo cp redisbackup.rdb /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb
4) Change permissions of new dump file
$ sudo chown lxd:<user> /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb
$ sudo chmod 600 /var/lib/docker/volumes/chirpstack-docker_redisdata/_data/dump.rdb
5) Start only postgres containers
$ sudo docker compose up postgres -d
6) Rebuild SQL database from backup
$ sudo docker compose exec -T postgres psql -h localhost -U postgres < postgresbackup
After doing this a default Chirpstack setup should mirror your old server datawise, but the configuration will still be up to you to match (regions, mqtt listener settings, certificates, etc…).
Very very useful information! So basically Chirpstack consist on inmutable files + ram redis DB + postgres DB.
I had never heard of redis db before but while reading now about it I can see it holds volatile data in RAM memory, does this mean if I skip the redis DB I would only lose the last data received? Cause all I need to preserve is devices with their activated keys, profiles and payload decoders, and integrations. Also gateways
My install is not on docker but direct apt install (Debian / Ubuntu - ChirpStack open-source LoRaWAN® Network Server documentation)
When you say it would show up like a clean install you mean I would still have to set up language, preferences, etc, but defices, gteways, profiles etc wouls all be there right?
Thanks!
No, any data received will be automatically logged into postgresql, you should lose no data doing only the postgresql backup unless you are receiving the uplink while backing up.
All that will be saved with just the postgresql backup. Except any integrations you have enabled in the Chirpstack.toml (global integrations) I believe any integrations enabled through the UI should be kept (although I have never tested this myself).
I’ve never changed the language so I’m not sure where that is stored, if it is in the Chirpstack.toml or other configuration file it will not be saved, if it is something that was done through the UI then it will be saved (I believe all UI interactions only change the postgres/redis databases not the config files but I cannot confirm that). All of the important info you are concerned about though will be kept.
I’m not sure what all is stored in redis these days, the device session keys themselves were stored in redis before v4.7 so that why the backup used to be important although these days you can do just the backup of the postgres without any issues (although redis literally is copy/paste a single file so there’s not much reason to skip it).
Ok I guess that to be safe I will take the redis backup as well.
No, I’m not aware of having done any customization thru the toml file, I think everything was set up on the UI.
Also my install is I believe 4.6, and I see that latest download is 4.10. so if I follow the apt install procedure on the new server, I guess I will get v 4.10 installed, will all the migrated databases data be compatible between 4.6 and 4.10 versions of CS?
Thanks again!
They will not be, I would go through the update process on your current host first before doing the backup restore. The main reason for that is the device session keys got moved from redis to postgresql in 4.7 and there is a command you have to run to move them after the update: [release] ChirpStack v4.7.
I believe you could do it the other way around (backup / restore and then run the migration command on your new server) but less likely to run into issues to update your current server, run the migration command, and then backup / restore if you can do that.
Alright. Is the upgrade (4.6->4.10) process 100% risk free? I have one specific client having one water pump commanded by one distance sensor at a tank using a downlink to a lt22222 and if this fails…the town runs out of water…
Also this uses an API key that cannot be lost as the downlink uses the key and also the key as you know cannot be pulled out or set to a specific value again
Thanks a lot for your time!
Theoretically yes, although I have seen people have issues with the migration command on the forums before so if it is absolutely critical you might want to leave your current server as is for now.
Seems like a shocking thing to leave to a single point of failure, especially something as innately lossy as LoRaWAN but it’s cool that you are providing such important services.
Since this is the case I’d recommend doing the reverse approach: create your new server on version 4.10, perform the backup/restore, then do the redis → psql migration command. Then only when you have verified everything on the new server lines up: the keys are all there in the devices activation tabs, the api keys still work, then you can direct your gateways to the new server. Even if this fails at least you don’t screw up production.
1 Like
Ok, sounds good Liam.
I’ve learnt a lot today.
I truly appreciate your time with this topic!!
Have a good day!
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.