Re: Re: [Duplicity-talk] Integrity check

[Gabriel Ambuehl]

On 17.9.09 address@hidden wrote:

> 
> not if the data is on another machine anyway or changed so much 
> inbetween that you end up with a list of verify errors, you are not even 
> remotely interested in plus the time for actually comparing the data. 
> All you want to know is: is the backup data intact, from this point of 
> view a totally different task.

But you would catch that during a verify run, wouldn't you? In essence you 
simply propose to leave away the last step of verify, right? Should be simple 
enough to implement...

> Then a little script is all you need. But doing it remotely is totally 
> not duplicity from my point of view. Why? Because if I use encryption 
> for my backup, then I don't trust the backup space. If I don't trust the 

Yes and no. I might decide I trust the guys to maintain a stable system yet do 
not want them to see my financial records. In some industries  you are even 
required by law to ensure the latter part (the former can generally be ensured 
by proper SLAs).

> backup space then I don't decrypt my data there or create/check hashes 
> there that somebody might tamper with and gives me the illusion of nof
> security while my data is already gone.

Decrypting it on the remote really is silly but gpg --verify would have its 
uses. 

> But I see that someone might trade security against traffic if the 
> connection is very slow. I simply wouldn't do large backups with a line 
> that slim, but that's me.

It may not necessarily a slow rather than an expensive line. Think non-flatrate 
3.5G which is said to be quite fast (I've never really seen it though, best 
I've ever seen was 1.5mbit and 0.3mbit average is more like) on a good day but 
is nearly always expensive...