12-08-2011 12:41 AM
Hello all,
I have on several mail-archiving servers (EV9.02), the event 7116 and 7083 from Storage Crawler.
The folder location indicated is '\\VPNLAPP92513\EVStorageMA003\EVStorage4\EVStorage\1753\01-01\F\12D\F12D2DAD7B0D41484663944B5DD4F1D1.DVS'.
This is probably (seeing 1753) a spam-mail.It then says:
Retrieval of saveset failed and Failed to access file.
Retrieval of saveset failed.
Archive Id: 19281A2F7BF424648A4FA8F80B91438B61110000EV001
Transaction Id: F12D2DAD7B0D41484663944B5DD4F1D1
Extended information: The system cannot find the file specified. (0x80070002)
Internal Ref: Vault/RI
Is it possible to use the mentioned DVS, archive-id and/or transaction-id to actually locate the dvs file mentioned? I've been performing searches against the dvs filename, but have not been able to find it. There are no CAB-files containing this item.
Any hints to resolve this are appreciated
Solved! Go to Solution.
12-12-2011 02:47 AM
Your customer may want to verify the extent of the data loss by running the following, using EVSVR:-
If you are using Collections; VERIFY -> ArchiveObjects -> ObjectExtractsFromContainer
or without Collections (to save time); VERIFY -> ArchiveObjects -> ObjectContainerExists
You have references in your database that do not exist on disk. To remove these references you can run an EVSVR repair operation. REPAIR -> DeleteSurplusReferences. Using the information from the VERIFY operation, you could use the date ranges to save time processing.Make sure you BACK UP before doing this!!
All of this is in the UTILITIES guide, p102 shows a table and which Verify operation and what subsequent procedure. Hope this helps you.
12-08-2011 01:02 AM
I guess one way is to search the partition/s for F12D2DAD7B0D41484663944B5DD4F1D1.DVS
If it's not located from a file search I guess it's gone, maybe check the backups?
You could try the .hta script that Wayne posted in the following thread but I still believe that it needs the DB's to be correct.
So if you've tried EVSVR and dumpsaveset and that failed, then most likely the script will fail as well.
https://www-secure.symantec.com/connect/forums/it-possible-verify-dvs-file-dvssp-etc
12-08-2011 01:10 AM
The dvs file should be listed in the Vault Store database saveset table.
Try this query to determine the IDTransaction and folder path are correct:
12-08-2011 03:43 AM
Did you see this Technote? http://www.symantec.com/docs/TECH153523
12-08-2011 04:48 AM
12-08-2011 07:23 AM
GPKGuy, i checked the events, and have:
Reason: The system cannot find the file specified. (0x80070002)
Operation: READ
Reference: SDR/LF
Not Create.
@JW, I'll check.
12-09-2011 05:10 AM
File is not found. Nothing in Quarentine. As best practice, the storagelocations are excluded from scanning.
technote mentioned could be valid. The number of events is annoying. Could I create an empty dvs file having that name? perhaps copy an existing one?
12-09-2011 06:23 AM
In desperation I have seen some people but a bogus dvs file in a path to get around an error. but on a retrieval request you will error out. If youare absouletly sure the file is gone, then I would remove the db references for that item instead of putting a false dvs in place.
Have you confirmed the most recent backup of the storage location after the archived date has the file or not?
12-12-2011 02:47 AM
Your customer may want to verify the extent of the data loss by running the following, using EVSVR:-
If you are using Collections; VERIFY -> ArchiveObjects -> ObjectExtractsFromContainer
or without Collections (to save time); VERIFY -> ArchiveObjects -> ObjectContainerExists
You have references in your database that do not exist on disk. To remove these references you can run an EVSVR repair operation. REPAIR -> DeleteSurplusReferences. Using the information from the VERIFY operation, you could use the date ranges to save time processing.Make sure you BACK UP before doing this!!
All of this is in the UTILITIES guide, p102 shows a table and which Verify operation and what subsequent procedure. Hope this helps you.