This one time, at band camp, ksaenz wrote:
>
>> > >Well I haven't tried it but I believe LVM lets you add and remove files
>> > >on the run.
>> 
>sorry for coming into this thread so late. I have only caught the tail
>end of this discussion. Can someone correct me if I am wrong because I
>see some probs with adding and removing files in the fly. What happens
>to a file if someone has it opened and either you remove or replace it?
>My understanding of backups is that those types of files would get
>corrupted. 
>Wouldn't rsync kick arse in this scenario when you want to backup
>updated or changed and restore files. Especially keeping the ownership
>and priviliges in tact.

The idea behind the snapshot is that the block device is stopped, and a
temporary block device is created, and all new writes to the block
device during the existence of the snapshot are written to the temporary
one.

LVM allows you to tie a bunch of physical volumes together and split
them up, so you could have a few disks that appeared to be a terabyte of
storage on a single disk like so:

[                                                  ]

and then split that virtual disk into volumes like so:

[ 1   |  2      |           3             |        ]

and then, for example, mount partition 1 as /, make 2 into your swap,
and 3 as /home, leaving the rest unpartitioned and unallocated.

Later you can add bits of the unallocated space to your other
partitions, when you decide you need more space in 1 for a kernel
upgrade, say, but you can do other nifty things with the spare space
such as snapshotting for backups.

So what happens is you say "snapshot volume 3 and use the remaining space
as a snapshot volume", at which point you get a new snapshot block
device which points to volume 3, and your old block device which you
thought you had mounted on /home is now volume 4 (which is some made up
number which refers to a combination of volume 3 and the unallocated space)

So you do your backup from the snapshot and your filesystem is as intact
as it was when the snapshot was created.  I *believe* cached writes are
written before the snapshot so that anything that your applications
think was written to disk will be, but if you have anything cached in
user space that wasn't written to disk then you won't have that backed
up.

Meanwhile, the rest of the system think it's still writing to /home when
it needs to, and the kernel effectively journals all those writes to the
unallocated space in volume 4; which is effectively layered on top of
volume 3 for everyone but your dump process reading the snapshot.

At the end of it, you unsnapshot the volume and the kernel writes all
the journalled data back into volume 3, and removes the snapshot block
device, and all the while your applications didn't even know.

-- 
[EMAIL PROTECTED]                           http://spacepants.org/jaq.gpg
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to