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: "Digimer" <linux at alteeve.com>
> Cc: drbd-user at lists.linbit.com
> Sent: Friday, February 17, 2012 11:42:46 AM
> Subject: Re: [DRBD-user] Documentation download & another DRBD question
>
> (Apologies for top posting - working off a different laptop as I
> broke mine this morning, and outlook is a pain)
>
> Jake/Maurits/Digimer, Thanks for the replies.
>
> Jake/Digimer:
> > What it sounds like you need is LVM's snapshotting capability. DRBD
> > is designed to be a block-level replication tool, not a backup
> > tool per-se.
> We need to back up individual folders, some of which are 80+ GB. I
> don't think a snapshot allows me to do this?
I don't see why LVM/snapshotting would care how big the folders are... you take the snapshot and basically have point-in-time of the volume which you can mount and use as a regular volume (r/w or whatever). Only thing I watch out for is that I have enough space allocated to the snapshot because any changes that occur on the volume you've taken the snapshot of require enough space to track until you remove the snapshot. For my use I run the following command right after my backup finishes (just before deleting snapshot) and it's part of my backup log every night. That way I can keep an eye on how much of the allocated space is used by the snapshot and make sure I always have sufficient snapshot size and physical space available. I believe all I/O would freeze if your snapshot ran out of space to write changes... no good! :-)
lvs command I use:
lvs -o origin,lv_name,origin_size,lv_size,snap_percent /vol_group_path/snapshot_vol_name
lv_size is how much space I allocate to track snapshot changes
snap_percentage is how much of the lv_size has been used tracking changes so far
>
> Digimer:
> > As a secondary aside; Why use cp instead of rsync?
> Data on the primary server is on a SAN, with about 8 million files,
> most tiny. The backup dumps this to fast local disks (there is other
> things on the SAN also, and all our VMs etc get backed up nightly,
> meaning sometimes disk IO access can be slowed), this is then
> compressed locally, before being booted off to local storage on the
> second server. The department in charge of the data, and the backup
> process are not that well versed in this, and when I suggested rsync
> and the delta capabilities, they assumed it is going to take longer
> to check, and never tested it fully. Preferably, I would like them
> to rsync to the second machine, and then do the tar/gz there. But
> with managers involved, ive been told to look for another solution,
> as they "don't have the time to spend days looking at something that
> is potentially slower"
>
> > (inducing a split-brain condition, which is generally something
> > you want to avoid
> The second machine does nothing except store a copy of this data (why
> they need 2 6core procs & 128GB memory baffles me tbh!). It actually
> stores two copies, one which is a "site sync" in the software, and
> the other being the tar/gz copy. It is source code, so they are
> quite finicky about the data.
>
> I will download the DRBD manual, and have a good read through. As I
> said im a novice with it. I also haven't used LVM snapshotting much,
> so will investigate that also.
>
> Once again, thanks for the replies.
>
> B
> -----Original Message-----
> From: Digimer [mailto:linux at alteeve.com]
> Sent: 17 February 2012 15:20
> To: Brian O Mahony
> Cc: drbd-user at lists.linbit.com
> Subject: Re: [DRBD-user] Documentation download & another DRBD
> question
>
> On 02/17/2012 08:19 AM, Brian O Mahony wrote:
> > Hey folks
> >
> > 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?
>
> What it sounds like you need is LVM's snapshotting capability. DRBD
> is designed to be a block-level replication tool, not a backup tool
> per-se.
>
> For example, DRBD would be perfect playing the role of protecting
> your data from a sudden catastrophic failure on the server. There
> would be no data loss at all and within moments, the system could be
> back online with the help of a clustering layer like pacemaker or
> rhcs.
>
> Though you could technically break the secondary/backup node off,
> force it to be primary (inducing a split-brain condition, which is
> generally something you want to avoid), copying the data and then
> invalidating the node again, it would be a very unwise way of using
> DRBD. Whereas LVM's snapshot partitions are designed to do exactly
> what you want. It "freezes" the data at a point in time, allowing
> the partition to stay in use while you back up that snapshot
> partition.
>
> As a secondary aside; Why use cp instead of rsync?
>
> --
> Digimer
> E-Mail: digimer at alteeve.com
> Papers and Projects: https://alteeve.com
>
>
> 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
>
>