Re: [Duplicity-talk] Duplicity Reliability Questions

[sophana]

I'm actualy testing duplicity, that I discovered not long ago.

First, I don't think that your script and duplicity are comparable.
duplicity handles a distant incremental backup through ftp or some other
protocol.
I'm not sure rdiff backup (that I don't know well) can handle
incremental backup with a distant storage without reloading everything.

Duplicity seems to work fine for current tasks.
I have found some minor problems actualy: when a single ftp transfer is
broken, the whole backup is stopped and duplicity does not retry
anything. Then you have to restart from the beginning, leaving the
already transfered files unused. There is a cleanup option that works.

I did some restores, it went OK.
I'm actually testing nightly incremental backups of my sql database with
an history of 8 days long. the backups are ok.
Restore last and at a specific date works. Haven't tested restore
integrity yet. Now i'm calculating a full md5sum before backuping. Will
remake tests soon.
Also have to try how it behaves with --remove-older-than 8D option, and
see if the backup does not grow too much.

Conclusion: seems to be a really GREAT tool. My test will continue.
Many thanks for the author and the contributors.

The features I would like:
transfer retry: it would be cool to retry 2 or 3 time when a ftp
transfer is broken with an increasing time wait.
redundancy: storing the columes on multiple ftp servers with .par files
(the one that are used in binary newsgroup). dibs actually has a similar
behaviour but it is not working.

When I will have some time one day, maybe I'll try to get involved in
this great tool.

Regards
Sophana


Dustin Brewer a écrit :
> Hello,
>
> I'm trying to decide between using Duplicity and using my own creation
> of scripts + rdiff-backup.
>
> I originally found rdiff-backup, and wrote some scripts to use it with
> gpg. Lets just call my script gpg-rdiff-backup. Here is an example:
>
> To Backup:
> rdiff-backup school_work school_work.backup
> tar -c school_work.backup | gpg -e -o school_work.backup.tar.gpg
> find school_work.backup -type f -exec shred -u '{}' \;
> rm -rf school_work.backup
>
> To Restore:
> gpg -d school_work.backup.tar.gpg | tar -x
> rdiff-backup <Restore commands here>
> find school_work.backup -type f -exec shred -u '{}' \;
> rm -rf school_work.backup
>
>
> Now the reason I bring up my gpg scripts for rdiff-backup is because I
> recently found Duplicity. I've found it to work well, but I noticed it
> doesn't seem to be in active development, has less features than
> rdiff-backup (which I may or maynot ever use), and states on the front
> page that there are known bugs.
>
> I wonder, how reliable is Duplicity compared to rdiff-backup? Can
> anyone provide some input?
>
> Some notes about the two that I've made (with regards to the example)
> gpg-rdiff-backup vs duplicity:
>     * gpg-rdiff-backup has a set of commands (in a shell script) vs a
> single command
>     * gpg-rdiff-backup vs duplicity wrt end-filesize is roughly equal
> (~48MB for the example)
>     * gpg-rdiff-backup vs duplicity wrt to total-time (for the
> example) is +4 seconds longer for gpg-rdiff-backup.
>
>
> -- 
> Dustin Brewer
> address@hidden
> PGP Key: http://www.thenullpointer.net/pgp/
>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>