I switched from Duplicati to Duplicacy because of the former not really working and purchased a personal license. I need to run Duplicacy as a Docker container (saspus/duplicacy-web) because I want to backup Docker named volumes only available from Docker.
My problem is I need to stop containers using the volumes before backup and after backup start them again. Any advice on how to this in a Docker setup?
Can’t you mount them to the host?
A brute force solution would be to start and stop those other containers from duplicacy container from pre-backup and post-backup scripts via mapped host docker socket.
That is however rather ugly. Why can’t you mount those volumes to the host and manage backup in the host? Also, stopping services to run backup is a bit counterproductive. Depending on the type of data containers operate on, perhaps file system snapshots on the host will be sufficient?
Thanks for answering!
Maybe it’s my Docker knowledge and understanding, but I wouldn’t know how? These Docker-managed named volumes have been created through Docker Compose configuration. Do you mean that these Docker containers should access them via host mount also, thereby removing all named volumes and only do bind mounting?
That what I was doing with Duplicati and tried to do here, but if you have a better idea I’m all ears. I do like to manage the volumes for my applications using Docker though, not only do bind mount.
No, I only meant to bind them to the host for the purposes of backup – if not bind – maybe just backup those named volumes directly? (depending on the host OS they will be under /var/lib/docker/volumes or inside a docker VM)
Well, binding to host may work, but I too in no way expert on docker…
On the other hand – since you already had a working solution with duplicati – why not continue doing the same?
This is the thing I don’t understand. Normally I bind named volumes to Docker container filesystem. How would I bind them to the host?
Thing is, I’m no expert either. I gather you are the maintainer of this image so you’re probably more experienced than me.
Well, Duplicati was always throwing errors and many recommended Duplicacy over Duplicati so I though’t I’d try it.
Maybe something like this: how to bind Docker Named Volume to host - Stack Overflow? (I have never done it myself though).
Have you tried finding those named volumes on the host under /var/lib/docker/volumes? (perhaps I’ve edited this suggestion into my previous comment after you’ve already read it)
Heh 
I made this container for myself initially to easily deploy duplicacy to Synology DSM, but seeing high usage I keep supporting it ever since even though I first stopped using it myself (instead running it natively) and then got rid of Synology Diskstations. But it’s the very first (and only) thing I have ever done with docker…
Oh yes, duplicati is literally the paragon of the worst backup solution in existence. And I’m not just saying that because we are on the competitors’ forum. Not sure why people keep using it. Maybe it pops up first in the search results. It’s unstable, slow, corrupts its own datastore all the time, let along does not have a stable version. What kind of decision was to EoL the stable 1.x version without having a stable replacement? Anyway.
Duplicacy is not without its own quirks, but none of those result in data loss, so there is that.
You can definitely add pre-backup and post-backup scripts (do you know how to find the location where to place them?) and run stuff… I’m sure you’ll like duplicacy’s performance and resilience – lack of locking database and CAS approach to managing snapshot data is helping a lot – many modern tools picked the same approach, restic and kopia being other notable examples.
I’m unsure what mounting named volumes to host would solve for me. I think I am sticking to my original solution, but I don’t know where to put the scripts and in what format?
You could run duplicacy as a service on a host, get access to filesystem snapshots without giving a container excessive privileges and avoid having one container control the docker host
The temporary folder defined in the web Ui settings page and by default mapped to /cache folder contains temporary repositories that the web version created to run CLI from. Web version a of today does not support specifying the scripts, so you would need to put them there manually. The scripts go to .duplicacy/scripts folder. That .duplicacy folder would be somewhere under /cache/localhost/0, where number is index of the backup job. That’s the main bit. For other operations it may be elsewhere — like localhost/all.
The script file is just any executable named pre-backup and post-backup. If pre-backup returns failure backup will be aborted.
(Writing from memory so I may miss some details — like whether - is needed in the script names or whether there is about sub folder under /caches before localhost)
Edit: Once you find the correct location for .duplicacy folder (it can also be looked up in the first few lines of any backup log for the task of interest) then follow this Pre Command and Post Command Scripts
Hi,
sorry for digging up this old thread. I’m using your container and i’m trying to figure out a thing. In the container description it’s stated that the content of /cache can be safely deleted. So if i do that then i’ll lose also my scripts?
Actually this is what i have:
/srv/dev-disk-by-label-HC2/AppData/duplicacy/cache/localhost/1/.duplicacy# ll -a
total 16
drwx--S---+ 3 root root 4096 Jun 29 01:00 .
drwx--S---+ 3 root root 4096 Jun 29 01:00 ..
drwxr-S---+ 3 root root 4096 Jun 29 01:00 cache
-rw------- 1 root root 352 Jun 29 01:00 preferences
So in here i should create a new dir called ‘scripts’ and put my pre-backup script in there?
Thanks!
Yes, and yes. “safely deleted” means the duplicacy-web won’t care if you do, nothing you configured in the UI will be lost. If you made some modifications outside duplicacy-web ui there and then delete the folder – then of course those will be lost.
Putting scripts manually to temp folders is a bit of a hack, duplicacy-web shall support it properly in the UI to make it reliabole.