I want to make sure the backups don’t really wear out my SSD’s rather quickly so I’m looking into making sure cached data is written to a directory backed by RAM on my host.
I’ve mapped /tmp of the duplicati docker container to a folder in /tmp on my host (which resides in RAM).
If I’m not mistaking any cache/processing operations that duplicati (docker version) does are (by default) in /tmp, so this should effectively push everything in RAM on my host right?
Now I’m still seeing about 1/3 of total backup size being written to flash storage, so I’m wondering… Am I missing a location that duplicati uses to maybe compress or encrypt blocks?
Note that my total RAM usage on the host is at 57% max so it should not be swapping to disk or so.
The default (for both) is /tmp on Linux from what I can tell. So if you’ve mapped /tmp in the docker container to a RAM drive on your host you should be fine.
That’s what I thought, strangely I’m still seeing a quite high number of writes outside of RAM space, therefore this question.
If someone else has a contribution I’m still open
You could conduct more experiments if you like, for example by moving the Database of a test job. Temporary Files Used By SQLite sometimes are next to the DB, other times they’ll follow TMPDIR.
Reportedly, swap for the Docker is the host OS swap, and possibly that’s contributing some writes. iostat -p can give statistics down to the partition level if that helps. I don’t know what other tools do.
Jus wanted to report back on this.
I did not had the time to look into this further, but as @ts678 said I did notice a lot of write activity regarding SQLite Journal files on the persistent storage, this might indicate the SQLite is writing outside of the /tmp dir for temporary matters.
Thanks for the suggestions both!!
I will surely check this out when I see time, for now marking as resolved.
