[Dirvish] Dirvish speed and security

[Brian]

Leopold Palomo Avellaneda wrote:
> A Dilluns 26 Maig 2008, Keith Lofstrom va escriure:
>> On Mon, May 26, 2008 at 03:31:01PM +0200, Leopold Palomo-Avellaneda wrote:
>>> I'm using dirvish 1.2.1-1, from a debian etch. I have created my vaults
>>> and configured and running the complete system. I have a nfs mount where
>>> I put the backup. It simply works.
>>>
>>> Howeber, I have a very poor transfer rate. To create the init backup I
>>> need two days to transfer about 90G, and some days, if we have a lot of
>>> modifications, the dirvish have not finished their work, so, when we work
>>> again the backup is not finished occasioning:
>> If your data rate is low, you may want to make more, smaller images.  That
>> way you can do the initialization in multiple steps.  You should also
>> arrange your data to minimize the backup effort - dateext for logrotate,
>> maildir instead of mbox mail storage, etc.  Lastly, if your transfer rate
>> is very low, consider running backups less often than once a day.  If you
>> are using smaller images, then you can run them in two sets on alternate
>> days, perhaps using two different master files selected by scripts from
>> cron.
> 
> Ok,
> 
> but why it's so slow? I would like to backup home and I don't want to make 
> different sets. And I would like to backup once a day. There's no another way 
> to do it?

Hi, I am running dirvish on an NSLU2, which has very little RAM. Some backups
were very slow. Investigating I found that the machine being backed-up was doing
nothing but paging because the file list being built was too large for its RAM.
You can use the --progress parm on rsync to see just what it is doing and when.
Try just entering the rsync command that dirvish runs yourself and add the
parm there as a test.
If the size of the filelists is too large, I dont think it will be better on
successive runs. Whereas if the xfer of the 90GB is the problem, once that has
been done once then looking at the "literal data" in the log will tell you how
many bytes of backup data were actually sent over the link between the 2 rsyncs.
That should then be less on successive days.

At least thats how I understand it.

Cheers Brian