Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
----- Original Message ----- > From: "Brian O Mahony" <brian.omahony at curamsoftware.com> > To: drbd-user at lists.linbit.com > Sent: Friday, February 17, 2012 8:19:00 AM > Subject: [DRBD-user] Documentation download & another DRBD question > Hey folks > I am quite new to DRBD, and just had two quick questions, if someone > could help it would be great. > #1 Is there a downloadable version of the documentation. I don’t get > very much time to read, so was planning on reading it all offline…. This is the PDF for version 8.4 - if you're going to run 8.3 I'm not sure where there's a downloadable version though you could save the website off-line... http://www.linbit.com/en/education/tech-guides/drbd-user-s-guide/ > #2 One of the scenarios that I was thinking of using DRBD with is as > follows. Please let me know if this would theoretically work, and > whether it is ugly, or even just plain wrong. > I have a server with about 500GB of data on its own filesystem. > Currently, nightly, we lock this data, use tar to copy it it another > volume, unlock it, then use gzip on the copy to compress, and then > copy this to a second server for backup. The reason for the > multi-step process, is we want to keep data lock time a minimum. > What I was thinking of doing is using DRBD to mirror this volume to > the second server. At backup time, on the second system, we stop the > process, or stop the packet shipping or likewise, so there will be > no updates, lock the data, run tar/gz, unlock, and restart the > synchronization. > Is this possible. IE can DRBD deal with a system being unavailable > for a few hours, store changes (or do checksums etc) and then replay > those changes when the second system comes back online? I'm not an expert but it sounds like it would work. On the secondary you would have to disconnect, promote to primary, mount (which would cause split-brain/divergence of data from the primary I believe), do your lock/tar/gz/unlock. Then you would unmount, demote and reconnect to the primary. Problem I see would be that it would require a complete re-sync because you would need to discard changes on the secondary when you reconnected to the primary. Might be better to put (at least) the secondary on top of an LVM volume and use a snapshot when you need to take a backup: Snapshot the secondary DRBD volume, mount the snapshot, do your backup, unmount and drop the snapshot. DRBD would hum right along on top while you did this and there would be no re-sync necessary. That is how we take our backups - against LVM snapshots of the DRBD volumes only on the secondary sides. HTH Jake > Anyways thanks in advance for the replies > Regards > B > The information in this email is confidential and may be legally > privileged. > It is intended solely for the addressee. Access to this email by > anyone else > is unauthorized. If you are not the intended recipient, any > disclosure, > copying, distribution or any action taken or omitted to be taken in > reliance > on it, is prohibited and may be unlawful. If you are not the intended > addressee please contact the sender and dispose of this e-mail. Thank > you. > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user