Add backup cronjobs

[stephan2012]

Pull Request

Description of the change

Allow creation of Kubernetes Cronjobs for periodic backups of the Nextcloud data volume.

Benefits

The PR provides a standard method of installing backup cronjobs. It uses the Helm chart's configuration data to share the configuration.

Possible drawbacks

I have yet to be aware of any drawbacks.

Applicable issues

N/A

Additional information

Checklist

• DCO has been signed off on the commit.
• Chart version bumped in Chart.yaml according to semver.
• (optional) Variables are documented in the README.md

[provokateurin]

Cool idea, I hope to be able to review it soon.
I'm wondering if it makes sense to have the extra values both in the readme and the values.yaml as they tend to get out of sync at some point.

[jessebot]

This needs a rebase, but I also think we should include setting maintenance mode on before the restic example and turning it off after it's done.

[stephan2012]

Oops. Forgot about this.

I’ll do the rebase today. Not sure about maintenance mode … I’d prefer to leave the system online and do a file scan after restore.

[jessebot]

maintenance mode is recommended to be on during backups: https://docs.nextcloud.com/server/latest/admin_manual/maintenance/backup.html

[stephan2012]

maintenance mode is recommended to be on during backups: https://docs.nextcloud.com/server/latest/admin_manual/maintenance/backup.html

@jessebot For me, the only feasible way seems to be to mount the config folder into the backup container to allow modifications to config/config.php. Some logic in the backup container would be responsible for updating the file before and after the backup. For this option, the only required Helm chart extension would be the additional volume mount.

While Kubernetes has init containers (enter backup mode), it does not have the concept of "exit containers" (leave backup mode). Also, lifecycle hooks are not an option because Kubernetes does not guarantee their execution time.

Thoughts?

[jessebot]

@jessebot For me, the only feasible way seems to be to mount the config folder into the backup container to allow modifications to config/config.php. Some logic in the backup container would be responsible for updating the file before and after the backup. For this option, the only required Helm chart extension would be the additional volume mount.

While Kubernetes has init containers (enter backup mode), it does not have the concept of "exit containers" (leave backup mode). Also, lifecycle hooks are not an option because Kubernetes does not guarantee their execution time.

Thoughts?

Actually, the way I do this is via just having Kubernetes CronJobs for just the maintenance mode being turned on and off, and then I use a k8up Schedule, which is a scheduled restic backup of all the annotated PVCs in the nextcloud namespace, to actually do the backup. During that time, I also have a scheduled backup that takes place via the Cloud Native PostgreSQL Operator. In my personal opinion, I think using a backup operator that wraps restic (Like Velero or K8up) is ideal, and the main thing we should be concerned about here is the maintenance mode cronjobs, but I'm also interested in hearing more opinions from other collaborators and maintainers such as @tvories and @provokateurin 🙏

[stephan2012]

Actually, the way I do this is via just having Kubernetes CronJobs for just the maintenance mode being turned on and off, […]

There are probably more reliable approaches than relying on wall-clock-based synchronization. It either reduces service availability or toggles the switch too early.

and then I use a k8up Schedule, which is a scheduled restic backup of all the annotated PVCs in the nextcloud namespace, to actually do the backup. During that time, I also have a scheduled backup that takes place via the Cloud Native PostgreSQL Operator.

My preferred option is to use logging and continuous WAL archiving as provided by the Zalando Postgres Operator (uses wal-e or wal-g under the covers), allowing you to restore the database consistently into any point in time.

In my personal opinion, I think using a backup operator that wraps restic (Like Velero or K8up) is ideal, and the main thing we should be concerned about here is the maintenance mode cronjobs, but I'm also interested in hearing more opinions from other collaborators and maintainers such as @tvories and @provokateurin 🙏

Let's be agnostic about the backup tool. People will probably use a wide variety of backup solutions and technologies.