duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Syntax of duplicity verify command


From: Aaron
Subject: Re: [Duplicity-talk] Syntax of duplicity verify command
Date: Fri, 5 May 2017 22:38:00 +0100

Thanks Kostas,

I agree with you (and ede). I have created a bug report for this:

https://bugs.launchpad.net/duplicity/+bug/1688657

I am about to do some work on the command line parsing side (Bug #1480565), so can add this to my list.

As ede said, the verify command has evolved unhelpfully over time and the need for a target in verify is a hangover from that.

Kind regards,

Aaron


On 25/01/17 11:05, edgar.soldin--- via Duplicity-talk wrote:
hey Kostas (again:)),

yeah duplicity's verify is actually a bastard command that verifies the possibility to restore _and_ allows to compare to the source folder. older versions did the second automatically, for newer versions you have to enable --compare-data for that.

the source folder argument is there and needed for the second part, that is why it is still needed.

the functionality should probably be separated into a new compare command in the future, but so far nobody did so.

..ede/duply.net

On 23.01.2017 21:16, Kostas Papadopoulos wrote:
Dear duplicity devs & users,

If the duplicity "verify" command just validates the integrity of the backup against the signatures of the sigtar files found at source_url, isn't then the requirement of a second argument (target_directory) unnecessary and confusing?

Currently, if the specified target_dir doesn't exist, then duplicity "verify" exits with an error. If the specified target_dir is empty, it works fine. And if the specified target_dir has other random files (unrelated to duplicity), the number of "files compared" is somehow increased (e.g. from 75 to 140 in the example below)

/root/docs was the backup original source dir
/tmp/t is non-existant dir
/tmp/tt is empty dir
/tmp contains other stuff too

    address@hidden:/tmp# duplicity verify --name duply_test-local --encrypt-key AABBCCDDEEFFAA --sign-key AABBCCDDEEFFAA --verbosity 4 file:///tmp/backup-test-local /root/docs
    Local and Remote metadata are synchronized, no sync needed.
    Last full backup date: Mon Jan 23 19:00:45 2017
    GnuPG passphrase:
    Verify complete: 77 files compared, 0 differences found.
    address@hidden:/tmp# duplicity verify --name duply_test-local --encrypt-key AABBCCDDEEFFAA --sign-key AABBCCDDEEFFAA --verbosity 4 file:///tmp/backup-test-local /tmp/t
    Verify directory /tmp/t does not exist
    address@hidden:/tmp# duplicity verify --name duply_test-local --encrypt-key AABBCCDDEEFFAA --sign-key AABBCCDDEEFFAA --verbosity 4 file:///tmp/backup-test-local /tmp/tt
    Local and Remote metadata are synchronized, no sync needed.
    Last full backup date: Mon Jan 23 19:00:45 2017
    GnuPG passphrase:
    Verify complete: 75 files compared, 0 differences found.
    address@hidden:/tmp# duplicity verify --name duply_test-local --encrypt-key AABBCCDDEEFFAA --sign-key AABBCCDDEEFFAA --verbosity 4 file:///tmp/backup-test-local /tmp/
    Local and Remote metadata are synchronized, no sync needed.
    Last full backup date: Mon Jan 23 19:00:45 2017
    GnuPG passphrase:
    Verify complete: 140 files compared, 0 differences found.

I would imagine that a more readily understandable syntax would be a duplicity "verify" command with just one argument (duplicity verify ... source_url), and another duplicity "compare" command that would take two arguments (duplicity compare ... source_url target_directory [--compare-data]) and compare backup against the target_directory's files size/date and optionally content (when used with --compare-data).

Thank you in advance for your consideration,
KP

On 04/23/2015 03:12 AM, Kenneth Loafman wrote:
The signatures in the sigtar files.  Think of them as uber-large hashes.

On Wed, Apr 22, 2015 at 5:25 PM, Kostas Papadopoulos <address@hidden <mailto:address@hidden>> wrote:

    On 4/22/2015 2:51 PM, Kenneth Loafman wrote:
    Actually, he has to use --compare-data for verify to look at the local data, otherwise verify just validates that the backup is intact and is not corrupted.

    Thanks for the clarification, but then isn't the output of "verify" a bit misleading?

        ...
        Last full backup date: Sun Apr  5 15:55:20 2015
        Verify complete: 73 files compared, 0 differences found.
        --- Finished state OK at 01:33:47.897 - Runtime 00:01:20.821 ---

    Against what are those 73 files compared?

    Br, KP



      
_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk


reply via email to

[Prev in Thread] Current Thread [Next in Thread]