[GH-ISSUE #5538] Built-in Backup Tooling for Self-Hosted Installs #11394

Open
opened 2026-08-05 01:29:33 -04:00 by saavagebueno · 4 comments
Owner

Originally created by @rgareh on GitHub (Mar 7, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5538

Is your feature request related to a problem? Please describe.
Yes. The NetBird self-hosted stack currently has no documented backup path and no official tooling for backing up management state, configuration, or the database. The management container holds meaningful, non-trivial-to-reconstruct state: peer configurations, routes, DNS settings, access policies, and user assignments. There is no getting-started guidance, no maintained script, and no compose-adjacent utility to handle this.
For anyone running NetBird as a production zero-trust layer, rather than a homelab experiment, discovering this gap after a host failure is a bad situation.

Describe the solution you'd like
A maintained backup script or compose service, shipped with or alongside the self-hosted install, that handles:

Config and environment archival - NetBird config files and .env state
Clean database snapshots - container-coordinated dump that pauses writes before snapshotting and resumes after, to avoid partial-state backups
Compression and optional offsite transfer - rsync or similar, with the option to route over an existing NetBird tunnel (which makes the backup path itself zero-trust, a neat property)
Trivial scheduling - a documented cron one-liner to go with it

This doesn't need to be complex. A well-maintained 100-line bash script with a documented cron entry would cover the majority of the use case. The problem today is that every self-hoster has to write this themselves, gets it subtly wrong, or doesn't do it at all until something goes wrong.

Describe alternatives you've considered
I've written a custom bash script that handles all of the above, including clean container-coordinated database snapshots and offsite rsync over the NetBird tunnel. It works, but it shouldn't require everyone to reinvent it independently.
Possible implementation approaches - none of these need to touch the core codebase:

A backup.sh script in a scripts/ or hardening/ directory in the repo
An optional --with-backups flag on getting-started.sh
A documented, maintained wiki page with a copy-paste script and cron entry
A companion compose service for teams wanting a more integrated approach

Additional context
This pairs naturally with a related request for CrowdSec integration (#5537). Both represent the same underlying gap: the getting-started experience gets you running quickly, but leaves meaningful production-readiness work undocumented and unsupported.
I'm happy to contribute a draft script and documentation as a starting point if there's interest from the maintainers.

Originally created by @rgareh on GitHub (Mar 7, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5538 **Is your feature request related to a problem? Please describe.** Yes. The NetBird self-hosted stack currently has no documented backup path and no official tooling for backing up management state, configuration, or the database. The management container holds meaningful, non-trivial-to-reconstruct state: peer configurations, routes, DNS settings, access policies, and user assignments. There is no getting-started guidance, no maintained script, and no compose-adjacent utility to handle this. For anyone running NetBird as a production zero-trust layer, rather than a homelab experiment, discovering this gap after a host failure is a bad situation. **Describe the solution you'd like** A maintained backup script or compose service, shipped with or alongside the self-hosted install, that handles: Config and environment archival - NetBird config files and .env state Clean database snapshots - container-coordinated dump that pauses writes before snapshotting and resumes after, to avoid partial-state backups Compression and optional offsite transfer - rsync or similar, with the option to route over an existing NetBird tunnel (which makes the backup path itself zero-trust, a neat property) Trivial scheduling - a documented cron one-liner to go with it This doesn't need to be complex. A well-maintained 100-line bash script with a documented cron entry would cover the majority of the use case. The problem today is that every self-hoster has to write this themselves, gets it subtly wrong, or doesn't do it at all until something goes wrong. **Describe alternatives you've considered** I've written a custom bash script that handles all of the above, including clean container-coordinated database snapshots and offsite rsync over the NetBird tunnel. It works, but it shouldn't require everyone to reinvent it independently. Possible implementation approaches - none of these need to touch the core codebase: A backup.sh script in a scripts/ or hardening/ directory in the repo An optional --with-backups flag on getting-started.sh A documented, maintained wiki page with a copy-paste script and cron entry A companion compose service for teams wanting a more integrated approach **Additional context** This pairs naturally with a related request for CrowdSec integration (#5537). Both represent the same underlying gap: the getting-started experience gets you running quickly, but leaves meaningful production-readiness work undocumented and unsupported. I'm happy to contribute a draft script and documentation as a starting point if there's interest from the maintainers.
saavagebueno added the feature-request label 2026-08-05 01:29:33 -04:00
Author
Owner

@heymoe commented on GitHub (Mar 8, 2026):

Unless I'm not understanding the request correctly, there is documentation on how to backup your self-hosted NetBird install here: https://docs.netbird.io/selfhosted/maintenance/backup

I've used that info to write my own script to automate backing up my deployments as well as move the data that is stored in Docker volumes to bind mounts for easier access and backups.

<!-- gh-comment-id:4018595235 --> @heymoe commented on GitHub (Mar 8, 2026): Unless I'm not understanding the request correctly, there is documentation on how to backup your self-hosted NetBird install here: https://docs.netbird.io/selfhosted/maintenance/backup I've used that info to write my own script to automate backing up my deployments as well as move the data that is stored in Docker volumes to bind mounts for easier access and backups.
Author
Owner

@rgareh commented on GitHub (Mar 9, 2026):

Unless I'm not understanding the request correctly, there is documentation on how to backup your self-hosted NetBird install here: https://docs.netbird.io/selfhosted/maintenance/backup

I've used that info to write my own script to automate backing up my deployments as well as move the data that is stored in Docker volumes to bind mounts for easier access and backups.

Thanks for the link. I should have found that before filing, and I appreciate the pointer. You're right that the procedure is documented.
To clarify what I was actually after: the gap I was trying to describe is less about the steps themselves and more about the lack of a ready-to-run automated solution. The docs describe what to do manually, but there's no maintained script, no cron-ready wrapper, and no mention of offsite transfer or scheduling. I suspect, most self-hosters won't find the backup page until they go looking for it... it's not referenced from the quickstart or the getting-started output.
That said, this is a much smaller gap than I initially framed it. Happy to contribute a simple wrapper script and a suggested cron entry if that would be useful. Might be a lower-effort path than a feature request.

<!-- gh-comment-id:4021539457 --> @rgareh commented on GitHub (Mar 9, 2026): > Unless I'm not understanding the request correctly, there is documentation on how to backup your self-hosted NetBird install here: https://docs.netbird.io/selfhosted/maintenance/backup > > I've used that info to write my own script to automate backing up my deployments as well as move the data that is stored in Docker volumes to bind mounts for easier access and backups. Thanks for the link. I should have found that before filing, and I appreciate the pointer. You're right that the procedure is documented. To clarify what I was actually after: the gap I was trying to describe is less about the steps themselves and more about the lack of a ready-to-run automated solution. The docs describe what to do manually, but there's no maintained script, no cron-ready wrapper, and no mention of offsite transfer or scheduling. I suspect, most self-hosters won't find the backup page until they go looking for it... it's not referenced from the quickstart or the getting-started output. That said, this is a much smaller gap than I initially framed it. Happy to contribute a simple wrapper script and a suggested cron entry if that would be useful. Might be a lower-effort path than a feature request.
Author
Owner

@websheriff commented on GitHub (Mar 25, 2026):

It's not an automated solution, but I'm not sure they should be reinventing the wheel when something like restic for example is already out there, but that does require some setting up that's not necessarily a point and click in the netbird GUI, which is what I think you're saying.

<!-- gh-comment-id:4123536122 --> @websheriff commented on GitHub (Mar 25, 2026): It's not an automated solution, but I'm not sure they should be reinventing the wheel when something like restic for example is already out there, but that does require some setting up that's not necessarily a point and click in the netbird GUI, which is what I think you're saying.
Author
Owner

@mr-gulin commented on GitHub (Jul 1, 2026):

Hi!
There's a documented way to backup the instance which requires downtime.
However, using the default sqlite backup mechanism (or Postgres if that's the case) it is possible to backup the instance without downtime.
This is doable by writing a script, but I really would like to see backup/restore as a built-in mechanism that would possibly evolve alongside with other changes, so I can just do a cron job on it and forget.

<!-- gh-comment-id:4854007098 --> @mr-gulin commented on GitHub (Jul 1, 2026): Hi! There's a documented way to backup the instance which requires downtime. However, using the default sqlite backup mechanism (or Postgres if that's the case) it is possible to backup the instance without downtime. This is doable by writing a script, but I really would like to see backup/restore as a built-in mechanism that would possibly evolve alongside with other changes, so I can just do a cron job on it and forget.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11394