-
|
We've recently switched to Keycloak and are now running cluster which gives us some redundancy and load balancing. However, when planning/implementing backups for disaster recovery, I got a bit confused reading about different ways of how to do that. From what I understand, the options are basically
Searching for documentation about backing up Keycloak, Importing and exporting realms seems to come up most often. I've tried it. It seems to work. But… I've also found a lot of hints that it comes with quite a few drawbacks. I found a few mentions that the process is rather slow, and you need to be careful when exporting realms with too many users. Although, that seems to be mostly the case if you export the data into a single backup file. You can easily work around that. More concerning are the comments stating that Keycloak needs to be stopped before triggering an export. I found a merged pull request stating that's no longer an issue, but I also had someone claiming that it is still an issue only yesterday, and it's also still mentioned in parts of the documentation (first sentence in that section). Taking down the cluster every time you trigger a backup doesn't sound great 😅 The alternative method you find people use is a database dump ( What has me a bit concerned though is that while I found quite a few people doing that, I mostly just found mentions of this in comments. Quite a few comments, that is, but still no official documentation. That makes me wonder why? That way is so obvious. Are there any drawbacks? The DB dump seems so much easier. Why isn't that the “official” way? Am I missing something? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I may be wrong, but I think the export / import route is better documented since it's Keycloak specific and is likely meant to be a more customizable approach to doing things, as well as portable from one version to another. For example, you can have a realm template where you can add placeholders that are updated via a script before importing it into Keycloak. We use this to quickly bootstrap a Keycloak instance for some webdev environments, where we can automatically create a realm, client, LDAP connection / local users, and so on. Strictly for backup purposes, I don't think there's anything wrong with just using SQL dumps, as this is basically standard practice for database operations. The largest downside is, of course, that it's much less customizable and it's tied to the version of Keycloak where you've taken the snapshot. If you try to import a database dump created from a previous version (e.g., highly recommended to have one just before an upgrade), Keycloak will have to run database migrations on it. Conversely, trying to use a database dump with an older version of Keycloak (for whatever reason) will not work, while exports will likely work unless you include some specific new features. |
Beta Was this translation helpful? Give feedback.
I may be wrong, but I think the export / import route is better documented since it's Keycloak specific and is likely meant to be a more customizable approach to doing things, as well as portable from one version to another.
For example, you can have a realm template where you can add placeholders that are updated via a script before importing it into Keycloak. We use this to quickly bootstrap a Keycloak instance for some webdev environments, where we can automatically create a realm, client, LDAP connection / local users, and so on.
Strictly for backup purposes, I don't think there's anything wrong with just using SQL dumps, as this is basically standard practice for database operations.…