Everhart, Glenn (FUSA)
From:	Everhart [Everhart@gce.com]
Sent:	Tuesday, April 13, 1999 6:24 PM
To:	Info-VAX@Mvb.Saic.Com
Subject:	RE: Snapshot news from COMPAQ
Snapshot isn't the only method to get an incremental of a file.
Journalling changes can produce the same effect when combined
with a pre-existing complete backup and with suitable data
recovery software. The journal of changes might need to be
postprocessed to save only the last update to a disk block
but logically a journal of blocks written with blk number and time
is precisely an incremental backup. Whether RMS Journalling can
do this I don't know. I wrote a virtual disk that can do this some
years ago; at that level it is certainly possible. The code is even
available.

A snapshot gives you the data as of the point in time of the
snapshot. A journal gives you the data as of the point in time
of the end of the journal (or the end of what you're using). The
same kind of rollbacks can be arranged but the complexity goes
more into the restoration code.

What you are presented with in a snapshot is after all a complete
disk as of some time. It is also to be expected that you cannot
make an indefinite number of these snapshots without some hits to
performance (in most cases; there may be exceptions such as where
data is essentially never rewritten). 

Being able to treat a snapshot as readonly with no risk of data being
overwritten may induce some locking savings that will be harder
to reproduce with a journalling system, but even those savings can
be replicated with a system that uses logs. Consider the system
I put on the sigtapes that reads backups off tape and presents them
as disks. With a bit of jiggery-pokery, that system could be made
to present a backup PLUS a journal as a disk, current to the point
of the end of the journal. It would just need to read the journal to
know
what blocks were where, and then when asked for a disk block
get it off the journal in preference to the system backup and present
it. A system that did before-write journalling could manage this kind
of trick based on the current disk.

The descriptions from Compaq seem to me to include these kinds
of notions, though vaguely. At this point I can't tell how much of them
might be included. Still, abandonment of the snapshot machinery
does not mean abandonment of the functions.
Glenn Everhart

> -----Original Message-----
> From:	Alan Greig [SMTP:agreig@my-dejanews.com]
> Sent:	Tuesday, April 13, 1999 7:10 AM
> To:	Info-VAX@Mvb.Saic.Com
> Subject:	Re: Snapshot news from COMPAQ
> 
> In article <3712a995.15019797@news.ne.mediaone.net>,
>   mahan@mediaone.net (Joe Mahan) wrote:
> 
> > Other folks were planning to use Snapshot for other things. For
> > example, Snapshot was the only practical means to get an incremental
> > backup of a large container file,like an NTDS "disk". So, with the
> > death of snapshot we have the death of VMS as a disaster tolerant
> > backend for NT.   (Not that it ever caught on as one, anyhow...) As I
> > understand it, the "enhancement" mentioned above does not address the
> > container file problem. So it will not  "replace" the Snapshot project
> > in functionality. Maybe it will replace the Snapshot link on the
> > website...
> 
> I had in mind allowing previous copies of a DBMS database to remain online
> while certain exclusive updates were performed on the live database. Only
> some of this functionality can be achieved using DBMS's own snapshot
> facility.
> 
> Oh well never mind... Just have to stick with the old method of
> duplicating
> gigabytes of information.
> 
> >
> >
> --
> --
> Alan Greig
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>