Re: integrity check - Re: [Duplicity-talk] Some questions from a new user

[Kenneth Loafman]

address@hidden wrote:
> 
>>>
>>> Idea: integrity check command
>>>
>>> The reason for not doing full backups regularly is the slow upload
>>> channel. But usually this combines with some pretty fast download (not
>>> always but often). Before deleting backups the leftovers should be
>>> checked for integrity. We could verify the last full against the data,
>>> but this does not make sense as a portion of it might have changed and
>>> would show up.
>>> As far as I understand the combination tar/gz/gpg already catches
>>> defective data, although very conservative by breaking the
>>> verify/restore process running.
>>> Therefor - wouldn't it make sense to introduce a integrity check that
>>> simply does a verify, receiving and unpacking without actually comparing
>>> data to the source. Additionally if there are checksums already in the
>>> backup they could be used. If not they can be added in the future and
>>> used then.
>>> @Ken: Are there checksums?
>>>
>>> This check could be run instead of regularly full backups to assure us
>>> that the old backup data we rely on is still intact.
>>>
>>> Command could be: check-integrity [last-full|<age>]
>>
>> Duplicity does not have anything running on the remote system in order
>> to do an integrity check.  To check the data on the remote, all of it
>> would have to be downloaded and validated.  You can get the same by
>> doing a normal duplicity verify command.
>>
> 
> exactly my point .. same as verify but without comparing to the source
> _and_ if possible, not breaking on defect volumes.
> 
> Possibly combined with a check against checksums.
> @Ken: Are there checksums in the backups?

In the manifests, yes.

...Ken

signature.asc
Description: OpenPGP digital signature