[Discuss] Backing up LVM partitions using snapshots

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

On Dec 14, 2011, at 4:56 PM, Bill Bogstad wrote:
> 
> Let me try again.   1. Do away with differentials against
> differentials.  2.  Optimize differential against full by keeping
> track of TRIMs so that writes that are later TRIMed are dropped from
> the list of differences from full.   Since any restore would be simply
> full + one differential there shouldn't be any inconsistencies.

I now see that #1 is a given -- and something that needs to be well-documented, with eight-by-ten colour glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was.   While incremental against incremental is perfectly fine for file-level backups, it looks to be a disastrous mistake for block-level dumps.

So... what happens if you lose a full dump?  Suppose a 7 day cycle.  Do a full dump (f1), then six differential dumps (d1.1-d1.6).  Then do a second full dump (f2), and start doing six more differentials, but disaster hits on day 4 so you have only 3 days of differential dumps (d2.1-d2.3).  You go to restore f2 and discover that it is corrupted, unusable, maybe LVM reaped it.  Okay, go back to f1 and restore, then restore d1.6.  That gets the volume to the state it was a day before the f2 dump was made.  What now?


#2 should work, but I don't know enough about various TRIM implementations to say with certainty either way.

I still see the potential security issue with reused blocks.  TRIMed blocks aren't zeroed and they will be reallocated for use.  This could be exploited.


> Been there, done that.  Of course, when that database gets corrupted
> recovering even a single file from a file oriented backup system means
> you start scanning a bunch of tapes. Some systems like to backup the database every time any kind of backup occurs.

Been there, done that, hate Legato Networker for it because back in the day it *didn't* back up it's own database.

> This can get expensive if you have lots of small files or you keep your history for a long time.

Now... this statement bothers me on a fundamental level.  It's the negative perception that backup systems are expensive.

Your data has value.  Will losing that data cost you more than what it would cost you to have a reliable backup?  If the answer to that question is "yes" then the backup system isn't expensive in relation to the value of the data it stores.  It may have a high monetary cost (FSVO "high"), but if it lets you recover from a disaster then it saves you more money than it costs.  Thus, it is not expensive.

--Rich P.