On Sun, 2008-04-13 at 08:47 -0700, Bart Schaefer wrote: > On Sat, Apr 12, 2008 at 5:59 PM, Karanbir Singh <mail-lists at karan.org> wrote: > > well, just use it. > > This implies that "snapshot" is a bit of a misnomer for what LVM > creates, because you can modify both the "snapshot" and the "real > physical LV," but if you want to be able to revert easily, it's the > "real LV" that you have to *avoid* changing (so that you can simply > drop the snapshot when you're finished with it). > > Have I got that wrong? > > This limits the usefulness of snapshots as a backup/recovery mechanism. > > > Also, your work flow is broken if your historic snapshots are now > > production while the real physical LV isnt.( imho ) > > Seems to me that's exactly the situation he's trying to avoid. He > wants to restore the real LV to the state it was in at the time one of > the snapshots was taken. Which in other contexts is exactly the > reason one makes a snapshot. At the risk of looking foolish now, I'll discourse a little from *memory*. Then y'all can take KB's advice if desired. IIRC, the snapshot volume holds changes to the base volume that occur while it is mounted, leaving the base unchanged so that a (e.g.) backup process sees a fixed state on the base file system. Only changes are on the snapshot volume and I don't know at what level (changed blocks, i-nodes, whole files or what). Regardless, when the snapshot volume is unmounted, the changes are then commited to the base volume. But the record of those things are still on the volume and it is mountable and usable independently, implying that there might be complete files on there. I don't know for sure. Regardless, the snapshot volume is not a "mirror" of the base and is not suitable for an unfiltered restore to the base and is not useful as a full replacement for the base FS. Someone please correct me if I'm wrong - it'll save me reading again! =>8-O :) > <snip sig stuff> -- Bill