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

Asked by George Talev


I have two external harddisks.
Every time before running Deja Dup backup I mount one of the two disks at /mnt/backup, which is the backup location for Deja Dup. So on every backup session the other disk is mounted.
Will Deja Dup properly detect the last backup timestamp based on the files in the currently mounted HDD and then properly create an incremental backup files, so that on every external HDD I have valid archive?

If somebody else is doint My goal is not to change WHAT I archive, just to change WHERE I archive.
In other words, will my scenario with the two harddisks work with Deja Dup?
If somebody else is doing something different to get similar result, I would be happy is some experience is shared.

Question information

English Edit question
Déjà Dup Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Michael Terry (mterry) said :

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?

Revision history for this message
ceg (ceg) said :

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.

Revision history for this message
ceg (ceg) said :

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.

Revision history for this message
ceg (ceg) said :

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

Revision history for this message
ceg (ceg) said :

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

Revision history for this message
Michael Terry (mterry) said :

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.

Revision history for this message
ceg (ceg) said :

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.

Revision history for this message
Worzel (edwardsw) said :

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.

Revision history for this message
ceg (ceg) said :

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

Can you help with this problem?

Provide an answer of your own, or ask George Talev for more information if necessary.

To post a message you must log in.