Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Backing up LVM partitions using snapshots



> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Bill Bogstad
> 
> On Wed, Dec 14, 2011 at 10:53 AM, Richard Pieri <richard.pieri at gmail.com>
> wrote:
> > On Dec 13, 2011, at 11:11 PM, markw at mohawksoft.com wrote:
> >>
> >> Using a block level store, an incremental backup is no different than a
full
> backup.
> >
> > You're not following me. ?You have a full dump. ?You have a first
differential
> against that dump. ?You have a second differential made against the first
> differential. ?If you lose the first differential then you are screwed.
> 
> I've been watching the (second?) incarnation of this thread for a
> while now and I think that I see your point.  

That's not how incremental snapshots work.  Well sure, if you leave these
datastreams laying around as files, then the argument is true, lose the
first incremental and you lose everything after it.  But that's not what you
do.

I can't speak on behalf of Mark's stuff, but there is only one sane way to
behave:

You receive your first complete image.  In and of itself, it represents a
filesystem.
On the receiving end, you snapshot the receiving filesystem.
You send an incremental datastream, and write it directly on top of the
recipient filesystem.  After this receive is completed, it represents a
whole filesystem.  Optionally delete the previous snapshot on the recipient
system.
You send another incremental datastream, and so on.

At all times, you have a complete filesystem.  You never have any
incrementals laying around, waiting for corruption to silently occur.
You're not writing them to tape and sending them to the vault.  Every time
you receive an incremental image, it's written directly on top of the
previously received image.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org