-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
website/docs: sys mgmt: document authentik backups #12943
base: main
Are you sure you want to change the base?
website/docs: sys mgmt: document authentik backups #12943
Conversation
✅ Deploy Preview for authentik-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for authentik-storybook ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #12943 +/- ##
==========================================
- Coverage 92.68% 92.59% -0.10%
==========================================
Files 785 785
Lines 39623 39623
==========================================
- Hits 36724 36687 -37
- Misses 2899 2936 +37
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Depends on #12962 for the Docker container names. |
…d and this is the easiest no-config-change solution that works
You don't need to, we assume in the documentation that a bunch of commands are run from the docker-compose directory. |
--- | ||
|
||
This guide provides steps to back up authentik, including its PostgreSQL database, Redis data, and some important directories. These instructions cover both Kubernetes and Docker environments. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add explanations about what is stored where, and why it is important to back it up. For instance, some users might not want to go through the trouble of backing up redis.
One thing I forgot to mention, I don't want us to provide specific instructions for backing things up, but instead provide references to our dependencies respective documentation. |
For example, linking the Postgres backup page instead of providing a command? I'm curious, is there any specific reasoning behind this? While this might simplify things for us, it could ultimately create more challenges for the user, particularly those who aren’t as familiar with Postgres or Redis. There’s a risk they could end up relying on commands from unreliable third-party documentation or their own improvised solutions, which could lead to data loss or improper backups due to incorrect usage or poor practices. Wouldn’t it be safer and more effective to direct them to the official dependency documentation and provide commands? |
This is a bit like one of my first PRs to authentik: upgrading PG from v12 to 16. We could have linked pg_restore/pg_dump/pg_whateverelse docs but instead we provided a step-by-step with postgres commands. |
Exactly
There is. First, there is the added maintenance for us. Providing specific instructions would mean that we have to maintain those, possibly for multiple versions of postgres (for instance the helm chart and the docker-compose ones don't currently match). It also means that we would need to provide some level of support for issues and questions coming in. We currently don't have that kind of bandwidth. Backing things up (whether it's postgres, redis, files, or whatever else) is never easy and straightforward. Providing commands would make it look like it is, but it isn't. There are many other things to consider, like the fact that we also need to backup users and their password so that on restore. While on the topic of restoration, we would also need to provide additional instructions for that. We also need to consider that using the provided postgres/redis setup with the docker-compose and helm chart is not the way everyone runs authentik. I would much rather have explanations of what needs to be backed up, why it needs to be backed up, and solid pointers to resources explaining how to do it, instead of us trying to "make things up" even though it isn't our expertise.
Not our problem. Seriously. I know it sounds harsh, but if anyone is running an application (authentik or else) and rely on that data without having 1. learned how to do backups and 2. proper setup and testing of said backups, they shouldn't be running that application. Which is why I want us to point people in the right direction, with links to references of the upstream backup documentation for example. |
What?
This PR adds documentation to backup the authentik postgresql, redis, and server/worker containers & pods. Adds steps for K8s and docker.
Closes
Closes #8411
make website
)