-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Timothy J Massey wrote:
>
> But the ability to rsync collections of VMDK files to a remote host
> *is* appealing. Interesting...
>
> However, you could achieve the same thing in other ways without
> having to run BackupPC in a virtualized guest. You could simply
> use an rsync-like process for copying the block device to a remote
> (physical) host. Years ago someone posted a script that read a
> block device 64k (IIRC) at a time and did an MD5SUM on it and
> compared it with a remote block device (via netcat, again IIRC).
> If the blocks matched, they were skipped. If they didn't, the
> block was sent over. You could do something like that to a
> physical block device to achieve largely the same thing.
>
> Or, if you wanted to use actual rsync and you wanted to avoid block
> devices, you could do the same thing by using a (very large!)
> loopback file for your BackupPC pool partition on a physical server
> and a physical partition and rsync the file (after you stop
> BackupPC and unmount the partition). In fact, you could create a
> partition for your pool and create a single file that fills the
> entire device, and use that file as a loopback partition. In that
> case, you could very nicely use LVM tools to snapshot the outer
> partition and you could even restart BackupPC while the remote sync
> was taking place!
>
> How much performance do you lose using a loopback mount? It's
> *gotta* be less than the overhead of virtualization! I like that
> idea even better. But all it buys you is being able to use rsync
> directly on a file instead of coming up with a way to copy a block
> device in an rsync-like manner... And, to me, that's the best way
> of all.
>
> Of course, now we've come full circle: how do you copy a physical
> block device in an rsync-like manner? :)
Why not just use lvm to take a snapshot, use dd to take 2G chunks (or
whatever size you want) or even cat /dev/blah | cut -c 2G etc... once
split into files of the right size, do they rsync to the remote site.
Downsides:
1) You need LVM to create the snapshot (or else you need to stop
backuppc while creating the split files)
2) You need double the storage space to store your pool data locally
as split files
3) You need double the storage space on your remote server if you want
to actually save the split files to a device so it is ready to roll
when needed... (or you need extra storage space to do this at the time
your disaster strikes).
Of course, all the 'double storage spaces' can be single disks, they
don't need to be expensive, fast disks, and don't need to have RAID
etc....
Just my 0.02c...
Regards,
Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqp8oMACgkQGyoxogrTyiXAiACgrMMF9RxnAg2k90xO9zvr7Itl
NDgAoLq4ks9lDaRKr6oQcTTTFam0daDw
=v178
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
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/
|
