Matt,

There is a reason why NetApp can do this kind of thing so easily, yet it
seems so hard with Windows.

Both FAT32 and NTFS are "update-in-place" filesystems where file data is
overwritten in it's existing locations on disk. Also, both of these
filesystems have fixed locations for metadata such as block maps, directory
entries and pointer blocks ("indirect inodes" for Unix people).

In order to maintain a "snapshot", products that work with traditional
filesystems, such as:

GoBack
CDP's Persistant Storage Manager
Volume Replicator (was Compaq, now HP)

and similar products for Unix, also products that work in storage arrays
that can't assume anything about the filesystem since they are presenting
raw LUN's, such as:

EMC Snapview
HDS QuickShadowCopy

all have one thing in common - they have to maintain a temporary storage
area to actively copy blocks out to as they are changed. i.e. every write to
a block becomes a read (either from read cache or off disk) and two writes
(one to write the old data to the snapshot area, the other two write the new
data to the original block location).

This means that for most systems maintaining a snapshot incurs a performance
penalty, and if you want to keep more than one the performance penalty grows
exponentially with each additional snapshot maintained. We call these
"active" snapshots since to keep them available requires additional activity
either by an OS shim or by the storage array processor. One of the issues
with active snapshots is that when the snapshot storage area fills up the
snapshot can no longer be maintained and becomes invalid - so if you're
running a report or doing a backup from the snapshot at that moment the
operation will fail. In an active snapshot system the active filesytem has a
higher resource priority than the snapshots.

Windows System Restore is a different beast entirely - I won't go into it
here but suffice it to say it's not useful for what you're trying to do.

NetApp can maintain multiple, on-line and readable, snapshot like you want
because their patented WAFL filesystem has no fixed locations for metadata
and never updates blocks in-place when writing to a file. i.e. snapshots are
simply a pointer to an older consistent filesystem image that happens to
share some physical blocks with the active filesystem, but no active copying
is required. We call this a "passive" snapshot. Passive snapshots have zero
performance overhead and no risk of operations against the snapshot failing,
i.e. snapshots have a higher resource priority than the active filesystem.

NetApp can also produce iSCSI or FCP LUN's that are really container files
on top of WAFL. You can create an NTFS filesystem on these LUN's and due to
the virtualisation gain the passive snapshot capability that you are
seeking.

The only other system that I am aware of that offers passive snapshots, and
at the raw block level so it can apply to NTFS as well, is the StorageTek
SVA ("Iceberg") produce, which uses a virtualisation process very similar to
using NetApp for block. Except StoTek does compression that has a
performance penalty not just because of the compression processing but
because there is no longer a 1:1 relationship between real and virtual disk
blocks.

Hope all this is of some help. It is POSSIBLE for someone to produce a
system like you want - maintaining block indirection tables is all that's
required - but the overheads in doing this locally on a Windows box given
the nature of NTFS and FAT32 are very high.










"Matt" <matt@downwithspammers-mengland.net> wrote in message
 news:kb9v20hl2ifpo47q8dlb47qvmcu9cmid97@
4ax.com...
> On 15 Feb 2004 08:29:06 -0500, adykes@panix.com (Al Dykes) wrote: 
>
> At first glance of http://www.symantec.com/goback/features.html, it
> appears that GoBack does not allow me to easily peer into a set (ie,
> multiple at the same time) of "snapshoted" file systems like I can via
> a NetApp fileserver/toaster/etc (for more info see the snapshot
> filesystem definition in my original post).  GoBack seems to make me
> restore the drive to see the older stuff.  It might have a "view/mount
> the recovery file" gizmo, but I doubt it presents it natively like I
> want.
>
> Nonetheless, it looks like a viable option.  That and Nik's reference
> to WinXP backup utility (presumably ntbackup?).
>
> -Matt
> --
> Remove the obvious text (including the dash) to email me.

[ Post a follow-up to this message ]