Compose backup of container includes entire mapped directory tree?

  • EDIT - I noticed that the sabNZBD backup process was actually still running and appears to actually have been moving the entire contents of /share to the container backup. I killed the rsync process and disabled the backup until I get my head around this.



    I have just begun playing with the Compose plug-in as a way to manage the docker containers I had created manually through Portainer or docker compose. I was interested in simplifying backups and restorations of containers and OMV itself and seems like this is the way to go.


    My Compose settings are below. Config sits on my SSD system drive and is where I've been storing all my compose files and persistent configuration of each container. Pool is a large mergerfs pool consisting of 20ish drives, and "share" is the single top -level folder that contains all the data. This is split into "storage" and "media," with each of those being further split, and on and on.



    I began by migrating a few less used containers, MeTube and Bonob, which seemed to go well, so I then created one for my primary media downloading service, sabNZBD. The compose file looks like this:


    services:

      sabnzbd:

        image: lscr.io/linuxserver/sabnzbd:latest

        container_name: sabnzbd2

        environment:

          - PUID=1000

          - PGID=100

          - TZ=America/New_York

        volumes:

          - /config/sabnzbd:/config

          - /share:/share

        ports:

          - 38092:8080

        restart: unless-stopped


    I also have backups enabled every Tuesday at 11PM.



    At midnight each day, a snapraid sync and scrub runs, which usually takes between 6-8 hours. When I noticed that it was still running after about 11 hours, I looked at the output and found that it appears that the backup of the sabNZBD container included the entire contents of the /share directory that was mapped inside the container. I assume these are hardlinks, as there's no way I could store dupes of all the data in that folder. However, what I want to back up is only the compose file itself and the persistent configuration, but not the entire contents of every mapped directory in each container.


    I assume I've made an error with my configuration somewhere. Can anybody help me identify it? I'm trying to post an example of the line in the snapraid output that led me to these conclusions, but I am traveling and only have JuiceSSH on Android to access the system. I can't seem to figure out how to copy the text that extends past the width of the console window.

    OMV 7.7 (Sandworm) - Linux 6.2.16-20-pve - Intel Core i5-12500

    Edited 2 times, last by flvinny521 ().

    • Official Post

    Read the wiki - https://wiki.omv-extras.org/do…v7_plugins:docker_compose - specifically the backup section that talks about the SKIP_BACKUP flag.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Read the wiki - https://wiki.omv-extras.org/do…v7_plugins:docker_compose - specifically the backup section that talks about the SKIP_BACKUP flag.

    Perfect, so this is intended behavior and I should manually specify the /share directory to be skipped. Can I assume that the partial backup that I interrupted was non-destructive and all the files rsynced still exist at /share? I spot-checked a few specific files and everything seems to be in tact at the source directory, but doing this from my phone makes it a bit trickier to verify.


    If the backup doesn't alter or delete the source files, I'll just delete the backup and move forward from there.

    OMV 7.7 (Sandworm) - Linux 6.2.16-20-pve - Intel Core i5-12500

    • Official Post

    Perfect, so this is intended behavior and I should manually specify the /share directory to be skipped.

    Yes. The backup has no idea whether you really want to back it up or not.


    Can I assume that the partial backup that I interrupted was non-destructive and all the files rsynced still exist at /share?

    The backup script will never delete source files because rsync doesn't.


    If the backup doesn't alter or delete the source files, I'll just delete the backup and move forward from there.

    Backup that alters the source files would be dangerous and not make sense.

    omv 8.0.6-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.2 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • flvinny521

    Added the Label resolved
  • flvinny521

    Added the Label OMV 7.x

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!