|
Home > Archive > Data Storage > July 2004 > Re: Looking for incremental snapshot utility for NTFS, FAT32
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Looking for incremental snapshot utility for NTFS, FAT32
|
|
|
| Check out www.storagecraft.com and download Volume Snapshot.
Jamey
"Thanatos" <dgahan@europe.com> wrote in message
news:40ad947e@dnews.tpgi.com.au...
> 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...
>
>
|
|
|
|
|