This post is just trying to be helpful for people who encounters the same problem. No need to resolve this issue, already figured out.
Hope it helps for you too!
So the story:
Our backup server has a pretty huge amount of disks, so we are saving backups to local disks. I've created a Synthetic Disk Storage on the Deduplication Disk Storage (I know, I'm bad, however it can be done, but not recommended by Veritas). So the Deduplication & Synthetic Disk Storage became full. I had to pause the Deduplication Disk Storage, and delete the Synthetic Disk Storage. I've managed to get back a lot of storage space. Hurray!
So I made another volume and created a Synthetic Disk Storage, restarted the BE services, created a job there, tested it, works.
However, on Deduplication Disk Storage, strange things started to happen. Even when it was set from pause to active, backup jobs started, but queued to a very very long time, and after that they started to fail with 0x2000040d - S_TF_NO_TAPE_PRESENT error. Restarted BE services did not help, but a complete restart of the server resolved my issue, all the backup jobs started working.
The error can also occur if there is any internal corruption reported within dedupe. Just means we cant create a media to write to it.
I'm also experiencing the same issues on Backup Exec 15.
We're unable to use the DeDup storage at all. When trying to run a backup or restore job, the job queues for a long time and then failed with error 0x2000040d - S_TF_NO_TAPE_PRESENT.
Tried restarting services, inventory & catalogue and restarting the server all of which have not worked.
Are there any log files we can collect to get assistance from Veritas support. It's a major issue. We've had to switch our backups to use disk storage for now but our disk drive is filling up fast.
need to first make sure the dedupe folder is in good state.
when did the issue start ? any issues on the server or disk hosting dedupe ?
Case 1 -
open command prompt (run as administrator) - change dir to BE Install Path
You can post the output of above.
run crcontrol.exe --processqueue (run it 2 times)
you can then check the status of processqueue by running the command - crcontrol.exe --processqueueinfo
The status shows something like this (Busy - Yes, Pending - Yes). Monitor the dedupe\log\spoold\storaged.log (if this runs fine then dedupe should be allright but if you notice errors in this storaged.log (from the time when you started the processqueue. You can filter the log with string "ERR") then you will need to contact tech support.
Case 2 -
Apart from this the message can also occur (i.e. when case 1 does not show any error) when a remote server is backed up with client side dedupe set in job settings -> storage, in case the beremote on remote server is unable to connect with the dedupe engine or dedupe manager on BE server. Test the backup with server side dedupe set in the Job.
I'll give your suggestions a go and see how I get on. I've been experiencing the issues for several weeks. There are no outstanding issues on the server or the disk/raid hosting the deduplication storage.