Video Screencast Help

Media Not Being Purged- Manual Delete Error "Unable to Delete {0}"

Created: 20 Feb 2013 • Updated: 27 Aug 2013 | 10 comments
This issue has been solved. See solution.

Been having alot of issues since upgrading to Backup Exec 2012...One that is really getting on my nerves is my backup storage always running out of space.  BE should be auto-purging the last backups to make room for new.   Anyway, up until now I was going in and manually deleting backup sets older than 2 weeks.  When I do that, I get the message about "dependant backup sets" which I always say "yes" to then I get multiple instances of "unable to delete {0}".  I click "ok" on them (usually get it like 20x when deleting a few weeks of sets)

What is up with that error and how can I ensure that BE starts to auto-purge the old sets? My searches found little to nothing about my specific error but this article came up (http://www.symantec.com/docs/TECH187957 ) anyway implementing this registry change did nothing.

 

My Media is an eSata external mirrored 2 TB solution from HiRely.  If I go to the media information it shows "Overwrite protected until: Infinite - Do not overwrite".  It is greyed out without an option to change it.  The media sets in the jobs show as between 14 and 7 days, depending on the type of backup I am running.

Anyone?

Before I scrap Backup Exec all-together and find a new solution? Been using it for quite a few years/versions and wouldn't mind staying on but this new build kind of sucks...also had a case open about P2Vs not working and support takes weeks to respond then just stops as they can't figure it out lol

 

 

Operating Systems:

Comments 10 CommentsJump to latest comment

Colin Weaver's picture

2012 does not use media sets for disk storage backups It used DLM which is based on the retention in the job properties and NOT the retention in any media sets.

DLM has some hidden rules for deletion(reclaim) of expired sets that are designed to protect Backup Admins from not understanding what might be a critical backup set and overwriting early.

For instance we will not let a full backup set be removed from a system if an Incremental or differential set depends on it. Typically the message you quoted about dependent backup sets is an indication that this is what is happening to you.

We also don't let you delete the last complete backup set of a given selection  which may also be part of your issue.

 

EDIT: For more info on DLM suggest you review this

https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012

jason.lehr's picture

Thanks for your response.  There is no setting that I can tell in the actual jobs that has anything over 14 days  (the media set setting), besides one yearly Exchange backup I do to a local server folder with 52 weeks retention.  That being said, none of the other server backup jobs are properly purging old media.  I am doing full backups every week and incrementals or differentials during the week  (SQL and Exchange are doing incrementals as suggested by Symantec).  They should only be dependent on that last full backup...

If DLM rules are hidden what can I do about this? Also why is the media properties showing "Infinite- Do not Overwrite" as that setting exists no where in my jobs or in BE job/storage defaults...

Colin Weaver's picture

PKH's docuemnt is almost certaainly worth reading in addition to the linkl I posted. 

Just to answer your specific question however: Because DLM does not use media sets, any media that is managed by DLM shows up inside the Backup Exec databsee in the "Infinite-Do not overwrite media set" just as a holding location. Normally the DLM managed media in this set is NOT exposed to the BE console, however if you enable the ShowHiddenMedia registry key it becomes visible.

bdubya's picture

I have encountered this issue as well. Another thing I noticed when the "Cannot delete the {0}" error appears frequently, is that there are numerous duplicate entries in the backup set viewer under the storage tab.
After performing an Inventory / Catalog operation on the NAS device in question I was able to see that the duplicate backup set entries had been removed from the view and the error only occured once after deleting about a dozen or more backups and dependent sets.

It's worth noting that the inventory/catalog job actually threw a failure during catalog operations, but the desired effect was still achieved. Hope this helps.

WARNING MASSIVE ASSUMPTIONS BELOW :)
I assume that the numerous errors were due to a broken catalog or Backup Exec being unable to accurately recognize and display the media items contained on the disk. After the failed inventory/catalog task successfully updated the media items on the device in BE I only encountered the error once.
This remaining error I assume is related to the DLM feature forcing retention of that particular item.

It is frustrating that the error is generic, is there work being done to add specificty to this error, as in :
unable to delete the instead of unable to delete {0}?

jc_Independent's picture

No solution from me, but I have a client with same issue.  DLM set to hold only 3 weeks, works fine for number of months.  Then out of disk space - go clear and I get delete {0}

Support has nothing.  Wasted 4 hours today when I could have been working on other tasks.

Replaced controller, created new arrays. When it happens after deleting I get "query failed" trying to get to datasets now, so perhaps it’s a Backup Exec database issue.

DLM where it must have made sense to someone - has really tied my hands on resolving.  I am backup eng. that can set proper retention sets.

jason.lehr's picture

Opened a support request and it turns out when my storage was originally setup it somehow got configured as a "disk cartridge".  I had to go through hell-and-high-water to delete it; ended up deleting it through the SQL database.  Anyway it should have been configured as "disk storage".  So I don't see the "unable to delete {0} " messages anymore and if it doesn't prune old backups I'll report back as well as re-open my ticket with Symantec. Now on to figuring out why the job engine crashes every weekend on my full backups. yay.

SOLUTION
jason.lehr's picture

It worked for me.  I since moved it off to another server, confirming that it was setup as disk storage instead of disk cartridge

astewart504's picture

Ok thanks. I'm having the same problem and I think mine was setup similarly before my time.