Encrypting the database has replies which I’ll pull here, since it’s active now.
I’m hoping some other Canary users can keep this up, as I’ll be away awhile.
It sounds like reinstalls of a system suffer the same trouble as new system or changing user on same system (e.g. migration to Windows service). If option --disable-db-encryption works as simply described in the case I tested, then
is defeated. OTOH if the decrypt is tied to a system which is lost, the DB is lost.
Experiments so far seem to suggest that an export with its own export PW will do. Other encryption passwords are the server DB one and the one for backup data which is in the export. I suppose a redundant copy of that would add some safety, and it’s probably the most critical, even if one has to resort to using RecoveryTool.
Viewing server DB as not a primary source reduces worry about it. It’s not clear if random encryption password can even be obtained, but if one moves onto a new system or account, one should be able to import config using its export password.
Maybe the people who are available to try out scenarios can find “best practices”, which maybe eventually will be passed on to users in docs and the release notes.