| 2011-03-29 13:40:45 |
ceg |
description |
It may be a desired option that deja-dup checks the UUID before starting a backup *automatically*. Howerver, it should just give a warning when the mountpoint is there but the UUID does not match, and allow to proceed anyway (manually accepting).
The backup files could just have been moved to a larger disk, or one wants to alternate between disks, or backup to additional disks, mounted at the same mountpoint.
Nowadays, the mountpoint is often determined by a filesystem label. If the user has explicitly given the same label (e.g. backup-disk) to another disk with a different UUID, deja-dup should not need to stop, warn and wait for confirmation. Just start the backup in this case.
(With a fix for duplicity's Bug #743820, duplicity will not break on url changes (different mountpoint, hda/sda etc.) anymore. So, the restriction to a fixed url/mountpoit will also be gone in duplicity.) |
It may be a desired option that deja-dup checks the UUID before starting a backup *automatically*. However, it should just give a warning when the mountpoint is there but the UUID does not match, and allow to proceed anyway (manually accepting).
The backup files could just have been moved to a larger disk, or one wants to alternate between disks, or backup to additional disks, mounted at the same mountpoint.
Nowadays, the mountpoint is often determined by a filesystem label. If the user has explicitly given the same label (e.g. backup-disk) to another disk with a different UUID, deja-dup should not need to stop, warn and wait for confirmation. Just start the backup in this case.
(With a fix for duplicity's Bug #743820, duplicity will not break on url changes anymore (different mountpoint, hda/sda etc.). So, the restriction to a fixed url/mountpoit will also be gone in duplicity. Deja-dup should just rely on duplicity to check for the correct backup ID and integrity.) |
|
