<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi there,<br>
<br>
We have DRBD set up to create live backups of important data on a
file server on Amazon EC2. It's a simple setup, with a DRBD primary
and a secondary, both with a bunch of storage made up of EBS volumes
bound together via RAID, with LVM on top of that, and DRBD on top of
the LVM. Or, more succinctly, EBS -> RAID -> LVM ->
DRBD. <br>
<br>
This setup works well to help us handle the risks of a disk failure,
and also has made it easy for us to move between AWS availability
zones. But we'd like to use it to do proper snapshots for backups
to protect from user errors (deleting an important file etc.) We
have a couple of questions about the best way to do this.<br>
<br>
We've read this blog post
<a class="moz-txt-link-rfc2396E" href="http://blogs.linbit.com/p/277/use-backup-with-drbd/"><http://blogs.linbit.com/p/277/use-backup-with-drbd/></a> about
doing backups of DRBD volumes using LVM, which says:<br>
<blockquote>Essentially one would disconnect the Secondary, [use LVM
to] snapshot the backing device, mount the snapshot, perform the
backups, umount the snapshot, reconnect the Secondary. <br>
</blockquote>
We've tried this (the mickey-mouse test script is below), and it
appears to work fine. <br>
<br>
But: as far as we understand, the reason LVM is useful in this
process is that it allows you to mount and access the backing
device, as this would normally be inaccessible even when the server
is disconnected, because DRBD is keeping it locked. For example, in
a test environment, on the secondary, with
/dev/important_volume/real_data as the disk to which the DRBD
resource r0 is syncing:<br>
<blockquote><tt>root@giles-devbackup1:~# drbdadm disconnect r0</tt><tt><br>
</tt><tt>root@giles-devbackup1:~# mkdir /mnt/foo</tt><tt><br>
</tt><tt>root@giles-devbackup1:~# mount
/dev/important_volume/real_data /mnt/foo</tt><tt><br>
</tt><tt>mount: /dev/mapper/important_volume-real_data already
mounted or /mnt/foo busy</tt><tt><br>
</tt></blockquote>
Are we right in thinking that the purpose of using LVM is purely to
get a mountable device that you can run the backup from? After all,
if the server you're running on has been disconnected from the
primary, the volume won't be being written to, so it presumably
isn't to avoid "blurring" as the disk changes underneath your feet
while you're backing up.<br>
<br>
If we're right in that belief, we think we don't need to use LVM
snapshots for our specific environment. We're using Amazon EBS, and
that has its own snapshot functionality. It doesn't work very well
if data changes under its feet, but if we use "drbdadm disconnect"
before it starts and reconnect when it's done, perhaps it will
work? So we're wondering if instead we can use this, perhaps
simpler, backup methodology:<br>
<ul>
<li>drbdadm disconnect the resource on the secondary<br>
</li>
<li>Use the AWS API to do their kind of snapshot on the underlying
disks. Wait for these to complete.</li>
<li>drbdadm connect the resource secondary</li>
<li>Make sure you wait for the primary to have synced fully before
doing this again!<br>
</li>
</ul>
Again, we've done this in a testing environment and it looked like
it worked -- but we're not sure if it will work in production.<br>
<br>
Is anyone out there doing backups on Amazon like that? Any
thoughts?<br>
<br>
<br>
All the best,<br>
<br>
Giles<br>
<br>
PS here's our mickey-mouse script to do backups using LVM snapshot:<br>
<blockquote><tt>echo Start off with a clean backup disk</tt><tt><br>
</tt><tt>mkfs.xfs -f /dev/xvdf</tt><tt><br>
</tt><tt>mount /dev/xvdf /mnt/backup</tt><tt><br>
<br>
</tt><tt>echo Disconnect us - the secondary</tt><tt><br>
</tt><tt>drbdadm disconnect r0</tt><tt><br>
<br>
</tt><tt>echo Snapshot the backing device</tt><tt><br>
</tt><tt>SNAPSHOT_ID=`date +%Y%m%dT%H%M`</tt><tt><br>
</tt><tt>lvcreate -L100M --snapshot --name $SNAPSHOT_ID
/dev/important_volume/real_data</tt><tt><br>
<br>
</tt><tt>echo Mount the snapshot</tt><tt><br>
</tt><tt>mount /dev/</tt><tt><tt>important_volume</tt>/$SNAPSHOT_ID
/mnt/snapshot/</tt><tt><br>
<br>
</tt><tt>echo Perform the backup</tt><tt> -- primitive version<br>
</tt><tt>cp -pr /mnt/snapshot/* /mnt/backup/<br>
<br>
</tt><tt></tt><tt>echo Unmount the snapshot</tt><tt><br>
</tt><tt>umount /mnt/snapshot</tt><tt><br>
<br>
</tt><tt>echo Remove the snapshot</tt><tt><br>
</tt><tt>lvremove -f /dev/</tt><tt><tt>important_volume</tt>/$SNAPSHOT_ID</tt><tt><br>
<br>
</tt><tt>echo Reconnect us -- the secondary</tt><tt><br>
</tt><tt>drbdadm connect r0</tt><tt><br>
<br>
</tt><tt>echo Umount the backup disk</tt><tt><br>
</tt><tt>umount /mnt/backup</tt><br>
</blockquote>
<pre class="moz-signature" cols="72">--
Giles Thomas <a class="moz-txt-link-rfc2396E" href="mailto:giles@pythonanywhere.com"><giles@pythonanywhere.com></a>
PythonAnywhere: Develop and host Python from your browser
<a class="moz-txt-link-rfc2396E" href="https://www.pythonanywhere.com/"><https://www.pythonanywhere.com/></a>
A product from PythonAnywhere LLP
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number OC378414.
Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK </pre>
</body>
</html>