Chirpstack Backup and Restore - Activation information gone

Hi,

I use the Chirpstack dockerized.
To move to another server, I backed up the related PostgreSQL database via pg_dump and copied the redis dump.rdb file.
After restoring to a new system, the devices are not activated anymore in the interface, and I get a device-session error: object does not exist from the Chirpstack Network Server.
This issue is described in the following link, and it is pointed out that redis should be configured with appendonly yes to avoid this:

I did not configure redis with appendonly yes, and so I wonder if it is possible to resolve this issue without restarting the LoRa devices?

Many thanks!

I think the only way is to reboot the nodes.
Newer LoRaWAN nodes have the ability to reboot the nodes after some time.

Does someone know why RDB file backup is not sufficient? I don’t understand why we should activate AOF in our case…

I don’t understand why RDB backup fails. Each time you restart your server, the RDB file is read to retrieve the session keys. Did you try to parse the file (GitHub - sripathikrishnan/redis-rdb-tools: Parse Redis dump.rdb files, Analyze Memory, and Export Data to JSON)? This could help you to retrieve and inject the keys manually in your new instance.

Another guess: 90% of linux problems are access right problems… Are you sure that your Redis instance can read the RDB file you copied?

1 Like

Many thanks for your help!

I realized that when restarting the redis container the dump.rdb file got reset.
After adding command: ["redis-server", "--appendonly", "no"] to my docker-compose file, I could restart the container without resetting dump.rdb. Then I removed the line again.

So it seems that copying dump.rdb from a redis docker container suffices as a backup.

1 Like

I feel better :sweat_smile:

I think AOF, if wrongly configured (for instance not set from the beginning), could potentially conflicty with RDB, because it will try to rebuild the cache from a different starting point.

1 Like

I know this has already been answered/figured out below, but I wanted to reiterate that this is definitely not necessary. I’m not a fan of AOF and have had no issues running Redis with:

redis-server --save 300 1 --save 60 100 --appendonly no

Save rate depends on your use case, obviously.

1 Like