I have hit a limitation using this container that I wanted to report just in case it helps someone else.
I am using a podman quadlet systemd service to run this image. It works fine but I eventually noticed that new changes to the directories under /backup did not get backed up to jotta cloud. I confirmed there were no permission issues accessing those files from inside the running containers so for a while I was a bit stumped as to what was going on.
After using jotta-cli tail I finally saw the problem:
pid:12 2024/03/05 10:36:37 Queueing scheduled scan of /backup/photos (Interval)
pid:12 2024/03/05 10:36:37 Starting full scan at /backup/photos
pid:12 2024/03/05 10:36:37 Queueing scheduled scan of /backup/containers (Interval)
pid:12 2024/03/05 10:36:37 ok stat with 0 got filesystem info id[c03b98a9d583d91e] type[overlayfs] for path /backup/photos
pid:12 2024/03/05 10:36:37 Error occurred starting full scan: Filesystemid has changed [7ccce3e68f640449] => [c03b98a9d583d91e]. Scan will not continue
pid:12 2024/03/05 10:36:37 Starting full scan at /backup/containers
pid:12 2024/03/05 10:36:37 ok stat with 0 got filesystem info id[c03b98a9d583d91e] type[overlayfs] for path /backup/containers
pid:12 2024/03/05 10:36:37 Error occurred starting full scan: Filesystemid has changed [7ccce3e68f640449] => [c03b98a9d583d91e]. Scan will not continue
That lead me straight to this jotta-cli issue which explains what is going on: https://github.com/jotta/jotta-cli-issues/issues/81 . I suppose this feature exists in jotta-cli so it doesn't accidentally blow away existing backups if the expected local FS is not there.
Sure enough, after running jotta-cli add --confirmexisting /backup/photos, jotta-cli picked up the changed files and began working as expected.
You can see the filesystem ID using stat -f /. I am sure there are better ways.
Unfortunately, if you delete and then recreate the container the filesystem ID is going to change. So for example, when podman-auto-update runs and recreates the container with any updated image, jotta-cli ends up "silently" not backing up.
I have hit a limitation using this container that I wanted to report just in case it helps someone else.
I am using a podman quadlet systemd service to run this image. It works fine but I eventually noticed that new changes to the directories under /backup did not get backed up to jotta cloud. I confirmed there were no permission issues accessing those files from inside the running containers so for a while I was a bit stumped as to what was going on.
After using
jotta-cli tailI finally saw the problem:That lead me straight to this jotta-cli issue which explains what is going on: https://github.com/jotta/jotta-cli-issues/issues/81 . I suppose this feature exists in jotta-cli so it doesn't accidentally blow away existing backups if the expected local FS is not there.
Sure enough, after running
jotta-cli add --confirmexisting /backup/photos, jotta-cli picked up the changed files and began working as expected.You can see the filesystem ID using
stat -f /. I am sure there are better ways.Unfortunately, if you delete and then recreate the container the filesystem ID is going to change. So for example, when podman-auto-update runs and recreates the container with any updated image, jotta-cli ends up "silently" not backing up.
Might it be possible to add an environment variable so that the entrypoint.sh around line 113 can optionally include
--confirmexistingwhen it runsjotta-cli add? https://github.com/bluet/docker-jottacloud/blob/main/entrypoint.sh#L113