Re: [keycloak-dev] Using export and import for backup and restore

On Mon, Sep 30, 2019 at 3:31 PM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: I believe any of those two would be a problem. In the Operator use case, all modifications should be made through the Operator. That means, we could implement a simple Mutex and prevent the Operator from modifying anything until the backup is complete. The more I'm thinking about it, the more I'm convinced that's using export/import gives us the most flexibility. At first, we could simplify basic configuration of a Realm (and other CRDs in the future as well). We would expose only basic settings and if anyone wants to configure every small detail, he would need to prepare a full JSON and restore it - just like restoring a backup - the same mechanism. If there are some guarantees (are there any?) about the structure of the JSON backup, we could use it for complicated migration process - like Integreately, where they need to migrate off the old Keycloak Operator to a new one. Also, the structure remains of the JSON file remains compatible across Keycloak/RHSSO versions, we could use it for migrating our customers from Keycloak to RHSSO. Finally, this solution doesn't tie us up to a particular database and its version. During an upgrade, we can wipe the database up and just restore Keycloak from a JSON file. That's another option we consider. We could use Volume Snapshots [1] and just backup the whole Postgresql data directory. This seems to be the fastest option and I believe, the Integreately Team tried that before (Peter, David - perhaps you could tell us more about it). However, it ties us up to Postgresql in a specific version (as far as I know there are no guarantees about migrating the data directory between Postgresql versions). My intuition tells me, this will be a problem in long-term. [1] https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-f...