[Discuss] lvm snapshot cloning

[richard.pieri at gmail.com (Richard Pieri)]

On Wed, Oct 26, 2011 at 8:26 AM, <markw at mohawksoft.com> wrote:

> 400GB/hour? I doubt that number, but ok. It is still close to three hours.
>

Doubt if you want but I did it last spring.  7.5TB -- ~7500GB -- restored
over 19 hours and change.  That's 400GB/hour average throughput.  Over a
network.  From a tape-based storage system.  That's what an enterprise-class
backup system can do.

I see where you are going with this.  One of the historically canonical
examples is database servers that use raw disk for storage. A
block-incremental backup mechanism would have been very useful 15-20 years
ago when this was more common.  Today, hardly anyone does it this way.
 Today, standard procedures are to either dump the DB to a flat file and
back that up or to perform the freeze/snapshot/thaw cycle and back up the
snapshot.  This may not be the most efficient way to do it.  On the other
hand, if I have so much data to back up that efficiency would be an issue
then I already have sufficient resources in my backup system to make it not
be an issue.

You mention virtual machines.  I can see this if you want to back up the
containers.  The thing is, using an operating system's native tools is
always my preferred choice for making backups.  It may be inefficient at
times but it ensures that I can always recover the backup correctly.  More
generally, it avoids issues with being locked into specific technologies.
 Going back to the example of running a FreeBSD domU on a Linux dom0.  With
LVM-based block backups I am locked into using LVM-based block restore for
recovery.  I can't restore this domU onto a FreeBSD or Solaris dom0 or even
onto a real FreeBSD physical machine.  On the other hand, if I use OS tools
to do the backup then I can restore it anywhere that I please.

It is clear to me that we have different philosophies about backup systems.
 In my mind, efficiency is all well and good but it will always take a back
seat to the ease of restoring backups and the ease of creating them.  I've
had to recover from too many disasters and too many stupid mistakes -- some
of them my own -- to see it any other way.