Set backup Destination

[mandraid]

I'd like to request this feature; when doing a backup, being able to specify where the backups should be placed (example, an external drive).

[kyrofa]

Seems reasonable, just keep in mind that the writable areas are pretty limited due to confinement, so we need to handle errors well.

[scubamuc]

currently I'm using an alternative "snap-backup" skript for this:

snap stop 'nextcloud'
snap save 'nextcloud'
snap start 'nextcloud'
find snapshot in "/var/lib/snapd/snapshots" and move to external media
find /var/lib/snapd/snapshots/ -name "*.zip" -exec mv '{}' /media/BACKUP/ \;
find and remove older snapshots
find /var/lib/snapd/snapshots/ -name "*.zip" -mtime +30 -exec rm -f {} \;

this works fine in weekly automatic (cronjob as root) mode and has the added convenience of easy snap transfer to different server when needed. thus always 4 weeks of snap-backup on external medium.

• cronjob daily/weekly/monthly, reduced downtime

[pachulo]

really nice one @scubamuc ! I think this should be added as an alternative in our wiki. WDTY @kyrofa ?

[scubamuc]

really nice one @scubamuc ! I think this should be added as an alternative in our wiki. WDTY @kyrofa ?

@pachulo
wiki entry...

• SCUBA's self-hosted Nextcloud-snap server

[NaXal]

Hello,

Little off topic, but when taking about different methods of backup, I have a question on data directory items.

Off late, due to HDD corruption issue, I was getting I/O error (read / write) while trying to issue full snap backup. When I dug deep, as to identify where exactly, I found a particular user data folder was having issue while copying data from.

So I decided to take snap nextcloud backup of Database and Config only and manually copy the user data directories from /data folder to another fresh installation and then restore the snap backup there. It worked, yes the said problematic user account needed to upload the files again. But the curious thing is an extra appdata folder.

root@vm-u22-nxt:/var/snap/nextcloud/common/nextcloud/data# ls -lst
total 40
4 drwxr-xr-x 2 root root 4096 May 16 18:14 ta****
4 drwxr-xr-x 10 root root 4096 Apr 29 22:21 appdata_ocgq1exp8w8u
4 drwxr-xr-x 5 root root 4096 Apr 29 18:53 Ba********
4 drwxr-xr-x 7 root root 4096 Apr 29 18:52 hu*******
4 drwxr-xr-x 5 root root 4096 Apr 29 18:47 sa**********
4 drwxr-xr-x 7 root root 4096 Apr 29 18:40 ba******
4 drwxr-xr-x 7 root root 4096 Apr 29 18:40 Tr********
4 drwxr-xr-x 7 root root 4096 Apr 29 18:35 Su*********
4 drwxr-xr-x 7 root root 4096 Apr 29 18:34 G*************
4 drwxr-xr-x 6 root root 4096 Apr 29 18:25 appdata_ocnnl3iy2w4n
0 -rw-r--r-- 1 root root 0 Apr 29 18:22 index.html
root@vm-u22-nxt:/var/snap/nextcloud/common/nextcloud/data#

Now I have two of them.

I didn't copy the appdata from previous installation. I only copied the individual user folders. But after restoration from snap DB / Config backup, I see the new installation has two of these directories.

How to figure out which one is in use and which one is safe to delete?

Thanks.

[maxkapur]

I'd like to bump this issue with a link to a discussion I saw on the Nextcloud forum about possible solutions:

https://help.nextcloud.com/t/change-directory-for-snap-nextcloud-export-exports/143346

In the current implementation, if you want to back up your files with nextcloud.export, the backups are stored in /var/snap/nextcloud/common/backups, so you need to have (asymptotically) at least 50% of your root partition empty to use it. Plausibly, many users have limited space on their root partition and want to dump backups to an external hard drive; possibly, this external drive will be hotplugged and lack a static path, or the user wants to rsync their backup to an SSH or SSHFS target.

The workarounds suggested in the link above are:

• Give the other HD a static mount point, symlink from /var/snap/nextcloud/common/backups to it, and give the Nextcloud Snap the removable-media permission. ⇒ This solves the disk space issue for backing up to another internal hard drive, but not the hotplugging/SSH cases.
• Use nextcloud.export -abc to backup everything except the files, and use rsync -a for the files themselves. ⇒ This solves the issue but doesn't let you restore from backup using nextcloud.import.

Questions to consider:

• Is it technically possible to allow a user-selected output directory within the Snap confinement?
• How do other Snap applications (e.g. Firefox) allow the user to save downloaded files to locations (e.g. ~/Downloads) outside of the container? Is a similar approach possible here?

One idea in the help thread was to allow nextcloud.export to print to stdout, sort of like tar does by default, which would allow the user to put backups outside of the Snap container by piping to another location. It's unclear, however, if doing so would require creating temporary files within the Snap directory, which wouldn't solve the disk space issue.

[HandsomeSimon]

Maxkapur hits the nail on the head for my issue with backups currently.
My setup is as follows:
Ubuntu running NextCloud snap on a 250GB SSD
NextCloud snap configured to store user data on an internal 6TB HDD (roughly 2TB used)
A second internal 6TB HDD where I would like the export feature to store my backups

If I run the export command, I assume it would completely fill my SSD and fail.
What I would love is to have a flag on running the export command to specify location.

However, if I had to restore a backup I don't know what that would look like. I would need a way to specify that config data belongs on the SSD and user data belongs on a different drive.

[shumancw]

More or less the same issue. I already have a backup routine for the data. What I need the backup to do is create a backup of all config, db, apps, etc. Maybe add a "-a" option for "application only" or "-c" for configuration only. Also, choosing location would be nice although I think I can get around that part of it pretty easily.

[scubamuc]

I already have a backup routine for the data

That's a good idea. There are plenty tools like rclone that can even sync between instances if needed. Locally hosted data is best backed up using Linux basics like rsync.

You can automate nextcloud.export with scripts quite nicely.
The procedure for backing up is more or less the same: https://github.com/nextcloud-snap/nextcloud-snap/wiki/Backup-and-Restore. As for choosing the storage location, that shouldn't be a problem. Even rotation is simple when needed.

Maybe you'd like to try this script with option -ac

[edsonsbj]

Hi Everyone, for anyone looking for an effective way to backup the nextcloud snap, here are two scripts, one uses the borg tool and the other uses rsync + tar

https://github.com/edsonsbj/Backup_Restore_Rsync

https://github.com/edsonsbj/Backup-Restore-Borg-Rclone