restore option does not write to logfile about duplicity-backup.sh

[zertrin]

Hum have you tested it? calling the duplicity_backup function should normally log to file (see line 380).

For the second question, yes, see issue #5 ;)

[ilium007]

Ahh - I missed the -t option !

Restoring one file from took an inordinate amount of time but it did restore and this is what I got in the log:

Email alert sent to [email protected] using ssmtp
Removing lock. Exit code: 0
--------    START DUPLICITY-BACKUP SCRIPT    --------

Attempting to acquire lock /var/log/backup.lock
successfully acquired lock.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Jan  2 18:52:57 2013
--------    END DUPLICITY-BACKUP SCRIPT    --------

[zertrin]

Hum,

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Jan 2 18:52:57 2013

correspond to what is logged from duplicity's output.

Maybe you should run the script in dry-run mode to see which duplicity command is actually called, and then try to run it yourself (not from the script) to see if the problem is duplicity not giving much output or our script not logging correctly...

[ilium007]

running with set -x now

On 02/01/2013, at 9:43 PM, zertrin [email protected] wrote:

Hum,

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Jan 2 18:52:57 2013

correspond to what is logged from duplicity's output.

Maybe you should run the script in dry-run mode to see which duplicity command is actually called, and then try to run it yourself (not from the script) to see if the problem is duplicity not giving much output or our script not logging correctly...

—
Reply to this email directly or view it on GitHub.

[ilium007]

Ok - it looks as though the restore option give no verbose output until you crank it up to 5, ie. duplicity -v5

Cheers

On 02/01/2013, at 9:44 PM, Brant Winter [email protected] wrote:

running with set -x now

On 02/01/2013, at 9:43 PM, zertrin [email protected] wrote:

Hum,

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Jan 2 18:52:57 2013

correspond to what is logged from duplicity's output.

Maybe you should run the script in dry-run mode to see which duplicity command is actually called, and then try to run it yourself (not from the script) to see if the problem is duplicity not giving much output or our script not logging correctly...

—
Reply to this email directly or view it on GitHub.

[zertrin]

Yep saw that too, although -v5 seems a bit too verbose... do you think we should force it anyway?

[ilium007]

Yes, I agree. Too verbose and I still don't get a list of files it has processed !

On 02/01/2013, at 10:34 PM, zertrin [email protected] wrote:

Yep saw that too, although -v5 seems a bit too verbose... do you think we should force it anyway?

—
Reply to this email directly or view it on GitHub.

[zertrin]

Ok then I'll just let it like that for now... It's more a problem with duplicity itself than of the script... Could be reported upstream.

When restoring something you'll usually check if the restored files are there anyway so I don't think it's very critical.

Moreover restore operations are not really meant to be a cron job so it shouldn't really bother not to have a verbose enough log per email...

I'll close it then. As always feel free to comment or reopen it if anything new happens :)

[ilium007]

Will do - thanks

On 02/01/2013, at 10:40 PM, zertrin [email protected] wrote:

Ok then I'll just let it like that for now... It's more a problem with duplicity itself than of the script... Could be reported upstream.

When restoring something you'll usually check if the restored files are there anyway so I don't think it's very critical.

Moreover restore operations are not really meant to be a cron job so it shouldn't really bother not to have a verbose enough log per email...

I'll close it then. As always feel free to comment or reopen it if anything new happens :)

—
Reply to this email directly or view it on GitHub.