Duplicity

What diagnostics are provided by Duplicity?

Asked by David Arnstein

During a backup or restore operation, what diagnostics are provided by Duplicity? Do the diagnostics go to stderr? To a fixed log file location? I am interested in obvious problems like "backup media not available," "lost connection to backup media," and so forth. I am also interested in unusual conditions such as internal errors.

Thank you!

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
edso
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
edso (ed.so) said : 		#2

>During a backup or restore operation, what diagnostics are provided by Duplicity? Do the diagnostics go to stderr?

errors yes, notification and such go to STDOUT

> To a fixed log file location?

check the manpage on how to achieve that
http://duplicity.nongnu.org/duplicity.1.html

>I am interested in obvious problems like "backup media not available," "lost connection to backup media," and so forth. I am also interested in unusual conditions such as internal errors.

often duplicity error messages are not very helpful. just error stacks or sometimes assertion errors. but one by one we are trying to improve the situation.
having said that, please try duplicity out and come back with suggestions/patches.

ede/duply.net

Revision history for this message
edso (ed.so) said : 		#3

added answer

Revision history for this message
edso (ed.so) said : 		#4

btw. there is also a machine readable log descriptor similar to what gpg has, in case you are interested in such .. ede

Revision history for this message
David Arnstein (arnstein) said : 		#5

Hello ed.so,

What I am looking for is a reliable indicator for the situation where a file should have been backed up, but was not. Typically, this would be a problem with user environment, rather than an issue with Duplicity itself.

I consider this to be an essential feature for a backup system. I am concerned about this because I am aware of at least one other OSS project that ignores such errors. The last time I looked, Ubuntu's sbackup called tar(1) to do the real work. Sbackup piped both stdout and stderr to /dev/null.

Please don't do that to duplicity!

Revision history for this message
Best edso (ed.so) said : 		#6

On 03.11.2011 19:05, David Arnstein wrote:
> Question #175163 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/175163
>
> David Arnstein posted a new comment:
> Hello ed.so,
>
> What I am looking for is a reliable indicator for the situation where a
> file should have been backed up, but was not. Typically, this would be a
> problem with user environment, rather than an issue with Duplicity
> itself.
>
> I consider this to be an essential feature for a backup system. I am
> concerned about this because I am aware of at least one other OSS
> project that ignores such errors. The last time I looked, Ubuntu's
> sbackup called tar(1) to do the real work. Sbackup piped both stdout and
> stderr to /dev/null.
>
> Please don't do that to duplicity!
>

duplicity issues statements like e.g. this, if a file could not be accessed

Error accessing possibly locked file /srv/www/vhosts/host.net/file

but does not break or exit with an error code.

why don't you just setup a test and check how duplicity behaves if you make files inaccessible and if the reaction suffices your needs?

..ede/duply.net

Revision history for this message
David Arnstein (arnstein) said : 		#7

Thank you ed.so.

Revision history for this message
David Arnstein (arnstein) said : 		#8

Thanks edso, that solved my question.

Revision history for this message
Otto Kekäläinen (otto) said : 		#9

Hello,

Besides error logging, I am as an administrator also interested in knowing that everything was OK in the last run. I'll play around with the --log-file and --log-fd options.

Another related thing: I'd like to get the log information at the backup target, not source.

Compare to rdiff-backup: in the target directory, there is a subdirectory "rdiff-backup" that contains a few log files. Is is possible to write a log file to the target dir in Duplicity at the moment somehow?

Revision history for this message
Kenneth Loafman (kenneth-loafman) said : 		#10

That is a good idea. Please submit it as a feature request.

It would have to be stored locally, then transferred over at close,
but the idea is sound.

...Thanks,
...Ken

On Thu, Apr 4, 2013 at 1:46 AM, Otto Kekäläinen
<email address hidden> wrote:
> Question #175163 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/175163
>
> Otto Kekäläinen posted a new comment:
> Hello,
>
> Besides error logging, I am as an administrator also interested in
> knowing that everything was OK in the last run. I'll play around with
> the --log-file and --log-fd options.
>
> Another related thing: I'd like to get the log information at the backup
> target, not source.
>
> Compare to rdiff-backup: in the target directory, there is a
> subdirectory "rdiff-backup" that contains a few log files. Is is
> possible to write a log file to the target dir in Duplicity at the
> moment somehow?
>
> --
> You received this question notification because you are a member of
> duplicity-team, which is an answer contact for Duplicity.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~duplicity-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~duplicity-team
> More help : https://help.launchpad.net/ListHelp