[Top][All Lists]

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

Re: [Duplicity-talk] duplicity fails to do incremental backups on Ubuntu

From: Travis H.
Subject: Re: [Duplicity-talk] duplicity fails to do incremental backups on Ubuntu Feisty
Date: Mon, 26 Feb 2007 23:17:24 -0600
User-agent: Mutt/1.5.12-2006-07-14

On Sat, Feb 24, 2007 at 09:33:05AM +0100, Michael Baierl wrote:
> The big problem seems to be that duplicity is not really supported

When I get my fileserver fully set up and have some room to start
doing online backups, I will probably start using duplicity, and given
that I am a python programmer (and cryptographer), and currently out
of work, I may take up some of the tasks here, time permitting.  If
someone who is familiar with the project could fill me in on the most
important problem areas, perhaps I could take care of some of them.

And yes, I use [k]ubuntu and FC in addition to many other OSes, so
should be able to help out on making this tool more robust and

I like the idea of pluggable mechanisms; that is, one should be able
to choose a "network transport" mechanism (ssh), an encryption
mechanism (gpg), and so on independently of one another.  If one is
unsuitable or causing problems, you should be able to substitute another
one without too much effort (IMHO).  This should apply to finer grained
subsystems too, such as "use timestamps to determine what has changed"
versus "use checksums to determine what has changed" and so on.

> me that it did not find any valid signatures... and sometimes there is
> the "broken pipe" error.

This happens when the program on the right of a pipeline exits before
the one to its left finishes writing.  I am going to guess that what
is happening here is that sftp is failing due to some sort of
temporary network problem, and so the commands in front of them are
generating this error.

It is caused by a program receiving SIGPIPE (Unix sends it that signal
when it tries to write to stdout after the reader has died) and can be
dealt with properly by trapping that signal and handling it as an
exception of some kind.

> Bad to say there are no alternatives out there - a tool that encrypts
> backups, does not waste bandwidth, creates small backup files, does
> incremental backups.... and ideally works with Windows and Linux :)

Bear in mind here that it's not enough to work with Linux if you want
to preserve all the file metadata and permissions as well; in Linux
ext2/3 alone, there are user/group/owner, change times, permissions,
ACLs, flags, SELinux contexts, and attributes.

It sounds like the major problems have to do not with actually
performing the task of backing up, but dealing with the variety of
error conditions, temporary failures, and unforseen cases (i.e.  one
system resets its clock during the backup) that one sees in
distributed systems like this.  The best policy seems to be to have
one mechanism that tries to deal with it as best it can (i.e. try
three times and then give up).  If the mechanism fails, it should be
simple enough that the error messages are clear and easy to interpret,
and the user should be able to then fix the underlying problem so that
the program works properly.  It may well be that no one mechanism is
suitable for all cases (for example, maybe you are backing up over
TCP/IP from a deep space probe and sunspot activity is affecting the
reliability of the network), but a single mechanism should be suitable
for most cases, and it shouldn't be too hard for the remainder of the
users to adjust it to suit their unique conditions.

Anyone who wants to make any comments about what they think duplicity
needs most, now is the time to jump in and have your voice heard; I'll
read over the comments from here.  If any developers would like to
state their current views on the program, and if they have enough time
to really devote to it, etc...  based on what I've seen here on the
list over the last year or so, it is either (a) working fine for the
developers so they don't spend much time making changes or (b)
(relatively) abandoned.  If the latter is true and I end up committing
some time to it, I will look into reviving it in the socially accepted
manner (trying to coordinate with the previous developers for a
passing of the torch, making sure that it is truly abandoned, etc.)

Good code works.  Great code can't fail. -><-
For a good time on my UBE blacklist, email address@hidden

Attachment: pgpTCssmp5Y6A.pgp
Description: PGP signature

reply via email to

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