Christian Völker wrote:
>
> First, my environment:
> 28 hosts to back up. Mostly idle machines with minor services (so no big
> databases and so on). Partially fileserver with only little daily
> changes. So I expected not too much daily changes on the pool.
> I want to copy the pool to a remote location after testing is done.
> 
> So I used an USB 2.0 disk as "second backup device" to store the copied
> pool.
> The pool itself is aprox 540GB in total. And is not growing any more-
> even not all 12 full backups are stored.
> 
> My first attempt was rsync the pool. This tooks ages.
> Second attempt was to "dd" the whole device (with less frequency), but
> for the size of the pool, took ages, too.

With reasonable fast drives, this should take 2 or 3 hours for disks under 1TB. 
  USB would slow it down some compared to SATA.

> Third try was to use "dump" for this hoping it would transfer only
> changed blocks after the initial dump. No way. After one day it
> transferred 300GB (!). I thought, dump might not bee a good solution...

I suspect dump sees the link count change in the pool file's inode as you 
expire 
  a backup and add a new one as an update.

> Last attempt now was to move the pool device to a VMware virtual disk
> and let rsync run over this file. Thus rsync backing up the block
> device. Best attepmt, I thought. Result: rsync transfers after the first
> run  ~300GB, too.

I haven't tried that approach but always thought it should work.  Can you try 
using the vmware option to split the virtual disk into files of 1 or 2 GB? 
Perhaps rsync has trouble finding resync points after a change on such a large 
volume.  Also you might be able to use vmware's snapshots to see how much 
really 
is changing.

> So what does this mean to me?
> 
> Looks like on my pool BackupPC changes approx two third of the whole
> pool daily. So if I would transfer to a remote site I'd need to transfer
> 300GB daily!
> 
> Can anyone confirm BackupPC changes so many data inside the pool DAILY?

That will depend on your data.  Large files that change a little (growing logs, 
unix style mailboxes, databases, vmware images, etc.) can cause a big turnover 
but files that don't change at all should remain in the pool with nothing but 
the link count changing (which causes a ctime change as a side effect).

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/