Backup Exec B2D size limitations?

No limitation from BE...B2D size limitation depends on the OS's file system

It sounds more like you don't have your overwrite settings set to expire in a way that will allow you to recycle or reuse B2D Files.  How long do you need to retain these backups?  I would look at the media set settings and change them accordingy.

What are the OSes involved?

If you create a new media set with no Overwrite Protection, can you run a small B2D job to either B2D device?

Thanks for the responses. 

Both servers are 32-bit Windows 2003 Standard w/SP2.  I use the Lotus Domino agent, but no other agents and all files are local to the server running BE (no remote devices getting backed up).

All my media is set with no Overwrite Protection.  I run daily incremental backups and a weekly backup in a 4 week rotation.  Since I replaced the backup drives, I created all new B2D folders, so overwrites shouldn't be an issue, since there is no existing media being overwritten.

On the server running 8.6, the old 2TB drive is still plugged in (drive letter K:).  The new 3TB drive is drive F.  I created a new B2D folder called "test2" at K:\test2 and ran a backup of five 1K files.  Everything went as expected - the job finished in 16 seconds.  I then created a new B2D folder called "test3" at f:\test3 and attempted to back up the same five files and the job stayed in "Queued" status for 5 hours, until I cancelled it.  After cancelling the "test3" job, I ran another backup to the "test2" location and it completed in 3 seconds, overwriting the previous media.

So, it appears that the only difference between these 2 jobs is the size of the drive that contains the B2D folders.

I have not ran these same types of tests on the server running 11D, as this server has been offline all day, due to some electrical maintenance being done at that facility.  I will run the same types of tests when that server becomes avaialble.

One more thing I should mention about the backup drives on the 8.6 server.  The old drive is set to be an MBR disk and the file system is set to exFAT.  By default, the new drive had these same settings.  In an effort to try to fix the issue earlier in the week, I converted the new drive to a GPT disk and formatted the new volume with NTFS.  I'm not sure this makes any difference to BE, since I've seen the same symptoms before and after the changes to the disk.

Right after I posted, I got word that the 11D facility was back up and running.  I ran the same tests (although, since the old drive is dead, I used the same drive that contains the data - drive E:), with the same results.  "Test2" completed in 8 seconds.  "Test3" almost immediately went into "Queued" status.  I waited 10 minutes and ran the "test2" job again and it completed in 19 seconds, overwriting the previous data.  Meanwhile, "test3" was still queued.  As I post this, it's been queued for 22 minutes.

Edit: I should mention that I did not change anything with the drive settings on this server.

Are your new 3TB disks configured as a single 3TB partition?  If so, then your disks is probably using GPT, instead of MBR.  Since your BE versions are so old, it could be that they do not support GPT disks.

You can try partitioning the 3TB disks into two partitions with none of the partitions using more than 2TB and formatting them with MBR rather than GPT.

I tried changing the disk to MBR and created a 1TB partion.  Same result - job is just stuck at "Queued."

Yeah, I figured running these old versions would come back to bite us at some point.  We are planning to move to Windows 2008 R2 on all of these servers in the next 6 - 9 months, at which point I know we need to upgrade anyway.  I guess these 2 machines are going to get the upgrade now (downloading it as I type this).

Thanks to all for your help and suggestions.

You can upgrade your BE 11d directly to BE 2010 R3 which is the current version.  I am not sure about the upgrade path from BE 8.6, but it is definitely a 2-stage upgrade.  If you want to start afresh, then there would be no problems.