cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot overwrite/associate RDX cartridges

Agility
Level 2
Partner

Hello all,

I've had an SBS2011 installation running Backup Exec 2012 running for 6 weeks now, backing up to an RD1000 drive (Dell server).  Everything was brand new, the server, the software and the RDX drives.  All has been running well up till this week when one of the backups started failing, complaining that the RDX was not overwritable.  Looking at the All Media view, I can see that two of the RDXs have gone into a different media set (Backup Exec and Windows NT Backup Media) and have been put onto complete overwrite/append protection.  This appears to have happened autonomously.

I've tried to associate the problem RDXs with the correct media set, but the option is greyed out.  I've wiped them, re-inventoried and even formatted them in Windows, but nothing I do seems to "unlock" them.  I've checked the physical lock switch on them hasn't been set, so now I'm stumped.  I've even brought a brand new RDX, and as soon as it went into the server it went into the same status.

I've just applied SP1a, to no avail.  Does anyone have any suggestions?

 

36 REPLIES 36

Andrew_Griggs
Level 3
Partner

Quick update for anyone watching this thread.  Hotfix for being unable to delete RDX media is out:

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

I'll be installing it this week and will post my findings.

I am also testing the orphan hotfix for GRT backup sets not expiring and I'm seeing good results, so hopefully the official fix will go live soon.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

That hotfix covers just for deleting the FLDR media from the console, which you should only need to do if you are retiring a cartridge from being used by Backup Exec.

 If you have the IMG folders not reclaimed/overwritten issue and you apply the Hotfix mentioned in TECH191513, then you will need an updated version of the orphan/private fix - now numbered as 26.12

LPTCsupport
Not applicable

The hotfix for deleting the FLDR media from the console is no longer available.  Also we are having the issue with that requires the orphan fix 26:12 but I am very hesitant to deploy this into a production environment.  What is the ETA on an official fix for this?

Will_Salen
Level 3

I have the same issues.  Called tech support and they referred me to http://www.symantec.com/business/support/index?page=content&id=TECH187957.  They stated I would have to manually delete the RDX media the first time after changing the registry entry but from that point on it should be able to overwrite.  Since I use a different RDX media each week, will will not be able to test automatic overwrite for another 4 weeks.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

If you have the IMG folders filling up the RDX disk issue then the technician should have referred you to

http://www.symantec.com/docs/TECH192382

Note: This tech was recently been edited to state that a supported hotfix is available as long as you log a formal support case.

 

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Hotfix 199190 was withdrawn due to a stability issue with the BESERVER process.

Orphan 26.12 depended on Hotfix 199190 so should only be used if you have that Hotfix and are not seeing BESERVER stability problems.

If you are seeing BESERVER stability problems with Hotfix 199190 then please uninstall it and use Orphan 26.11 for the RDX IMG reclaim issue instead

You will need to speak to Tech support to be issued with the correct orphan version if you do not already have it.

A complete replacement for Hotfix 199190 (with a new number) will be released soon.

Will_Salen
Level 3

My case was titled "Need hotfix for TECH192382", but they referred me to http://www.symantec.com/business/support/index?page=content&id=TECH187957.

Chuck_Bridgelan
Level 2
Partner Accredited

So, I've applied the service pack manually.  This appeared to go successfully  I've made the registry change.  Then I restart services and run BE 2012.  Liveupdate sees SP1a as needing to be installed and attempts to install, but that fails.

How can I tell if SP1a is properly installed?

The cartridges I'm working with are still stuck in the "Backup Exec and Windows NT" media set, with no expiration (so, presumably no grooming), and still with no option to them to the backup set I want them in.

So, I'm not sure this is helping me.

Is this going to be fixed, or should I be looking for a different backup product?

 

 

 

 

 

 

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

THE IMG delete will eventually be fixed by public fix, however for the time being YOU MUST log a formal support case to receive the controlled/private release

Also note we are not fixing the FLDR* media being seen in the  NT Backup set as that bit is actually by design, the bit you are missing is it is not actually FLDR media that get deleted/reclaimed to free up space once their retention period expires it is the IMG and BKF media that is contained inside an FLDR and these media types are not obviously exposed in the console

With regards SP1a check in installed updates within the Backup Exec admin console as the LibveUpdate link tio what is already instaleld sometimes get stuck on SP1a (oh and you should log a separate formal support case for that issue as well so we can investigate.)

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Sorry Will, you should get the case re-activated and if necessary quote this forum thread to get the private fix.

IGE
Level 1

Hi, i have the same problem on our Backup Server. It's possible to get the Fixpack ?

Thanks in advance.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

You have to log a formal support case to get the update it CANNOT be issued via a forum request.

And customers that already have the fix are not allowed to distribute private/orphan fixes to 3rd parties without Symantec permission.

lsvasset
Level 2

Colin, is thier a patch#/orphan# we can refer to when calling/creating a ticket?

lsvasset
Level 2

Colin, is their a patch#/orphan# we can refer to when calling/creating a ticket?

Daniel_Donaldso
Not applicable

Hi there,

 

is this fix out? I appear to be having the same issue with my customer running bexec2012, their rdx carts don't want to overwrite any longer, despite a valid overwrite protection schedule

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

The Hotfix that was released just over a week ago (201596) does not address IMG reclaim issue on RDX but does address the ability to delete an FLDR media object should you ever need to. Note : It remains by design that this media object type is fixed to the NT Backup ... etc media set.

The Orphan (Beta) update for the IMG reclaim has had to been updated to be compatible with the new hotfix so if you apply the new hotfix make sure you get the updated Orphan via a formal support case. Bear in mind it is recommended that you remove any orphans before installing newer Hotfixes. Anyone who already has an older version of the Orphan should still have an open case and should just contact their current engineer.

If you need the Orphan and don't know the details then you can just quote http://www.symantec.com/docs/TECH192382

 Currently (and this is subject to change) the public fix for this will be in the same planned update that will suppprt things like Windows 2012 and ESX 5.1

Keith_Fountain
Level 3
Partner Accredited

We have resolved this issue as follows.

 

Create a file called RDX.cmd and populate it with the line below. Put it in a folder on the hard drive of your BUE server, such as imgcleanup.

 

for /f "tokens=*" %%i in ('dir %1 /b') do rd "X:\%%i" /s /q

 

Where X is the drive letter of your RDX drive.

 

Set a pre command in your job to call the file, so C:\imgcleanup\RDX.cmd "X:\img*"

 

When the job starts it will clear ALL of the folders that start with img from the drive you specify. We have been using this solution for a couple of years now and it works perfectly. Please ensure you run this in a test environment before deploying to your production servers.

This will obviously work for disk based storage as well as RDX drives by replacing "X:\img*" with either a mapped drive letter or unc path.