Feature suggestion: Database backup function

[sgofferj]

Is your feature request related to a problem? Please describe.
Somewhat. With moving NC into a docker stack with prudent security settings, the host system does not really have access to the DB anymore.

Describe the solution you'd like
I suggest a database backup function which when triggered

• Puts the system in maintenance mode
• Freezes the DB
• Creates a sql backup of the DB, maybe gzips it and puts it into a configurable location within the NC realm
• Unfreezes the DB
• Puts the system back into operating mode

Ideally, the backup could be triggered manually from the admin settings or scheduled with the schedule being configurable through the admin settings as well.

Describe alternatives you've considered
The only alternative would be to use a script on the host system which would require host system access to the DB - which would be somewhat contrary to the container philosophy, security-wise.

[j-ed]

I would expect that the OwnBackup app has explicitly been developed for this purpose, hasn't it?!

[sgofferj]

@j-ed
I actually haven't found that app before, thanks! At first glance, however, it does not seem possible to automate it nor does it offer a choice where the backup should go, so it would be hard to e.g. move it to a centralized backup system.

[j-ed]

@sgofferj I don't think that a second way to backup data will be implemented into Nextcloud. I think, it would be worse to create a feature request in the app repository.

[sgofferj]

@j-ed
I can do that and reference this request, although I kinda think that it should be a core functionality. But that's for the maintainers to decide.

[kesselb]

that it should be a core functionality.

I am not convinced. Why reinventing the wheel? There are many backup solutions out there. I don't think we need that as core functionality.

The only alternative would be to use a script on the host system which would require host system access to the DB - which would be somewhat contrary to the container philosophy, security-wise.

I'm not a docker expert but starting a temporary container for your backup does not work? I guess this is what most people do: https://medium.com/@tomsowerby/mysql-backup-and-restore-in-docker-fcc07137c757

Puts the system in maintenance mode

This might be a problem yes. Perhaps stop the nextcloud container during the mysql backup?

cc @nextcloud/docker how do you backup your instances?

[cyphar]

cc @nextcloud/docker how do you backup your instances?

Back when I ran under Docker (I now run under LXC but it's quite similar), I have volumes for all of the data folders which are backed up using https://github.com/restic/restic. The database is PostgreSQL (running in a separate container because I share the database with my Matrix homeserver), and I just follow the best-practice for PostgreSQL backups. Personally I wouldn't have much use for a "backup the database" feature in Nextcloud since I have more than just one user of my database (and thus I need a whole-database backup -- and Nextcloud can only see its own database).

[sgofferj]

Before I moved NC to docker, I had one central db for everything. NC, asterisk, Joomla, some self-writtten stuff... Part of my moving everything over to docker was to also move away from the central db to db containers in the corresponding stack. The stacks are configured so that all containers in a stack have their private network and are not reachable from outside the stack with the exception of the web server instance which is in an additional network where the revproxy (and only the revproxy) can reach it.
Reason for me thinking it would be good to have the backup function in the core is that this way, nothing from outside the stack ever needs to have direct access to anything inside the stack, like the db. The core already has access to the db - naturally.
IMHO it would make the db backup very easy and also elegant. If a backup to a physically different storage is desired, the admin could include that as external storage. Even offsite-backup would be trivial and elegant, may it be to Google Cloud, AWS S3 or any other offsite solution which NC includes connectors for.
Another advantage would be for users of NAS boxes or other systems without full console access. For those, a db backup could turn out to be a challenge. Not so if it was core functionality...

[tflidd]

Nextcloudpi has implemented some basic backup solutions in their systems:
https://docs.nextcloudpi.com/en/how-to-periodically-backup-to-a-second-usb-drive-with-nextcloudpi/

Reason for me thinking it would be good to have the backup function in the core is that this way, nothing from outside the stack ever needs to have direct access to anything inside the stack, like the db.

Normally you don't want the main system having direct access to your backup: in case your system is compromised, it cannot compromise old backups as well.

[sgofferj]

Normally you don't want the main system having direct access to your backup: in case your system is compromised, it cannot compromise old backups as well.

I guess, that's a matter of philosophy and also of implementation... Or how much one trusts NC vs. how much one trusts the environment in which the stack runs.

[J0WI]

Nextcloudpi has implemented some basic backup solutions in their systems

That's just mysqldump and tar.

[szaimen]

Please use either the database commands or this app https://apps.nextcloud.com/apps/nextbackup for this. Thanks! :)