Existing archives in destination check?

Features
6

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.

  1. Yes - having a destination check for existing duplicati- files is a good idea.
  2. Yes - encouraging separate folder for each backup is a good idea, but it doesn’t always happen (my guess is usually not on purpose).
  3. 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 the AAAHFSVBZF 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… :smiley: