BackupPC-users

Re: [BackupPC-users] Block-level rsync-like hashing dd?

2011-04-09 12:34:00
Subject: Re: [BackupPC-users] Block-level rsync-like hashing dd?
From: Les Mikesell <lesmikesell AT gmail DOT com>
To: backuppc-users AT lists.sourceforge DOT net
Date: Sat, 09 Apr 2011 11:31:28 -0500
On 4/9/11 12:28 AM, Saturn2888 wrote:
> Was the conclusion that you could or could not rsync a logical volume? And 
> even if so, what are the speeds to run checksums on a device and compare it 
> with another device? I've got an iSCSI target setup and had a few ideas, all 
> of which failed. Here are my findings on various methodologies or possible 
> solutions to backing up BackupPC's data.

Long ago, I mentioned I was thinking about running backuppc under vmware with 
the virtual disk broken into 2gb files on the host (a standard vmware option) 
then trying to rsync snapshots of those to a remote server configured the same 
way.  Someone responded about a fuse filesystem that made an ordinary partition 
image look like it was broken into smaller files in much the same way so that 
you could rsync them.  I didn't pursue either option at the time.

> :: mdadm ::
>
> I could try adding the drive into the Linux Software RAID1 mirror, but that 
> would slow down all transfers because if the iSCSI target I'm writing to are 
> being written to, that will slow down writes of all these really small files 
> with hardlinks on top of that. No matter what, I can't imagine any sort of 
> non-block-level sync associated with RAID1 being anywhere useful over 
> Ethernet when BackupPC's being used. And what if I restart the iSCSI target 
> machine etc? Doesn't seem workable.

This is what I use, with a raid1 created with 3 members but one missing.  I 
periodically rotate disks into a hotswap sata bay, add it long enough to 
re-sync, and then fail and remove it to take offsite.  The sync operation does 
make backups too slow to be practical, but it completes during the blackout 
window and I just shut down/unmount momentarily while breaking the raid to have 
a clean filesystem.  This should work just as well over iscsi, given a network 
that is fast enough, but probably not over a WAN.


> :: DRBD ::
>
> Here comes DRBD. I absolutely have no clue how to use this and usage examples 
> online are scarce. The an up-side to DRBD is that it's going to act like a 
> RAID1 mirror, but that it works at the block level which will speed up 
> transfers greatly. The next good thing about it is it's able to work 
> asynchronously. Right there, I have a capable solution with may or may not 
> work for me. From what I've seen, it's really designed for high availability 
> clustering and requires both sides to have DRBD for it to be useful. Since 
> I'm backing this up to an embedded FreeBSD 7.3 box which does not have DRBD, 
> the iSCSI target comes to mind as a capable solution; yet, it almost seems 
> impossible because this machine has to be both the sending and receiving end. 
> I don't quite know yet if this will really be worthwhile or not or if I can 
> even get it working.

Theoretically, this should work like software raid over iscsi but the current 
versions are supposed to be able to keep track of what is in sync and what 
needs 
to be updated after a disconnect.   It sounds promising but I don't know what 
happens with an 'unclean' disconnect.  That is, if there is a backlog of 
changes 
between the master/copy, how badly the copy filesystem will be corrupted if you 
try to use it.


> :: Final Thoughts ::
>
> I hope that helps anyone trying to figure out how insane this is. My last 
> idea is to either way for BackupPC4 which uses a database or write my own. 
> I'm backing on the latter because that's the quickest way to get something 
> worthwhile accomplished.

Tossing a locally-mirrored disk in your briefcase turns out to have a lot of 
bandwidth even if the latency is bad....

-- 
    Les Mikesell
      lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
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/