I now moved asynchronous-upload-folder and tempdir to the RAM-Disk with the help of the ImDisk Toolkit. Started the backup again, already saw a slight improvement in speed but still with write operations to my source SSD with peaks up to 15MB/s.
Then I also moved the database file to the RAM-Disk. This gave me another performance improvement and the SSD write speeds were in the low KB/s and never exceeding 1MB/s. You just have to make sure to not forget to move the database file afterwards to not loose it. For the future incremental backups I will probably just leave it on the SSD.
Overall the backup was more than 30% faster even though the destination is my really slow external HDD connected via USB.
Before: ~2:30h
Now: ~1:40h
What I have to add is that I used the opportunity to increase the block size from 100KB to 500KB which probably also increases the speed slightly, but I don’t think that makes much difference.
Just to throw one more anecdote on the pile. I have been using the ImDisk Toolkit with Duplicati for several years. The way I have it set up is this:
I use the RamDisk Configuration tool to create a RAM disk. You can assign it a drive letter (R: by default), or you can give it a mount point, which is what I use (C:\Apps\Temp-Ramdisk). I also have it configured to Allocate Memory Dynamically so that RAM will be used only when it is needed and will be released when it isn’t needed any longer. I also have it set up to Launch at Windows Startup.
Then, in Duplicati the only parameter I have set is to set the tempdir setting to be the mount point of my RAM Disk. That is all, I don’t use before/after scripts.
The result is that Duplicati will store all of the intermediately created files in RAM instead of writing them all to disk, saving wear and tear on SSDs. This is especially true during the creation of brand new backups, and also during the Compaction operation which downloads, writes, and then rewrites a lot of data during the process.
What it does not do is save any disk operations that are related to the Duplicati database… mostly because I was never courageous enough to move that to the Ram Disk. In theory you can set up the ImDisk toolkit to save the contents of your RAM disk storage periodically, making it “persistent”, but that seemed a bit too rickety to me.
Gotta agree with that. The database has to always match the Destination. People get in trouble when restoring a stale database from an image backup and trying to do things, which likely leads to a repair being run, which likely results in Duplicati damaging the destination to make it match the stale records.