One of the things I like about the docker image is just that it absolutely rigidly guarantees that all the state is located only in exactly the directories I specify, and I can be sure of that by construction.
So my Nextcloud backup solution is a cron job that shuts the entire container down and runs a restic job on it, then brings it back up when the backup is complete.
I'm not completely sure that's quite "self-made"; restic is standard enough. The only special sauce is just that I don't even bother with how to handle files that are open, especially with the database. I just shut it all down.
The nice thing is this works with all my docker stuff; the cron job just iterates them one at a time, shutting them down and doing the same standard backup on them all, then bringing them up. I don't need or want a Nextcloud-specific backup mechanism.
No. Docker compose, if you want to get technical not just "docker", with MariaDB. When the cron job runs docker-compose down it backs all the subdirs up, including the full DB directory. (Probably not a cheap plan for a heavy-use site, but for my family it's a normal thing for day-to-day to have no changes.)
Interesting that you comment about SQLite being a problem. I am not a heavy user of Nextcloud, but I haven't had the operational problems many people report here; I wonder if that's correlated to using SQLite.
So my Nextcloud backup solution is a cron job that shuts the entire container down and runs a restic job on it, then brings it back up when the backup is complete.
I'm not completely sure that's quite "self-made"; restic is standard enough. The only special sauce is just that I don't even bother with how to handle files that are open, especially with the database. I just shut it all down.
The nice thing is this works with all my docker stuff; the cron job just iterates them one at a time, shutting them down and doing the same standard backup on them all, then bringing them up. I don't need or want a Nextcloud-specific backup mechanism.