cancel
Showing results for 
Search instead for 
Did you mean: 

RDX cartridge woes. IMG folders overflow.

Hendrik_Klinge
Level 2
Partner

Hi everyone.

I've been having a lot of trouble with an RDX disk cartridge drive.

 

Background

Backup Exec verison is 15FP3. Windows version is 2012R2.

We have 5 RDX disk cartridges. One for every work day. So that's Monday, Tuesday, Wednesday, Thursday, Friday.

Raw space on these is 1000GB. A backup job has about 800GB. (I'm simplifying the numbers here.)

So the problem we've run into is this: The first backup job to a disk will work fine. But then the next week BE will fail with "V-79-57344-33935 - Insufficient disk space." after having written 200GB.

The problem is that BE forgets that it itself has filled up that cartridge. Then it believes that someone else must own that 800GB used disk space and doesn't touch it or delete it.

 

Workaround 1: Catalog:

If you manually run a CATALOG job on a cartridge before a job, then you can watch in real time how the "Backup Sets" view of that particular RDX cartridge fills up. You can watch as it BE discovers the IMG folder's contents line by line. This will take about 30 seconds for a cartridge. And afterwards you can watch BE expire and delete the old backup sets.

And, yes, you have to do this EACH DAY. 

 

Workaround 2: Format the disk.

Takes about the same time as re-cataloging.

But again: you have to do this EACH DAY.

 

Workaround 3: Run pre-backup script.

User "ClarkL" wrote a small Batch script that deletes the old IMG-folders. He posted it in a 2012 thread: https://www.veritas.com/community/forums/why-are-img0000xx-folders-not-erased-rdx-cartridge-b2d-cycle

I have not tried this yet.

 

 

(FWIW: I have opened up a tech support case (Case Number 21102882) but I feel it's going nowhere.)

Has anybody else run into this problem?

Cheers, Hendrik

1 ACCEPTED SOLUTION

Accepted Solutions

pkh
Moderator
Moderator
   VIP    Certified

RDX disks are managed by DLM and you should read these documents on how DLM works.

http://www.veritas.com/docs/000076201

http://www.veritas.com/docs/000068230

You might also want to read my article blow

https://www.veritas.com/community/articles/when-backup-sets-are-deleted-under-dlm

Note that DLM does not overwrite existing backup sets.  These backup sets must be expired by DLM to free up space on the disk.  The DLM grooming process should start when the RDX disk is online.  Did you do an inventory after putting in the RDX disk into the drive?  A catalog is probably not necessary.

Do not manually delete the backup sets on disk either by formatting the disk or by script.  This will leave orphaned entries in the BE console.

View solution in original post

3 REPLIES 3

pkh
Moderator
Moderator
   VIP    Certified

RDX disks are managed by DLM and you should read these documents on how DLM works.

http://www.veritas.com/docs/000076201

http://www.veritas.com/docs/000068230

You might also want to read my article blow

https://www.veritas.com/community/articles/when-backup-sets-are-deleted-under-dlm

Note that DLM does not overwrite existing backup sets.  These backup sets must be expired by DLM to free up space on the disk.  The DLM grooming process should start when the RDX disk is online.  Did you do an inventory after putting in the RDX disk into the drive?  A catalog is probably not necessary.

Do not manually delete the backup sets on disk either by formatting the disk or by script.  This will leave orphaned entries in the BE console.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

As well as pkh info you should read this blog:

https://www.veritas.com/community/blogs/backup-set-retention-and-expiry-handling-removable-rdx-etc-media

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Since BE 2012 we have adjusted DLM behviour (including how it operates on RDX) which might mean workarounds (including scripts) form BE 2012 no longer apply.

 

Looking at your actual problem have yoy crted one job defintion oper day or one definition that repeats daily. If you have done one defintition per day then you have created a daily last recovery chain meaning the existing sets on a daily disk cannot be reclaimed until a new set for the same day exists (this problem is mentioned in the the blog I posted earlier)