>Hi,
> The following scenario is what concerns me, say you are running a merge during which the VSC backup starts, at this time your posting prg has updated the parent record of a transaction but has only got around to updating two of seven related child table records, if this image is restored you will have a corrupt database.

Assuming you're talking here about file-server databases like VFP, I believe that's correct. If only two child records were updated at the moment the VSS snapshot was initiated, that's what would get backed up.

As far as I know, the only way around that problem is two-phase commit, which VFP et. al. don't natively support.

> The real curly one is if you look at a fragmented database, i.e. a record in the DB occupies two segments and the blocks that it occupies are distant to each other, it does take time for the system to move from the first sector block to the distant ones, if the image is taken during this move would have only the first part of the record update, again we would have corruption.

I think this one would depend on how/whether a VSS shadow copy handles pending disk operations/disk queue for that volume. I think that's something else two-phase commit is supposed to alleviate.

> If the system does wait for all caches to be flushed to disk (this can take quite a while when the system is at high load) and the user interprets the lack of response as a lockup and resets the workstation, again we have corruption.

Not sure you can do anything about that other than educate the users, or pop up a message on the workstations saying "Backup in progress - please wait".

>>>Hi,
>>> Most VSS backup systems quote that their backups are "Crash Consistent" i.e. it is an image snapshot at that exact time.
>>> I am asking for everyones views on this type of backup, especially with non VSS aware programs/DB's like vfp and the potential for corruption if an image is restored which was taken during a period of high activity in the Database i.e. the I/O's that are in progress and not as yet written to disk are lost, resulting in corruption.
>>>
>>> Any ideas on how to get around/overcome this problem.
>>
>>I've been wondering about this too so I did some research.
>>
>>The Wikipedia article seems like a pretty good overview: http://en.wikipedia.org/wiki/Shadow_Copy
>>
>>More details at http://technet.microsoft.com/en-us/library/cc785914%28WS.10%29.aspx
>>
>>Backups that make use of VSS are copying a read-only snapshot. If the volume was consistent/not corrupted at the moment the snapshot was created, any backup made from that should also be consistent (as long as it completed). The snapshot would not reflect any I/O (specifically, writes) to any files on the volume after the moment the snapshot was taken.
>>
>>One thing I'm not sure about is the issue of pending operations. I guess it really depends if the contents of the volume being shadowed includes the state of any virtual memory or disk cache operations that relate to that volume. I'd like to think the big brains at MS have thought about this and made VSS work properly. Virtual memory and cache are working constantly behind the scenes for all kinds of operations, not just DBs.