Backup of overseerr:latest data volume causes backup to fail about docker-volume-backup HOT 12 CLOSED

The backup of the overseerr container's data volume had been working up until recently and suddenly didn't anymore after a recent update of the offen/docker-volume-backup image

Do you run latest? In case yes, you might want to lock your version numbers (i.e. do not use latest, but one of the versioned tags here: https://hub.docker.com/r/offen/docker-volume-backup/tags?page=1&ordering=last_updated) as it seems you have inadvertently upgraded to a new major version (which is a rewrite from scratch, thus v2). See: https://github.com/offen/docker-volume-backup/releases/tag/v2.0.0

As for the failure itself: how big is the file you are updating?

from docker-volume-backup.

Could you share the exact image and volume config you are using for the failing service so I can try to reproduce the issue on my end? Fixing it might be a little tricky though as the problem arises inside of a dependency here https://github.com/walle/targz

For the time being I would advise you to lock the docker-volume-backup image to v1.8.3,. which seems to work correctly if I understand you correctly.

from docker-volume-backup.

I think it would be nice if v2 handles that case too so I'd leave this issue open until it's resolved in any way. Thanks for the config.

from docker-volume-backup.

For anyone affected, I also released the pending fix as v2.0.1-pre in case anyone wants or needs to test it in their setups already.

from docker-volume-backup.

I just saw that on dockerhub and wanted to thank you!
Definitely taking it for a test spin ;)

EDIT: The "v2.0.1-pre" tagged image worked like a charm

from docker-volume-backup.

I think I'll rely on the fork over here https://github.com/m90/targz for now, so I'll make this a proper v2.0.1. If the upstream package ever merges the PR I can always go back to using the original package again.

from docker-volume-backup.

Awesome!! I'll change that tag back to "latest" :)
Thank you.

from docker-volume-backup.

This seems pretty close to what is happening: https://stackoverflow.com/a/40003617/797194

Does your backup contain symlinked files?

from docker-volume-backup.

Thanks for the speedy reply, @m90

I think you might be onto something with the symlink as the overseerr container does create a symlink log file. That was the only thing that seemed "out of the ordinary" when inspecting the overseerr config bind mount.

Just for clarification: The backup to my own S3 service running on my truenas storage server works flawlessly when excluding the overseer data volume.
I absolutely love your image... it was such a delight to use as a backup solution after trying so many other solutions that were not up to the task.

from docker-volume-backup.

Image version set to 'v1.8.3' and the backup (including overseerr) worked as expected.

Here is my portainer stack for overseerr:

---
version: "3"
services:
  overseerr:
    image: ghcr.io/linuxserver/overseerr
    container_name: overseerr
    environment:
        - PUID=1000
        - PGID=1000
        - TZ=Europe/Berlin
    volumes:
        - /home/user/docker/overseerr/config:/config
    network_mode: bridge
    ports:
        - 5055:5055
    restart: unless-stopped
    labels:
      - docker-volume-backup.stop-during-backup=true

/home/user/docker/overseerr/config is mounted to /backup/overseerr:ro on the docker-volume-backup container.

from docker-volume-backup.

You can gladly mark this as solved due to a know bug in a dependency if you like.
Or should I "close with comment"? I am very new to github issue posts. ^^

from docker-volume-backup.

So I've got a fix for this over at this branch.

I also opened a PR including that fix against the upstream repo which would be the best way to fix this. I will wait a few days to see if maintainers respond. If this is blocking anyone else in the meantime, please comment in this issue and we can get the version depending on the fork shipped.

from docker-volume-backup.