Forum Discussion

marco_lelli-123's avatar
14 years ago

Deduplication Folder and "BLANK (WORM)" media

Hi all, I'm facing by months with strage problems related to the BackupExec Deduplication Option.

I'm doing B2D Jobs to collect data in parallel from Servers to the Deduplication folder.

After that Duplicate Jobs start copying data to TAPE for long term retention.

It happens that B2D jobs run fine but the related Duplicate job returns an error:

"Duplicate
V-79-57344-1541 - The requested media was mounted, but it has been erased and does not contain any backup sets.
"

Taking a look at the job log I understand that there was a problem with the virtual media in the Deduplication folder. The specific media is not marked a DSK, but is marked as "BLANK (WORM)".

Trying to take an inventory of the Deduplication folder causes other media to be marked a "BLANK (WORM)".

Has anyone seen a similar issue??

 

Thanks,

Marco

10 Replies

  • Try re-creating your backup and duplicate jobs.

  • deduplication storage media (OSTXXXXXXXX) is worm media by design.

    WORM stands for Write Once Read Many and is often associated with scratch media.

    Each time a job runs, expired media is scanned for and quick erased.

    Unless your retention periods lapsed and the media was erased by the engine, I see no reason to be concerned about the existance of the worm media.

    It would be helpful to test backups using the default "Keep Data Indefinately" media set and then have duplicates run after that.

    Also, there is a neat tool in BE 2010 called the Audit Log (Tools > Audit Log) which will show you the media being erased and when.

     

    Hope this helps.

  • Thanks dedupe-works, but my concern is not about the media marked as WORM, but that is marked as BLANK.

    After that the media become BLANK there is not way to restore or dplicate the data, the backup job must be run again.

    I'll try yor suggestion for the Audit Log to see when the media was overwritten.

  • Please check your Auidt Log.

    What you can do with it is save the file out to a disk, then importat it into Excel for ease of sorting/filtering.

    What you would look for is the phrase QUICK ERASE.

  • I've checked the audit log, but I haven't found the reason for the media to be marked as BLANK.

    The only related event I've found is the "overwrite" event when the B2D job start, and it's correct.

    Last week I've done a complete reitialization of the RAID, the volume and the Deduplication folder.

    The problem happened again yesterday on one job.

  • I am having the same exact problem... We backup to disk to a deduplication folder, then duplicate to tape for storage.... Every once and a while I will get a OST media that will go to WORM... problem is that its allocated that same evening obviously and though I might be able to see what it contained I cannot restore a thing off of it because it thinks its blank when its not... I am basically forced to erase the OST media because its useless at that point and it breaks up the entire set and I cant get a reliable backup to tape... Very frustrating! The only thing I found that seems to reduce the amount of times this happens is cleaning up the deduplication storage.... WHich is a very time consuming process!

    http://www.symantec.com/business/support/index?page=content&id=TECH130103

    If I do this once a week it seems to help... Although I understand this process is part of the normal maintenance routine which runs automatically I do seem to get a good amount of space back  and dont have this problem as frequently, although I do STILL have the problem which is what landed me on this forum tonight.

    I would love a permanent solution to this problem!

    Here is a screen shot of the media as it appears after it fails....

  • I have the same exact problem.  The best part is that the error lookup in the job log points to an article that doesn't even exist!  If you search for V-79-57344-1541 in the knowledgebase nothing shows up. 

    Recreating the jobs fixes the issue temporarily but it's only a matter of time before it comes back. That's not really a fix either.

  • After working few months with Symantec support we've found a working solution.

    There are two thing involved.

    The first thing seems related to performance issues, it's necessary to do a tuning of the dedupe folder related to the effective performance of the storage.

    In my case the storage was a RAID 5 made of 15 1TB SATA HDD ona an HP MSA2000.

    As suggested by the Symantec support I've reduced the parallel backup from 8 to 4 and the problem begin happening less frequently.

    This value must be tuned on the effective performance capability of the storage.

    The second thing is that I was using the "append or overwrite" for the B2D jobs.

    This causes an unuseful overhead on the dedupe folder.

    After changing the value to "always overwrite" the error is gone.

    I think that the "puredisk" windows porting is far from the perfection and suffers performance problems.

    I hope my suggestion could help to solve your problems.

     

    Marco

  • I have the same problem...  the error in the job log points to an article that doesn't even exist (V-79-57344-1541

    But after backup the policy duplicate to tape... and restore test (not all data) from tape is ok !