Duplicity

Duplicity does not recognize Network down - full backup is not complete

Asked by Paul Bernet

Hi,

We are using duplicity 0.6.21 on ubuntu 10.04 LTS.
In order to simulate a temp network problem, we restart the network interface during a full backup like this:

#!/bin/bash
echo "Stopping network interface..."
ifconfig eth0 down
echo "...stopped"
echo "Sleep for 30 seconds"
sleep 30
echo "Start network interface..."
ifconfig eth0 up
echo "...started"

Duplicity does not notice that the network was down:
- there are no messages in the duplicity log and
- restoring such a backup shows that the backup is not complete

What is the best practice here? I thought about:
- I am missing something obvious and duplicity does handle this situation
- Monitoring the Network with NRPE
- Using the "verify" option after every full/diff backup, though our backups are huge (up to 700 GByte)

Thanks for your help!
Paul

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
Paul Bernet
Solved:
Last query:
Last reply:
Revision history for this message
edso (ed.so) said : 		#1

> Duplicity does not notice that the network was down:
> - there are no messages in the duplicity log and
> - restoring such a backup shows that the backup is not complete

if the backup is incomplete then duplicity should have finished with an error exit code and the log output should show the upload error.
i guess your duplicity process is still running and trying to retry (by default usually 5 tries wait 10s).

> What is the best practice here? I thought about:
> - I am missing something obvious and duplicity does handle this situation

see above

> - Monitoring the Network with NRPE

how would that help duplicity?

> - Using the "verify" option after every full/diff backup, though our backups are huge (up to 700 GByte)

generally a good idea. you should do that frequently to ensure your backups are proper. note: there will be a switch --compare-data in the next release, to allow you to actually compare backed up data against an also saved checksum

..ede

Revision history for this message
Paul Bernet (paul-bernet) said : 		#2

Hi,

Thanks for your quick reply. I forget to mention that in our case duplicity is coping the backup to a mounted smb share:
mount -t cifs "${UNC}" "${MT_POINT}" -o "iocharset=utf8${LOCAL_USER_OPTION},dir_mode=0777,file_mode=0777,rw${USER_OPTION}${PASSWD_OPTION}${DOMAIN_OPTION}"

Currently the share is on a Synology NAS.
Using this setup there is currently no error in the logs.

We need to do further research, if this behaviour occurs as well if we mount a Win7 share and if duplicity returns with an error code.

btw. using a checksum to verify sounds like a good idea, when is the next duplicity version planned?

Kind Regards
Paul

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

>btw. using a checksum to verify sounds like a good idea,

just had a look at the --compare-data option for verify again. it'll actually compare against the file's original, not the saved signature. sorry.

>when is the next duplicity version planned?

not to soon i guess. Ken, the maintainer, is currently very busy professionally.

..ede

Revision history for this message
Paul Bernet (paul-bernet) said : 		#4

To wrap this up:
- I am able now to detect the duplicity exit codes, see: http://duplicity.nongnu.org/epydoc/duplicity.log.ErrorCode-class.html
- In the case above a Network-Downtime of less than 45 seconds does not affect duplicity: Full- and Diff-Backups return with exit code 0 and the backup is usable and can be restored.
- A Network-Downtime above around 45 seconds does affect duplicity: Full- and Diff-Backups return with exit codes 30 or 50 - the (old) backup is usable and can be restored.
- The default tcp timeout on ubuntu is 60s and probably the default smbclient 3.4.7 timeout is 20s

Thx again for your help
Paul