Seconded. In two years at this job, I've seen allot of snapshot related, we call them "resume generating events". <div><br></div><div>Bean<br><br><div class="gmail_quote">On Wed, Sep 22, 2010 at 5:58 PM, Nate Duehr <span dir="ltr"><<a href="mailto:nate@natetech.com">nate@natetech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
> In my environment, mostly virtualized servers in VMware Server on Linux, LVM snapshots make simple backups possible. Without LVM snapshots, backups would be a nightmare.<br>
><br>
<br>
</div>An LVM snapshot isn't a copy of the data... it just marks where the<br>
snapshot took place, and then knows how to "get back there"... a Hansel<br>
and Gretel trail of breadcrumbs so to speak. (It keeps track of the<br>
original inode numbers.)<br>
<br>
I have used snapshots on LVM and other filesystem types that are capable<br>
of snapshots to "freeze" the filesystem so a relatively slower<br>
backup-to-tape system could then back that snapshot up over a weekend's<br>
time, so that no changes are taking place to the data, while the backup<br>
is running. That works well.<br>
<br>
But if LVM itself fails, the snapshots aren't copies, and they're gone<br>
gone gone... they're not a substitute for getting the data off, and onto<br>
another platter, tape, CD, whatever...<br>
<br>
As a tool to "freeze" everything so a backup can be taken, tools like<br>
LVM are great. (Don't forget to "quiet" your databases and other things<br>
on that disk, if you have things there that aren't just files, but are<br>
actively being written to like binary DB spaces, etc.)<br>
<br>
My point was only that the limitations of the tool must be known, and<br>
one of those is that LVM *can* fail, just like anything else...<br>
<br>
It doesn't happen often, but I've seen it (once)... it took out the<br>
machine. I've also seen professional grade but similar tools like<br>
Veritas barf and take out all of someone's data too... there's all sorts<br>
of ugly once-in-a-lifetime failures that the only thing that will fix<br>
them is good backups, and a bare-metal recovery plan!<br>
<br>
So if you meant that LVM is a useful tool if you plan to use it as a way<br>
to "quiet" your filesystem you're backing up to somewhere else, I<br>
definitely agree, and building with LVM in mind up-front is required.<br>
But having LVM on by default for folks without a real plan on how to<br>
manage their systems, is kinda silly on the part of many Linux distros,<br>
and just adds complexity they may not (or may...) need.<br>
<br>
I don't ascribe to the "turn it all on, we might need it" philosophy of<br>
system management, because every 100 lines of code has at least one bug<br>
in it... the less overall code running, the less overall risk of<br>
failures... in my humble opinion. There's enough complexity in the<br>
computing world without turning on things like LVM by default long<br>
before a new sysadmin even knows what it is, and what they can (and<br>
can't) use it for. :-)<br>
<div><div></div><div class="h5"><br>
Nate<br>
_______________________________________________<br>
clue-tech mailing list<br>
<a href="mailto:clue-tech@cluedenver.org">clue-tech@cluedenver.org</a><br>
<a href="http://cluedenver.org/mailman/listinfo/clue-tech" target="_blank">http://cluedenver.org/mailman/listinfo/clue-tech</a><br>
</div></div></blockquote></div><br></div>