I think the scenario is say for example always open files like SQL DB files. These have to be co ordinated with the backup, stop the db or flush the db or dump the DB to another location.
A On Thu, Jan 29, 2004 at 03:47:48PM +1100, Jamie Wilkinson wrote: > 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 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
