Issues with Deleting AstDB During Asterisk Upgrade

Hello everyone,

I’m in the process of upgrading my Asterisk system, and I’ve come across a concern regarding the internal Asterisk database (astdb.sqlite3). I understand that this database stores dynamic runtime information like device states, user preferences, and other custom entries.

In my case, a significant issue arises if the astdb is deleted because all custom DEVSTATE entries are lost, and I have to re-enter them manually. This is especially problematic in environments like mine, where many custom device states are critical for daily operations.

Before I proceed with the upgrade, I want to clarify:

  1. Is it necessary to delete or reset the astdb when upgrading Asterisk?
  2. If not, are there any recommended steps to preserve and migrate it safely?
  3. In scenarios where astdb becomes incompatible or corrupted post-upgrade, what’s the best approach to restore custom device states efficiently?

Any insights or best practices for managing astdb during upgrades would be greatly appreciated.

Thanks in advance!

There is no need to delete or set the AstDB when upgrading. The schema has never changed, and even if it did we’d provide a migration mechanism. To that end right now there is no migration required. You leave it alone. Asterisk leaves it alone at startup except for opening it if present, or creating a new one if it doesn’t exist.

As for restoring custom device states, you could use the CLI command to recreate them.

Thank you Jcolp for the clarifcation .
even from 18 to 20 ?

Yes. You could go from Asterisk 10 to 22 and from an AstDB perspective, it would work fine.

thank you really solves me a major problem
I guess there was once a problem with it and still stayed in the script

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.