BackupPC-users

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

2011-04-12 23:17:59
Subject: Re: [BackupPC-users] Block-level rsync-like hashing dd?
From: Timothy J Massey <tmassey AT obscorp DOT com>
To: backuppc-users AT lists.sourceforge DOT net
Date: Tue, 12 Apr 2011 23:13:50 -0400
Saturn2888 <backuppc-forum AT backupcentral DOT com> wrote on 04/12/2011 10:40:50 PM:

> My goodness that's a lot of replies; although, almost all of them
> are from a post I made a while back which I've elaborated on at
> least 3 times since.


But you keep saying the same thing.  Repeating it doesn't make it doable.

> The main point here that I'm trying to get across, at least for my
> own setup, is that I cannot handle dd'ing 1TB/day.


I'm very sorry to hear that.  But you have *very* little choice.  Wishing it weren't so doesn't change it.

> That would
> literally take 8-12 hours (at least half a day) easy depending on
> network load, and it would cream available bandwidth.


By my math, that means you're moving about 24MB/s (1TB/60/60/12 hours), so it sure sounds correct to me.

(As for 'creaming available bandwidth':  you can't add an additional PCI or PCIe Gigabit NIC to dedicate to the backup?  Or even better, put that extra NIC into a dedicated gigabit switch--even a cheap one--so now your backup traffic never even appears on your normal LAN?  Not every problem can be fixed in software.  But I digress...)

> The reason I
> am advocating DRBD is because I have it going to an iSCSI target on
> a machine with ZFS which snapshots the pool. The key there is I'm
> taking snapshots of it so even if it corrupts, I'm fine.


You think/hope/pray.  Do you truly understand ZFS snapshots?  I guarantee that you *DO* *NOT*.  Corrupt the base layer, and all of the snapshots on top of it are *TOAST*.

But continuing anyway...

> All I'd
> have to do is mount the .img as EXT4 in an iSCSI target and point a
> client to that target to retrieve the files.


This is in *NO* way different from pairing LVM with iSCSI.  Where does DRDB come into this?

> Not necessarily the
> best idea, but I don't see pool corruption a big deal because I've
> never experienced anything like that.


OK, then.  If that's your philosophy (I've never seen it so I won't worry about it!) then please feel free to use whatever solution you would like.  After all, if it's never happened to you, then there's no need to protect against it!

> The BackupPC_copyPcPool script and the tar copy are great for
> backing up the pool but both suffer the same fate as dd; there's no
> method of only transferring changes of files which destroys
> available bandwidth and leaves drives running constantly almost all
> day long slowing down crucial backups of machines.


Again, just because you keep loudly asking for something doesn't make it possible.

That whole "figure out what has changed" is not magically instantaneous.  It takes a *lot* of work to actually do that part.  You keep ignoring that.  Once you truly understand and factor that work in, I think you will find that the dd solution is not nearly as lacking as you think it is.

> And please note, I did talk about ddsnap as well. While the
> project's out of commission, the software still exists somewhere.

And I covered that as well.  It will read *exactly* as many bytes as a dd will--and read a *lot* more bytes on the destination side than dd will.  Do not continue until you truly understand that.

The *only* thing it won't do is transfer as many bytes over the wire.  Is that *TRULY* what you are worried about?!?  Again, buy a $30 NIC and you will no longer worry about that any more!

And please do yourself a *very* big favor:  make *sure* you *truly* understand exactly what protection snapshots offer for your data.  (Hint:  they make your data *less* reliable, not more reliable.)  I'd hate to see you put the safety of your data into something that is not providing you with what you think it is.

Timothy J. Massey
 
Out of the Box Solutions, Inc.
Creative IT Solutions Made Simple!

http://www.OutOfTheBoxSolutions.com
tmassey AT obscorp DOT com
      22108 Harper Ave.
St. Clair Shores, MI 48080
Office: (800)750-4OBS (4627)
Cell: (586)945-8796

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
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/