[linux-lvm] SnapRestore software on NetApp

[linux-lvm] SnapRestore software on NetApp

[Emanuel Quass]

Hi,


first of all I want to thank the developers for the work they have done up to 
now!

But to come to business, I have to write a comparison between Linux  and 
NetApp Filers. (Is there anything already somewhere available?)

I saw something about a "SnapRestore software" which means that it is 
possible to revert a snapshot back to the filesystem in some minutes!
My question: Is this possible with LVM and reiserfs too?

Thanks in advance

	Emanuel

Re: [linux-lvm] SnapRestore software on NetApp

[Joe Thornber]

On Thu, Oct 18, 2001 at 04:46:58PM +0200, Emanuel Quass wrote:
> Hi,
> 
> 
> first of all I want to thank the developers for the work they have done up to 
> now!
> 
> But to come to business, I have to write a comparison between Linux  and 
> NetApp Filers. (Is there anything already somewhere available?)
> 
> I saw something about a "SnapRestore software" which means that it is 
> possible to revert a snapshot back to the filesystem in some minutes!
> My question: Is this possible with LVM and reiserfs too?

I'm not sure what you mean by 'reverting a snapshot back to the
filesystem', but dropping a snapshot takes very little time (seconds).

- Joe

Re: [linux-lvm] SnapRestore software on NetApp

[Andreas Dilger]

On Oct 18, 2001  17:48 +0100, Joe Thornber wrote:
> On Thu, Oct 18, 2001 at 04:46:58PM +0200, Emanuel Quass wrote:
> > But to come to business, I have to write a comparison between Linux  and 
> > NetApp Filers. (Is there anything already somewhere available?)
> > 
> > I saw something about a "SnapRestore software" which means that it is 
> > possible to revert a snapshot back to the filesystem in some minutes!
> > My question: Is this possible with LVM and reiserfs too?
> 
> I'm not sure what you mean by 'reverting a snapshot back to the
> filesystem', but dropping a snapshot takes very little time (seconds).

What this means is to make the "snapshot" become the primary copy again,
and not "dropping" it.  In other words, lets say you just deleted a whole
bunch of files on your filesystem, or your database chewed up the data.
Instead of restoring from a backup, or copying from the snapshot into a
new volume, you "revert" the snapshot data back into the original volume.
The latter only involves copying as much data as is in the snapshot,
instead of the entire volume.

If you had "symmetrical" snapshot volumes (i.e. the snapshot is exactly
a regular volume and both the snapshot and the original have "links"
to the blocks that they use) it would be possible to "drop" the original
and move the snapshot to become the original volume.

This may be possible to do in the short term with writable snapshots,
but then you start getting into a very ugly situation where the "good"
volume (i.e. the writable snapshot) depends on the snapshot, which
depends on the original "bad" volume and you can't get rid of any of them.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] SnapRestore software on NetApp

[Joe Thornber]

On Thu, Oct 18, 2001 at 12:20:22PM -0600, Andreas Dilger wrote:
> This may be possible to do in the short term with writable snapshots,
> but then you start getting into a very ugly situation where the "good"
> volume (i.e. the writable snapshot) depends on the snapshot, which
> depends on the original "bad" volume and you can't get rid of any of them.

I suppose the ideal solution is to allow people to choose which way
round a snapshot is taken depending on whether they thinks it's likely
they'll rollback, or commit to the snapshot.

ie.

You probably want to rollback; the snapshot lv contains new data written to 
the snapshot (as it is now).  Rollback is quick, commit (merge) is slow.

You probably want to commit to the snapshot; the snapshot lv contains
copies of the original data.  Rollback (merge) is slow, commit is quick.

- Joe