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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
