duplicity-team team mailing list archive

[Peter Schuller <peter.schuller@xxxxxxxxxxxx>]

> If you agree with these changes, please let me know and I will file
> another bug suggesting the changes to the man page.

They sounds good to me, but Kenneth will be the final judge ;)

> As you have already made clear, there are two issues here. The first is
> what duplicity is meant to do. It sounds like we agree that it should
> provide a means of testing the remote archive files can successfully
> restore, without actually restoring and replacing your local files with
> the remote ones. If that is what the command is meant to do, I would
> suggest that the man page make that clearer, as set out above.

Agreed.

> The second issue is that it sounds as though it isn't currently doing
> that properly. A tool that purports to verify everything but doesn't do
> so is worse than no tool at all, so thank you very much for filing the
> bugs about the problems. Presumably I could write some script that ran
> through each file that was backed up, do a "--file-to-restore" to a temp
> file, compare that restored file to the original, delete that file and
> move on to the next one. That seems silly when it can be, and already is
> mostly, in duplicity itself. As far as you know, Peter, would
> duplicity's "verify" command (with your bugs fixed) give me an
> equivalent level of comfort as this imaginary script, or are there other
> issues with the "verify" option?

My understanding has always been that what you describe is the intent
of verify. As to whether it gives you the same level of comfort - is a
slightly different question. As I previously indicated I have tended
to do spot checks by actually restoring files rather than using verify
(though I've used verify too).

But I'd say that the *intent* certainly is that 'verify' should allow
you to rest easy.

In reality in addition to fixing the bug about cache penetration and
checking content, there should probably be tests that ensure that all
these things are checked now and in the future.

Disclaimer: My knowledge of the code is spotty, depending on which
parts of it I've worked on in the past. In the case of verify, I'm
essentially making assumptions based on general understanding of the
man page coupled with a general vague remembrance of the code.

But again, my expectation was certainly that it did verify all
contents. It could be that expectation was wrong; we still haven't
heard from anyone else in this thread. Though in either case, I think
said expectation matches what a 'verify' command *should* do,
regardless of original intent.

> I hope that I don't come across as critical. I love duplicity and that
> is why I'm keen to see it be the default backup program for everything
> (with the deja dup frontend or similar for desktop distributions).
> Unlike simply copying files to an external HDD and being able to just
> check the copy, duplicity files are like random chunks of data. So I get
> a little nervous that, despite my regular duplicity backups, I'll get
> caught out when I finally need to rely on the backups. There are enough
> bugs filed about failed restores to give me some slight hesitation.

Skepticism when it comes to backups is a good thing IMO, and something
we need more of in this world. Please don't apologize for that ;)

-- 
/ Peter Schuller