>HELP,
>
>I have a client that is running on a virtual 2003 server, with StorageCraft's Shadow Protect program that makes backups of files every hour.
>
>The application has a base directory that has free tables and a data directory below that that has a DBC and related tables.
>
>About three weeks ago (6/17 to be exact), using a VFP Executable that was implemented back in January of this year, the client at 4pm all of a sudden started to throw errors indicating that the files they wanted to open or save to were "not a table".
>
>I tried to open the DBC exclusively and got an error of the DBC not being a database.
>
>I use FoxFix and also DBF Recovery to try to fix individual tables and both indicated the errors were too many to correct. I tried to fix the DBC with both programs and got the same or similar error.
>
>I thought maybe the DBC got corrupted, but when I tried to open tables in the base directory which has the free tables, I got the same error.
>
>The luckily the Shadow Protect had a good version as of 3pm and that was restored and they went on their merry way.
>
>Yesterday the exact same thing happened (only this time at 5pm). In looking at the error messages I have emailed to me from the application, the corruption started at or very near to the time that a backup was taking place.
>
>I have a number of clients including my own firm using the same application with the same version (but to my knowledge no one is using Shadow Protect) and have never seen a situation where a whole directory and subdirectory of DBF files are corrupted all at about the same time.
>
>I thought about a virus but the server and the workstations all have virus protection running on them (Eset File Security) and to my knowledge there has been no indication of a virus being present in the system.
>
>Their IT person says there's been no update to either the Shadow Protect or the Eset application

Looking briefly online at the ShadowProtect product, I can't tell if it makes use of Shadow Copy (VSS) or not. Assuming (based on the product name) that it does, it should work for backing up VFP free or database tables/files.

As I understand it, the main issue with using VSS for backing up VFP data files is possible inconsistencies. These would mainly be of the form where the snapshot was taken in the middle of one or more VFP transactions, so referential integrity in the backed up data files may be lost. This should not cause corruption at the file system level such that you would get "Not a table" or other OS/file system related errors. Instead, you might find (possibly subtle) RI errors.

Another possibility would be if maintenance functions such as PACK/REINDEX were taking place at the moment the snapshot was taken. In that case the snapshot may be of files that are momentarily "corrupt" at the file system level because they are in the midst of maintenance operations. But, if this were the case I'd expect only one set of related files (.DBF, .FPT, .CDX) to be affected, not all the tables/files in one or more folders.

Depending on the configuration of your environment, there is one other thing I can think of, and that's the possibility of two (or more) VSS-enabled programs running simultaneously. On a single physical or virtual server, my understanding is only one VSS-enabled application can be running at a given time. For example, if you try to run Windows Server Backup and ShadowProtect backup at the same time, the first one wins, and the second fails with an error that it can't invoke VSS because it's already in use.

However, in a virtualized environment there's another possibility. Some VM backup programs such as Altaro Hyper-V Backup make use of VSS on the host when backing up guest VMs. I don't know how this works in detail but at the very least it must be using VSS on the VHD file (if it mounts the VHD as a separate volume). This is speculation on my part, but problems might arise if:

- the host is using a backup program with VSS (call it Altaro) to back up a VHD file
- another backup program such as ShadowProtect is running on that guest, and also uses VSS (on the guest)

The two processes are essentially using VSS on the same volume simultaneously, but they don't report a conflict because as far as ShadowProtect is concerned, it's running by itself on a physical server, and as far as the host is concerned, only Altaro is using VSS to handle the VHDs.

I'd like to think in this case you'd get "nested" VSS (i.e. nested journalizing of the file systems) and everything would work out fine, but that may not be the case, especially if ShadowProtect on the guest is "VM aware" and/or Altaro on the host is "guest-aware" or "guest-integrated".

Again, this is speculation on my part. But, you can quickly find out if it might apply:

- Does a separate VSS-enabled backup product (e.g. Altaro, Windows Server Backup) run on the host computer?
- If so, does its backup duration collide with any scheduled ShadowProtect VSS backups on the guest?
- Does any other VSS-enabled application run periodically on the guest (e.g. scheduled System Restore Point creation)?
- Is the ESET security product set to do any scan or other operation on a scheduled basis? I believe some products are starting to use VSS for certain operations

Beyond that, you're in the situation where nothing seems to have changed, but clearly something has, so you need to track it down:

- Are the storage subsystems on either the Server 2003 guest, or the host server, under heavy load?
- Any unusual messages in System or Application Event Logs on the guest or host?