Will Deja Dup handle different backup media mounted on the same backup location?

Interesting. Deja Dup actually goes to some length to avoid doing what you want. :) It stores the UUID of the disk and only backs up to the drive if the UUID matches.

If it didn't do this, and just backed up to a path of /mnt/backup, it would do what you want -- incrementally backup compared to what was on the disk. That is, all backup information is stored on the disk (with a local cache, but I believe the disk's metadata would be preferred and used in this situation).

I don't believe there's a way to do what you want, unless you can manually make the UUID's match? Can you edit those?

Why did you implement this UUID restriction? Could you please explain the bad thing, that could happen and you are trying to prevent?

I ask because checking the UUID seems to give trouble when moving the backup files to another location, larger disk etc.

Currently, I don't see the reason. It just seems weired for me, if an app is only able to work with the files it produces if they are stored at a specific location/path.

Maybe DD should name the backups and use duplicity's --name option?

Explicitly naming the backup will prevent duplicity from using a hash of the target location as the name, and allows duplicity to continue to work without manually fiddling with url hashes when the target dir (url) changes.

Actually, duplicity should probably default to generate a UUID for the name of the backup, if none is specified, instead of an url hash.

...and save that UUID in the backup location as well.

To answer your question of why the UUID restriction: it was merely to support OSes that didn't mount external drives with the UUID in the path. You know, old systems that mount two different UUID machines in /media/disk1 or whatever.

I'm not sure how uncommon such systems are, but I suspect they are still in use.

By support I guess you meant to recognize the media (path) as containing a previous backup before doing automated backups to a destination, right?

Shouldn't that be possible directly, without locking on a filesystem UUID, by looking for the manifest at the destination and comparing it to the one under ~/.cache/deja-dup?

For duplicity itself I opened Bug #743820 to use unique IDs for backups (instead of hashes of the url, since the url can change) so it can support changing mountpoints/urls. When that is done, deja-dup could look for the backup's ID instead of for the manifest.

Looking for an unrelated filesystem UUID seems unnecessarily restrictive to me, it breaks with changes in the mountpoint/url, but maybe I didn't understand the reason just yet.

I have the same use case requirement, although in my case I rotate more than 2 USB disks for my backup.
With the current "feature" I cannot automate my backup and I'll have to go looking for another solution.

As an alternative feature, which would be beneficial in other ways, would it be possible to make several different backup sets or profiles? Each profile could be scheduled at different times, have different contents, and different locations.

I could use that feature to both solve my multiple external disks problem (I would have one set for each UUID) and also enable me to do an online backup of a smaller amount of the most critical data.

Worzel, you may enlist yourself as affected by Bug #324631 to be reopened.