cancel
Showing results for 
Search instead for 
Did you mean: 

dvs file cannot be found, how to locate?

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

 

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

Regards. Gertjan
1 ACCEPTED SOLUTION

Accepted Solutions

MarkBarefoot
Level 6
Employee

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.

View solution in original post

8 REPLIES 8

FreKac2
Level 6
Partner Accredited Certified

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

Percy_Vere
Level 6
Employee Accredited

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:

 

Use 'Insert Name of Vault Store'
--Declare parameters
--Enter the DVS file under investigation here
declare @dvs varchar(36)
set @dvs = '499000000000000~200701261417260000~0.DVS'
declare @CSH int
declare @CSL int
declare @DT char(23)
declare @unique int
declare @dts varchar(200)
declare @time datetime
select @CSH = substring(@dvs, 1, 7)
select @CSL = substring(@dvs, 8, 8)
select @dt = substring(@dvs, 17, 17)
select @unique = substring(@dvs,34,1)
SET @dts = LEFT(@dt,8)+' '+
SUBSTRING(@dt,9,2)+':'+
SUBSTRING(@dt,11,2)+':'+
SUBSTRING(@dt,13,2)+'.'+
RIGHT(RTRIM(@dt),3)
Select @time = Convert(DateTime, @dts)
select
case when
SS.collectionidentity is null then 'Not Collected' else 'Collected'
end as Status
,IDtransaction
, '"' +
case when
SS.collectionidentity is null then
PartitionRootPath
+ '\' + convert(char(4),datepart(year, IdDatetime))
+ '\' + case when datepart(month, IdDatetime) < 10 then '0' + convert(char(1),datepart(month, IdDatetime)) else convert(char(2),datepart(month, IdDatetime)) end
+ '\' + case when datepart(day, IdDatetime) < 10 then '0' + convert(char(1),datepart(day, IdDatetime)) else convert(char(2),datepart(day, IdDatetime)) end
+ '\' + case when datepart(hour, IdDatetime) < 10 then '0' + convert(char(1),datepart(hour, IdDatetime)) else convert(char(2),datepart(hour, IdDatetime)) end
+ '\' + @dvs +'.dvs'+ '”'
else
case when charindex('.CAB', relativefilename) = 0 then relativefilename
else PartitionRootPath + '\' + relativefilename end
end as 'Location'
from collection
right join saveset SS on SS.collectionidentity = collection.collectionidentity
inner join Vault on SS.VaultIdentity = Vault.VaultIdentity
inner join EnterpriseVaultDirectory.dbo.VaultEntryView VEV on Vault.VaultId = VEV.VaultEntryId
inner join
EnterpriseVaultDirectory.dbo.PartitionEntry PE on SS.IdPartition = PE.IdPartition and PE.VaultStoreEntryId = VEV.VaultStoreEntryId
where savesetidentity in
(select savesetidentity from saveset where [idchecksumhigh] = @csh and [idchecksumlow] = @CSL and [iddatetime] = @time and [iduniqueno] = @unique)

MarkBarefoot
Level 6
Employee

Did you see this Technote? http://www.symantec.com/docs/TECH153523

JesusWept3
Level 6
Partner Accredited Certified
Maybe worth checking your virus scanners quarantine location also
https://www.linkedin.com/in/alex-allen-turl-07370146

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

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.

Regards. Gertjan

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

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?

 

Regards. Gertjan

TRALSH
Level 4
Employee

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?

MarkBarefoot
Level 6
Employee

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.