The ZKAPAuthorizer internal database contains information of some value and should be amenable to backup/recovery

If a third-party backs up the ZKAPAuthorizer database and later restores it as part of an overall failure recovery process, some of the ZKAPs in the database may already have been spent. If they are left in place, ZKAPAuthorizer will slowly churn through them and eventually get to some unspent ZKAPs and everything will proceed as normal.

Depending on various factors (not least of which is how stale the backup is), it seems possible this churn phase could take a long, long time (a day seems likely in some plausible scenarios). There is also no way to indicate progress towards completion during this churn since the thing ZKAPAuthorizer specifically does not know is how many ZKAPs were already spent.

Beyond ZKAPs, there is other significant state in the database that changes from time to time. There are vouchers in various states and there are records of ZKAPs that couldn't be spent for some reason (along with a record of that reason). All of this stuff should, ideally, be recorded in a backup so it is available after recovery.