[Top][All Lists]

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

Re: [Duplicity-talk] zfec vs. par2 (and, hello there!)

From: edgar . soldin
Subject: Re: [Duplicity-talk] zfec vs. par2 (and, hello there!)
Date: Tue, 04 Nov 2008 15:20:28 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

only one file can be processed at a time.

It would be easy to change the cmdline zfec tool to process multiple files, but what should it do with them? I guess maybe "for FILE in a b c d e ; do zfec $FILE ; done" or else "tar cjf a.tar.bz2 a b c d e && zfec a.tar.bz2" would probably be the best way to handle multiple files.

this was more a remark. You are totally right on this. It was rooted in duplicity use case, where the creating of parity, usually would have to be applied on a bunch of files . As ftplicity coder I just played with the idea to add zfec to existing duplicity repositories, backup data. But as duplicity is also handling the upload (what I want to keep) there is no way. It would be possible though, if I had a script that would rsync locally created duplicity data to an external backup storage.

I don't know about the inner API as I am not python literate ... regards ede

The zfec README.txt describes the API. There is a function called "encode()". You tell it which block numbers to produce. If you tell it numbers which are >= K then it produces only "check blocks" a.k.a. "parity blocks" a.k.a. "secondary blocks", and produces no file data blocks.

I will read that part, if only out of interest as I don't see myself patching duplicity. But generally I'am very interested that future versions support protection against minor data errors caused by transmission or failing backup storage.


Thanks a lot  ..ede

reply via email to

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