Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Ken,
The method you outlined would work, however if you're stopping DRBD and
Heartbeat there would be no reason to bring down the dedicated
replication link.
Also check out the csums-alg setting, below is the excerpt from the
drbd.conf man page.
csums-alg hash-alg
A resync process sends all marked data blocks form the source to the
destination node, as long as no csums-alg is given. When one is
specified the resync process exchanges hash values of all marked blocks
first, and sends only those data blocks over, that have different hash
values.
This setting is useful for DRBD setups with low bandwidth links.
During the restart of a crashed primary node, all blocks covered by the
activity log are marked for resync. But a large part of those will
actually be still in sync, therefore using csums-alg will lower the
required bandwidth in exchange for CPU cycles.
Hope that helps.
Brian
: LINBIT | Your Way to High Availability
: 8152 SW Hall Blvd., Suite #209 : Beaverton, OR 97008
:
: http://www.linbit.com
Ken Dechick wrote:
> Hello all,
>
> I know this has been discussed before, but I am still trying to "sell"
> the whole DRBD/Heartbeat system to the higher-ups within my company and
> I can't find a solid answer on this here in the mailing list. So I will
> ask again.
>
> I NEED to have tape backups - we are in the medical software business
> and having a tape to fall back on is crucial to our business model (if a
> client's office burns to the ground and both the primary and secondary
> servers in the 2-node cluster are gone for good, then a tape backup no
> more than a day old stored offsite is the only solution left - no doctor
> will tolerate losing much more data than this).
>
> So let's forget the whole mounting secondary as read-only mess for now.
> What I am thinking is this:
>
> -at backup time (2AM?):
> -stop drbd and heartbeat on the secondary
> -bring down the dedicated eth1 connection to the primary (leaving
> eth0 still up so I can get in if need be)
> -mount the sda4 partition (NOT the drbd0 device as drbd will be
> stopped) to it's normal position
> -run my usual tape backup routine
> -unmount sda4 again
> -bring eth1 back up
> -start drbd and heartbeat again
>
> I am thinking that in this way my users will still see NO downtime of
> the primary resource (unless of course there is a hardware failure
> during the tape backup while the secondary is offline!), and I still get
> a tape backup that is quite current. Once the secondary comes back up
> again anything that may have changed during the backup will replicate
> leaving me with only a tiny window of time to be without the secondary
> (an hour or two tops for my tape backup to run).
>
> Could it really be this simple? We don't use lvm at all, just plain old
> ext3 file systems, so I believe this negates the whole lvm snapshot and
> then back that up dicussion I have seen here in the lists. What are your
> thoughts? Currently we implement what we call a view-only backup server
> at some clients where a second server is up and running and sync'ed
> (using rsync) only once a night from the main, then a tape backup runs
> once the sync is done. In this way our aplpication is only offiline
> during the time it takes to complete the rsync. I am thinking that there
> is no need to do this at all if I have a DRBD/Heartbeat 2 node cluster.
> (I certainly don't need a 3rd machine and keep doing the rsync then tape
> like we do now do I??)
>
> Thanks in advance for any thoughts on this you can share!
>
> -Ken
>
>
>
>
> Kenneth M DeChick
> Linux Systems Administrator
> Community Computer Service, Inc.
> (315)-255-1751 ext154
> http://www.medent.com
> kend at medent.com
> -- -- -- -- -- -- -- -- -- -- --
> "You canna change the laws of physics, Captain; I've got to have thirty
> minutes! "
>
> .
>
>
> This message has been scanned for viruses and dangerous content by
> MailScanner & ClamAV.
>
> This message and any attachments may contain information that is
> protected by law as privileged and confidential, and is transmitted for
> the sole use
> of the intended recipient(s). If you are not the intended recipient, you
> are hereby notified that any use, dissemination, copying or retention of
> this e-mail
> or the information contained herein is strictly prohibited. If you
> received this e-mail in error, please immediately notify the sender by
> e-mail, and permanently
> delete this e-mail.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user