Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Why are the IMG0000xx folders not erased from a RDX Cartridge in the B2D cycle?

Created: 27 Aug 2012 | 51 comments

Below is a screenshot of the file structure of a RDX 160GB Cartridge.
Whenever I run the erase command on the cartridge only the \VERITAS\B2D\*.bkf files are erased.
These IMG0000xx folders continually remain and cause the backups to fail because the cartridges run out of disk space for the next backup.
These folders contain backups of Microsoft Exchange.

Why are these folders not overwritten or erased in the B2D cycle?

Comments 51 CommentsJump to latest comment

Backup_Exec's picture

Hi

Pease check link below which descibes issue with not getting overwritten

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

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

Thanks

Sameer

Don't forget to give a "Thumbs Up" or Mark as "Solution" if someones advice has helped you.

Sush...'s picture

Hello Philip,

    In addition to the above technotes, we do have a private fix for this issue which will be released after testing. If you want the fix before it is public hot fix then I would request you to open a support case with Symantec and then Tech support can help you to fix the issue with the private fix.

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Philip Lakic's picture

Manual work arounds are not a solution especially if these issues have been around since version 12.5.
I want to set these backups going without having to log onto the server every second day to delete a bunch of IMG folders and files that should be automatically overwritten.

My backup exec settings already reflect the settings outlined in TECH189356. I have no issues overwriting the BKF files in the B2D folder only the IMG folders and files are not overwritten.

I have BE2012 - those hotfixes apply to version 12.5 and version 2010.

I set the inventory drive to a schedule, but I can't even see where that inventory job is available in the BE2012 console to confirm it's actually going to happen.

Sush...'s picture

Hello Philip,

   The private Orphan fix that I have mentioned is for Backup Exec 2012. So if you want the fix before it is released as a Public Hot fix then you may open a case with Symantec Support and they will be able to help with the fix.

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Philip Lakic's picture

I'm using the trial version at present so will they give me access to the fix?

Sush...'s picture

If you have a support contract then you will be able to open a case. Ones the case is opened then you will be provided with the fix even if you are using Trial version.

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Philip Lakic's picture

I'm a reseller trialing the software for a client of mine.
The cilent has some support contracts based around System Recovery 2011 but nothing for BE2012.

I'm not moving the backup software away from CA R16 unless I can get this trial version working, hence my need for the fix.

Backup_Exec's picture

Hi

Q

The cilent has some support contracts based around System Recovery 2011 but nothing for BE2012.

Ans :Best would be to call the suppor and check if they allow you to open the case or not checking all the information.

Thanks

Sameer

Don't forget to give a "Thumbs Up" or Mark as "Solution" if someones advice has helped you.

CraigV's picture

...do you guys now offer support to trial products?

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Backup_Exec's picture

Hi Craig

The above answer from my post refer to question asked by OP

The cilent has some support contracts based around System Recovery 2011 but nothing for BE2012

So has OP client have got support for BESR product best would be to get in touch with support to see what best can be done.

Thanks

Sameer

Don't forget to give a "Thumbs Up" or Mark as "Solution" if someones advice has helped you.

Philip Lakic's picture

Seriously your technical support department is useless.
They wont help me because I have no support agreement on the product. I was bounced around to 3 different departments and nobody seems to comprehend what I'm asking for...

The whole point of trialing BE2012 is to ensure that it performs like it was intended. Why make a hotfix if it's not available to everyone?

All I want is the hotfix!

The fact that this issue has been around since BE 12.5 and still occurs in BE 2012 is very poor.

Sush...'s picture

Hello Philip,

Why make a hotfix if it's not available to everyone?

This is currently a private fix and after all testing is done it will be released public for everyone to download and install it.

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Philip Lakic's picture

Sush: All I want is the hotfix! I fail to understand why someone from Symantec cannot get in contact with me via email and provide me with a link to the hotfix so I can download and install the fix to see if it sorts out the issue outlined in this forum post.

Colin Weaver's picture

Hello Philip

Private hotfixes of this nature are similar to Beta Fixes and are only released in a controlled way to customers that definitely have the issue concerned and in order for us to get immediate feedback if the fix either a) works, b) makes no difference to the problem or c) makes something worse - which is rare.

In some cases a common error message can be caused by different background problems making a specific private fix invalid, having an open support case helps us to confirm this. Note in your case I think you do have the documented issue however it is not always so obvious without looking at debug logs

As such the process for our engineering team allowing the release of a private fix to a customer is via a support case not via a forum thread.

As an aside any customers that received Private fixes (known  as Orphans) by Symantec should not give them to any 3rd party companies without permission.

Philip Lakic's picture

Colin: I can appreciate your procedures in relation to beta fixes, however this issue seems to have been around since Backup Exec versions 12.0, 12.5, appeared again in version 2010 and then again in Backup Exec 2012. It seems to me that you've had 3 iterations of the software to get this issue sorted and yet the problem still exists!

I have 17 days left of the BE2012 trial version. If this issue isn't fixed within that time period I will have no further choice as a reseller and a systems integrator to point my clients elsewhere for backup software. 

A little bit of professional courtesy and some special consideration surround this issue would go a long way to getting this issue resolved and potentially alleviating the problem for other users of your software with the same issue.

Colin Weaver's picture

Just to be clear this issue is a completely new problem for BE 2012 and relates to the differeces between Media Set Handling and the new DLM process. Any problems relating to IMG folders not deleting in older versions of Backup Exec were resolved and related to different back end processes.

If you are serious about intending to purchase backup Exec if you can see this compoennt working then please speak to our pre-sales teams and explain your issue, as a reseller you should have some form of pre-sales contact available to you.

Philip Lakic's picture

I have spoken with symantec's technical support department and with various sales teams within symantec regarding this issue except that none of the employees I speak with seem to understand what I'm asking for. You'd think I was speaking another language with the complete lack of understand I've received from those departments. I spent over 30 minutes being bounced around between departments because no one could action and comprehend my request. In the end I gave up.

If you're really able to help Colin, then please provide me with a name and a number of someone who will actually be able to assist with this issue. Or point them to the forum post and have them email me.

Bulbous's picture

I am also waiting for this hotfix. The Tech Notes posted above refer to BE 2010 and prior - is there a Tech Note for this issue for BE 2012?

Peter Sheridan's picture

Hi,

I am also having this same issue with BE2012 and the IMG folders not being overwritten. I am using USB Disk storage though, not RDX media.

I will contact Symantec tech support on monday and try and obtain the hot fix and post back if it works successfully.

Thanks

Peter Sheridan's picture

Just got off the phone from tech support and the guy didn't know what hotfix I was referring to (I even showed him the forum).

Apparenly I will be getting a call back from the small business server team (since i am using SBS 2008) and hopefully they will know what hotfix i am referring to.

I very much doubt it is a small business server issue but will see how we go!!

Sush...'s picture

Hello Peter,

    May be since you mentioned HOTFIX the technician may have got confused. You can tell the agent to specifically look at the technote " http://www.symantec.com/docs/TECH192382 ". At the bottom of the technote we have provided the Etrack number 2844365 .
This number is used to track the defect. You can ask the technician to check this etrack and confirm that the issue that you are facing are exactly the same as mentioned in the etrack and its for same version of BE. After this is fully confirmed ask them to escalate the case.

BTW, can you PM me the case number which you had opened?

Thanks,

-Sush...

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Bulbous's picture

I wasn't able to get the hotfix for the case I opened. I didn't have any trouble with tech support - referencing the Technote and the Etrack number was enough to get me to a level of support that was able to confirm the problem.

Unfortunately, in my case, the only reason why the IMG folders were being created in the first place was because I had (somehow) installed a trial of the Active Directory Agent, which uses GRT. The solution presented to me was to uninstall the agent trial, after which no more IMGs would be created for my environment.

Kind of a workaround to the problem, and I didn't really force the issue. I will be setting up another RDX soon that will be backing up Exchange, so I will be opening a new case at that time. I'll keep you posted.

I was advised that the Hotfix for this problem should be published in the near future, but you can always call support to get it in the meantime.

Peter Sheridan's picture

I ended up getting the hotfix after tech support confirmed i was having the same issue.

Am yet to apply it, but will hopefully do that today if no on Monday.

Peter Sheridan's picture

Just to update everyone on this. After the hotfix had been applied the IMG folders are being successfully overwritten....

However overwritten is probably not the best term though. What it does is actually deletes any IMG Backup sets that have past their Overwrite protection period. This can happen at any time, not just when a backup job runs.

For example, say you backup exchange, and protect the media for 6 days. As soon as that media is 6 days 1 hour old, BE and DLM will Groom and delete that backup set.

I'm still undecided on this concept though, as if a clients backup isn't working, they could essentially be left with NO GRT Backups because backup exec just kept on deleting expired backup sets.

On the other hand, lets say it is a good idea (and there are reasons as to why it is), then why not have it clean up .bkf files as well? Why is it only doing IMG folders? If the concept is to clean up storage devices, such as NAS and USB Drives it would make sense to do the same with .bkf files as well.

Before Symantec release an official hotfix for this, I would really like to see this idea considered, as to me it appears to be half completed atm.

Cheers

Peter Sheridan

Colin Weaver's picture

Just to to clarify IMG folders never do get overwritten in any version of Backup Exec which is why we use the term "reclaimed" as we actually delete them (exactly when depends on BE version and storage device type)  

Also DLM by default will not delete the last copy of any specific backup set no matter if it is beyond the retention time or not (so you cannot be left with no backup) although there is a registry key to change this behaviour .

Also BKF files are handled by DLM in the same way that IMG is (RDX being a special case for IMG and BKF where media set control is still used) 

We do have another defect affecting unplugged USB drives (or offline/disconnected NAS drives), that is not the same cause   as for IMG on RDX, that means that BKF and IMG media may not be reclaimed on these devices if they are disconnected when the DLM activity takes place.

Philip Lakic's picture

Hi Peter,

I never had a problem with the BE2010 overwriting my BKF files according to my media set properties, only those IMG folders.

Do you have a name or number for the hotfix that was given to you? I only just bought a copy of BE2012 so now I'm entitled to the support and the hotfix.

Cheers,

Philip Lakic

Peter Sheridan's picture

Collin,

Thats good news about the last backup set not being deleted. Does that apply if the backup set didn't complete successfully? As in, say it failed verification, will it search through and find the last successful one?

Re the other defect, so this is known to Symantec and is being looked at? I can confirm what then my .bkf files are expired that the USB drive is not connected to the server. So that might be why.

Philip,

Yep the hotfix was called BE1401798Orph26.7. If it helps as well the lady's name that originally dealt with the case was Smita Vinchankar.

Cheers

Bulbous's picture

I have called in and obtained the Hotfix. However, you need to manually tell BE how many folders to expire.

This isn't going to work for me. We use a custom cartridge rotation of Monday to Thursday and Friday 1-5.

That means, on the third Friday of the month, you would use the Friday-3 cartridge - so the Friday cartridges are only used monthly. (Monday to Thursday are used weekly).

We will need this data to be retained for a month, not reclaimed due to the auto-expiry settings. And the Friday-5 tape is only used a few times a year!

Peter Sheridan's picture

Really? I didn't have to do anything like that. Where do you specify how many folders it is going to delete?

If you set the expiration to 6 days it shouldn't be a problem for the Monday to Thursday drives. With the friday drives though, since they are only going to seen one a month, care needs to be taken to put the correct friday drive in otherwise it will be cleaned up.

I still don't get why they arn't cleaning up .bkf files as well as IMG folders though...

Bulbous's picture

I had to and add a DWORD "AutoExpireGRT" under HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\Misc as directed by the readme file and also a tech who contacted me to help me determine the right value to enter.

The jury is still out on the Friday settings. I may need to configure additional media sets with different retention settings.

Colin Weaver's picture

Hi Bulbous

 As long as the number is bigger than needed it will sort it out, I have been setting 200 for this reg key until you have cycled all the cartridges at least once after applying the update, after that you can probably drop the number down to maybe 10 or 20 (kind of depends on how many backup sets are created on each cartidge in a day)

Donald Eady's picture

Peter, 

(I still don't get why they arn't cleaning up .bkf files as well as IMG folders though...)

In the settings of the job do you have it configured to "overwrite recyclable media before scratch media" or do you have it set to "overwrite scratch media before recyclable" if the later please choose "overwrite recyclable media before scratch media" please view the following doc.

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

 

I hope this posting was helpful

  

Peter Sheridan's picture

Donald,

I have the job configured for "overwrite recyclable media before scratch media".

Don't get me wrong, they are being overwritten properly... But only when the back job runs.

I would have thought since IMG folders are being cleanup up as soon as the backup device is attached to the media server or when DLM Grooms the backup sets, that .bkf files would behave the same way and be cleaned up as well...?

Bulbous's picture

Actually, one of the technicians was going to get me confirmation on exactly when the IMG folders are reclaimed... when the cartridge is inserted, or when the next backup job runs? Are you able to explain?

Peter Sheridan's picture

What I’ve found is it pretty much happens immediately  of the drive being inserted and detected by backup exec.

For example, i'll connect Thursdays Drive, walk back to my desk, and by the time i get there Backup exec and DLM have already deleted all of the expired IMG Folders and backup sets.

Now, i'm sure there is a schedule it runs on as well, but perhaps when media comes online it gets triggered as well..

.bkf files are still only being over written at the time of the backup and when needed. And " overwrite recyclable media before scratch media" has to be configured in the settings as well (or if the destination is full that it will forceablly overwrite expired media).

pkh's picture

The DLM grooming cycle runs every 4 hours or when the disk gets full.

ClarkL's picture

I've run into the problem with DLM grooming leaving orphaned BKF files and IMG folders. This appears to be due to the grooming process deleting the job information and catalogs. If the disk was attached it would delete the related files and folders from the disk storage. With the disk not attached the DLM fails to remove the backup files but doesn't have any process to work around offline disks, so they're simply left on the disk. In Backup Exec you'll see your disk as partially or entirely full, with no backup sets. If you run an Inventory and Catalog operation it will find those old backups, however Backup Exec assigns those files a retention period of 1 year from the time you catalogged the disk.

As a work around until the issue is fixed within Backup Exec I've written a batch file using the FORFILES command to hunt down backup files that were not removed and delete them as a pre-command on the job.

Here is the batch file I wrote to do this:

@echo off
REM This batch file will process old/expired backup files and folders
REM and remove files older than the time specified.
 
REM TIME PERIOD
REM Specify the maximum age of a backup file before it is deleted if Backup Exec has not done so automatically.
REM Specify the number of days as a negative value.
REM To delete backup files older than 30 days, specify -30.
REM To delete backup files older than 4 weeks, specify -28.
 
Set TimeValue=-30
 
REM SCRIPT LOCATION
REM Specify the file path for the script directory on the server.
 
SET ScriptLoc=C:\BackupScripts\
 
REM DRIVE LISTING
REM Specify the name of the file located in the Script Location which contains the list of disks to process.
REM Copy the full path from within Backup Exec 2012, under the Details of each USB backup drive on the Storage tab
REM to the contents of the DriveList file. Use a seperate line for each drive.
REM Drives must be assigned a local drive letter, Volume ID is not supported by FORFILES command.
 
SET DriveList=DriveList.txt
 
REM This command removes the BKF files found within the BEData directory.
 
FOR /F %%i in (%ScriptLoc%%DriveList%) DO FORFILES /D %TimeValue% /P %%i /M *.BKF /C "cmd /c DEL @file"
 
REM This command removes the Disaster Recovery files found within the BEData directory.
 
FOR /F %%i in (%ScriptLoc%%DriveList%) DO FORFILES /D %TimeValue% /P %%i /M *.DR /C "cmd /c DEL @file"
 
REM This command removes the IMG folders found within the BEData directory.
 
FOR /F %%i in (%ScriptLoc%%DriveList%) DO FORFILES /D %TimeValue% /P %%i /M IMG* /C "cmd /c RMDIR /S /Q @file"
pkh's picture

You would probably have a problem with your catalog.  When you just delete the .bkf and .img files, the corresponding catalog entries will not be removed.

ClarkL's picture

The catalogs are already removed, the DLM grooms them out but as the disk is offline doesn't do the BKF or IMG folders because it cannot and does not monitor or watch for those files later. DLM makes an attempt to remove them, fails and just doesn't ever try again.

Backup on Monday night at 11PM, completes at 11:30PM, retention period is 6 days. DLM will groom the backup catalogs and BKF files after Sunday at 11:30PM, within 4 hours. If the disk is online then everything is removed, catalog, BKF, IMG. However at the client in question, the disks are disconnected and a different day (Tue-Fri) is connected. So Sunday night the "Monday" disk is not online. At 11:30PM or within 4 hours DLM removes the catalogs, attempts to remove the BKF and fails.

Monday morning the "Monday" disk is connected and reports XX of YY full. Backup Exec shows no catalogged information. If there isn't enough disk space to run the Monday backup it just fails, it doesn't even attempt to overwrite the files because the files are outside the system, orphaned and unknown.

So to work around it I wrote that script, which runs prior to the backup. I use a retention period minus one day and delete files older than that. Basically, the script does what DLM should and hunts down orphaned files. Obviously not perfect but I'd rather have orphaned catalogs than orphaned BKF files that prevent the next backup from running at all. 

Colin Weaver's picture

Just for info Clark L is describing the known DLM issue reported against disconnecting USB disks (caused by a DLM fault) and his script might work although obviously Symantec won't have tested it.

He is not describing the effects of the RDX issue which is still controlled by media sets and not DLM so is a different problem. Also the RDX issue will be a problem even if the cartridge remains online on the media server. The USB/DLM issue wil not be seen if the USB disk is never disconnected.

Also it if anyone is using RDX and seeing that BKF files are not being overwritten then we do need you to log a support case as this is not a known issue   (only the IMG folders on RDX not overwriting is the known issue)

EDIT:

TECH Article for disconnected USB/DLM issue = http://www.symantec.com/docs/TECH196201

TECH Article for RDX/IMG issue = http://www.symantec.com/docs/TECH192382

Bulbous's picture

Ok so, for clarity, this issue (IMG folders not erased from RDX) is a completely seperate issue that has nothing to do with (and does not involve) DLM?

Colin Weaver's picture

Yes (well almost) the cause for the defect of why the RDX IMG folders are not reclaimed is because of the changes for DLM but that is an unintended relationship as RDX still uses media sets and one critical link between media sets and the IMG folders was accidentally affected by the DLM changes.

RDX backup sets whether BKF or IMG are still handled by media sets with the only 2012 difference being you cannot append into a BKF (you could not append into an IMG in 2010 anyway)

Standard disk storage (incuding USB) media sets are handled by DLM, with RDX set to also be handled by DLM in the next full version of Backup Exec.

Bulbous's picture

FYI, this was working but now IMG folders are accumulating again. I wonder if a new hotfix broke this?

Colin Weaver's picture

1) If you don't have the orphan then you will almost certainly see this issue it has not been fixed by public hotfix yet,.

2) If you do have the orphan but have installed a Hotfix since  then the orphan has probably been overwritten. As the support case used to receive the orphan should still be open, please contact the technician working your open case and confirm if you need a newer version of the orphan because of your new hotfix levels.

Note we do deliberately give orphans lower file version numbers thabn hotfixes so that they should be overwritten. Also if you know you have an orphan you should be confirming via the support case for the orphan whether or not new hotfxies can be applied before you install them.

Bulbous's picture

Thanks, Colin.

I did have the Orphan and it did fix my problems. Then it stopped working, presumably overwritten by public Hotfix.

I replied to my case (02960920) and my tech gave me a new Orphan (26.11), which I applied, but my problem persists. IMG folders are no longer being reclaimed. Any chance this Orphan needs tweaking again?

Justin

Colin Weaver's picture

You may need to run the SQL comamnd again and you also need the registry change, both documenetd in the Orphan notes - howveer you should be discussing this with the TECH that issued the orphan - he/she will at least need to know that you still have a problem as they may currently belive all is working.

Bulbous's picture

Thanks. I have run the SQL command again and cranked up the AutoExpireGRT registry value to a very high amount - enough to blow away all my IMG folders on all media - still no luck.

I am working with my tech on this, but have posted in case others have the same issue - which points in a different direction!