So how does one accomplish this if say the snap is now deemed the copy of interest? I am hoping dd is not the only answer:)
Thanks! jlc
Joseph L. Casale wrote:
So how does one accomplish this if say the snap is now deemed the copy of interest? I am hoping dd is not the only answer:)
well, just use it.
Also, your work flow is broken if your historic snapshots are now production while the real physical LV isnt.( imho )
On Sun, 2008-04-13 at 01:59 +0100, Karanbir Singh wrote:
Joseph L. Casale wrote:
So how does one accomplish this if say the snap is now deemed the copy of interest? I am hoping dd is not the only answer:)
well, just use it.
Also, your work flow is broken if your historic snapshots are now production while the real physical LV isnt.( imho )
IIRC, you don't have a real snapshot on the LV ATM. The snapshot LV only contains files that were chang(ed/ing) while the snapshot volume was "attached" during the backup.
Don't trust me though - read the docs to be sure. Last time I looked it might have been vers 1.
William L. Maltby wrote:
IIRC, you don't have a real snapshot on the LV ATM. The snapshot LV only contains files that were chang(ed/ing) while the snapshot volume was "attached" during the backup.
That does not mean you cant use the snapshot, as long as you are ready to live with the fallouts of such a move ( and have enough space allocated )
On Sun, 2008-04-13 at 15:04 +0100, Karanbir Singh wrote:
William L. Maltby wrote:
IIRC, you don't have a real snapshot on the LV ATM. The snapshot LV only contains files that were chang(ed/ing) while the snapshot volume was "attached" during the backup.
That does not mean you cant use the snapshot, as long as you are ready to live with the fallouts of such a move ( and have enough space allocated )
Right. I started to say something about that earlier (I have an automated b/u script I wrote way-back-when that takes advantage of the snapshot facility) but decided that mentioning that to the OP might lead to some unexpected hardships for him/her. I decided that just letting h{im | er } know that it didn't have the full FS was a better choice of information to pass on.
And in all honesty, it's been so long since I read up on it (vers 1, IIRC) and looked at the script, I really didn't feel qualified to suggest anything useful with any certainty.
On Sat, Apr 12, 2008 at 5:59 PM, Karanbir Singh mail-lists@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.
Bart Schaefer wrote:
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.
Thats not what the whole point is. The point of doing snapshots is to expose TO your backup process a consistent filesystem while reducing the production downtime ( for people who use snapshots as a back transport ). The Snapshot isnt meant to be the backup.
Anyway, if you are looking to discuss the in's and out's of lvm and how it does what it does, there is a linux-lvm list, you might want to go ask there.
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@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>
He wants to restore the real LV to the state it was in at the time one of the snapshots was taken.
Nah :) I want to sanp a volume, mount the snap, do my `stuff`, if I like it, I can merge into the primary copy and continue or dump the snap and go back...
That would be so very usefull! I know I can dd out the snap but that so not elegant (and slow)!
jlc
On Sun, Apr 13, 2008 at 07:59:20PM -0600, Joseph L. Casale alleged:
He wants to restore the real LV to the state it was in at the time one of the snapshots was taken.
Nah :) I want to sanp a volume, mount the snap, do my `stuff`, if I like it, I can merge into the primary copy and continue or dump the snap and go back...
That would be so very usefull! I know I can dd out the snap but that so not elegant (and slow)!
Use rsync to copy the changes to the lv?
On Sun, Apr 13, 2008 at 11:21:28PM -0600, Joseph L. Casale alleged:
Use rsync to copy the changes to the lv?
That would be only be possible if the lv had an fs that rsync and the os under rsync understood:) If these are exported as block devices into xen vm's or as iscsi targets for example it gets trickier.
rsync doesn't have fs-specific knowledge. It just reads and writes files. Put another way, what fs does rsync not undestand?
Garrick Staples wrote:
On Sun, Apr 13, 2008 at 11:21:28PM -0600, Joseph L. Casale alleged:
Use rsync to copy the changes to the lv?
That would be only be possible if the lv had an fs that rsync and the os under rsync understood:) If these are exported as block devices into xen vm's or as iscsi targets for example it gets trickier.
rsync doesn't have fs-specific knowledge. It just reads and writes files. Put another way, what fs does rsync not undestand?
a raw block device, as they said.
On Sun, Apr 13, 2008 at 11:54:36PM -0700, John R Pierce alleged:
Garrick Staples wrote:
On Sun, Apr 13, 2008 at 11:21:28PM -0600, Joseph L. Casale alleged:
Use rsync to copy the changes to the lv?
That would be only be possible if the lv had an fs that rsync and the os under rsync understood:) If these are exported as block devices into xen vm's or as iscsi targets for example it gets trickier.
rsync doesn't have fs-specific knowledge. It just reads and writes files. Put another way, what fs does rsync not undestand?
a raw block device, as they said.
Well, I was thinking about vm and such, assuming at some point there was an OS reading the filesystem tht can run rsync. But I concede the point, it definitely makes things tricky.
Well, I was thinking about vm and such, assuming at some point there was an OS reading the filesystem tht can run rsync. But I concede the point, it definitely makes things tricky.
It does seem there is some talk about the functionality, I assume it will happen sooner or later... jlc
Joseph L. Casale wrote:
Well, I was thinking about vm and such, assuming at some point there was an OS reading the filesystem tht can run rsync. But I concede the point, it definitely makes things tricky.
It does seem there is some talk about the functionality, I assume it will happen sooner or later...
indeed, most of the snapshot systems I've seen to date have a 'revert' function which makes the specified snapshot the 'default' live version. OTOH, most of these only support readonly snapshots.
Joseph L. Casale wrote:
Nah :) I want to sanp a volume, mount the snap, do my `stuff`, if I like it, I can merge into the primary copy and continue or dump the snap and go back...
You need to start by reading some of the docs on LVM2.
eg. nothing stops you from mounting a snapshot back onto the same mountpoint you snaped from.
You need to start by reading some of the docs on LVM2.
eg. nothing stops you from mounting a snapshot back onto the same mountpoint you snaped from.
I understand that, but where I am unsure is how space in the vg relates to this? Will this not require much additional space, what if I need to do this a continued basis?
jlc
Joseph L. Casale wrote:
You need to start by reading some of the docs on LVM2.
eg. nothing stops you from mounting a snapshot back onto the same mountpoint you snaped from.
I understand that, but where I am unsure is how space in the vg relates to this? Will this not require much additional space, what if I need to do this a continued basis?
You make the snapshot with a given size. That size should be large enough to hold all expected _changed_ /or/ _new_ stuff. Whatever is not changed or new, lvm simply points back to the original lv. If you need to add more space to the snapshot, do an lvextend on it.
-
Bart Schaefer -
Garrick Staples -
John R Pierce -
Joseph L. Casale -
Karanbir Singh -
Toby Bluhm -
William L. Maltby