rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] Filechange during backup


From: Rainer Zocholl
Subject: Re: [rdiff-backup-users] Filechange during backup
Date: 08 Jan 2005 23:27:00 +0100

address@hidden(Neil)  08.01.05 16:49


>no. you have misunderstood lvm snapshots

Yes, i confirm ;-)


>LVM snapshots are far better than a dd (for this purpose at least)
>they hold a copy of the any changed data before it was changed

>from the lvcreate man page-
>Snapshots provide a 'frozen image' 

that's wrong/missleading 
No "Image of the *contens*" is frozen!

For someone who knows how that was meant the sentence is
clear.
But someone without that knowledge will be kicked in the
wrong direction.
Maybe "image" is not meant in the way i understand it.


>of the contents of the origin while
>the origin can still be updated. 

The snapshot "freeze" the directory information (the "view") 
and only the next changes are written to that snapshot(!) volume.

>They enable consistent backups and
>online recovery of removed/overwritten data/files. The snapshot does
>not need the same amount of storage the origin has. In a typical
>scenario, 15-20% might be enough.

The snapshot volume needs (mainly) only to keep the data that is newly
created after the snapsshot

Joe Baker wrote:

  It's another view of the data files.  When a snapshot is in effect 
  data is written differently to the drive in such a way that the 
  origional view is not altered.  It's a pretty fancy technique.

That's makes it pretty clear how it works.


>be aware that just because it is a consistent snapshot of what was on
>the disk at a point in time doesn't mean it will be useful. For
>example using a database you need to get the database to write to disk
>all the info it needs to be a valid usable snapshot. 

ACK. That is what i wanted to warn too.

>The easy generic
>way around this is to shut the database down; take a snapshot; start
>the database up again; backup the snapshot;remove the snapshot. 
>This time this saves over shutdown database; backup; 
>startup database can be huge. 
>or course you may not want to shut your database down then
>you getting into database specific territory

But you have typically the chance to let the database "flush" 
and stop it without shuting down.

Another problem are database which have their own file systems...
but those have their own backups algorithm.



Rainer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]