[Feature] Backups volumes/directories ignore list
hazzuk opened this issue · 5 comments
Prerequisites
- I have searched for duplicate or closed feature requests
Proposal
The user should be able to define a list of volumes/directories they want the backup process to ignore.
- Volumes would use volume names, and they would be skipped over when looping through the stack volumes list.
- Directories might work by having tar filtering out the array of ignore list directories during working_dir backup.
Motivation and context
The volume/directory might want to be ignored as it doesn't need to be/is too large to be backed up.
Hello,
This would clearly be a must-have for me to use this project (which I think is a great project to do to be honest).
My problem is if I do that on my plex compose stack, it'll try to backup all my libraries on a remote NFS target.
Also I have multiple stacks that use local filesystem instead of docker volumes. Is that compatible in its current state?
I have multiple stacks that use local filesystem instead of docker volumes.
Aside from backups of named Docker volumes, on the file system backupdate only archives the working directory of the Docker compose stack (the directory with your compose.yaml file). So if you're like me, and using bind mounts which are all located inside the working directory, then you're covered. Otherwise that'll need to be another feature request for backups of custom directories.
on my plex compose stack, it'll try to backup all my libraries on a remote NFS target.
Are your media libraries attached to the plex container as named volumes or bind mounts? If they're bind mounts and they're not mounted inside the working directory as explained above you shouldn't have a problem. (edit: from thinking about accidental backups, I've raised this feature request #7)
Sorry I meant my *arr, not the plex one :)
volumes:
downloads_transmission:
driver: local
driver_opts:
type: nfs
o: "addr=<redacted NFS server>,nolock,nfsvers=4.2"
device: ":/my/super/nfs/share"
services:
dl-sonarr:
[...]
- downloads_transmission:/downloads #optional
[...]
Would your script try to back this up?
Suggestion : a label on either the container or the volume to choose which ones not to backup?
Would your script try to back this up?
Yes, but this can now be prevented in the latest version of the script with the backup_blocklist.
Using -l "downloads_transmission"
will prevent the script from backing up this named volume.
Suggestion : a label on either the container or the volume to choose which ones not to backup?
Wasn't able to go this route as unfortunately labels can't be added to existing volumes.