I agree with pretty much everything being said - but I think I’m not making myself clear, so I’ll try again with some examples. Please let me know if this is actually what you all got from my original description.
- Yes - having a destination check for existing duplicati- files is a good idea.
- Yes - encouraging separate folder for each backup is a good idea, but it doesn’t always happen (my guess is usually not on purpose).
- I’m wondering why we can’t use the name of the local sqlite file already created by Duplicati (apparently with a random name) as a distinguishing feature of the remote files. For example, locally I have
AAAHFSVBZF.sqlite
so remotely I would have files like the following, all obviously related to theAAAHFSVBZF
backup:
a.Duplicati-AAAHFSVBZF-20171016T024101Z.dlist.zip.aes
b.Duplicati-AAAHFSVBZF-b00ec9bc9ab53459ca77b81f6fd418ef3.dblock.zip.aes
c.Duplicati-AAAHFSVBZF-i0a2fd13f21414b5838cd007193217559.dindex.zip.aes
In my mind this would:
- simplify cleanup when deleting jobs (just delete all files starting with
Duplicati-AAAHFSVBZF-
) - support multiple backups in one folder without needing user action to set a backup name
- allow for easier identification of “all” related backup files (local and remote) in instances where manual maintenance (such as moving destinations) is necessary
Oh, and just because I bumped into this so recently after replying to the above…