[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: integrity check - Re: [Duplicity-talk] Some questions from a new use
Re: integrity check - Re: [Duplicity-talk] Some questions from a new user
Mon, 07 Sep 2009 09:24:37 -0500
Thunderbird 126.96.36.199 (X11/20090817)
>>> 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.
Description: OpenPGP digital signature
Re: [Duplicity-talk] Some questions from a new user, Jacob Godserv, 2009/09/07