Hot Catalog Backup suddenly needs 2 tapes instead of 1

[Jaap_Hartog]

Hi all,

since 2 days, my Hot Catalog Backup needs 2 tapes instead of the usual 1.

We normally use tapes form a CatalogBackup-pool, 1 tape per day.

Since 2 days the first tape (from the CatalogBackup-pool)  is used to only store one file (D:/Veritas/NetBackupDB/staging/vxdbms.conf)  after which a tape from the scratch pool is mounted and filled with Catalog-data.

This last tape is in fact meant for general use and not for Catalog-backup-purposes.

Has anyone got an idea what may be the cause of this phenomenon ?

We run Veritas Netbackup 6.5.2.a for Windows. 

Kind regards,

Jaap Hartog

Message Edited by Jaap Hartog on 01-29-2009 02:40 AM

[maschino]

 I've a similar problem and when i do a cold backup, the problem was resolved. You can try to compress the catalog, with netbackup tools

[Jaap_Hartog]

Maschino, any suggestions for how to compress ?

I have looked into the matter in more detail.

The job is split into 4 subjobs

1. Starting several processes
2. Starting staging
3. Mounting the catalog tape for writing D:/Veritas/NetBackupDB/staging/vxdbms.conf
4. Mounting the same catalog tape for writing the Catalog data on it.

Instead of correctly performing subjob 4, another tape is mounted from scratch.
Probably, it takes too long for the CAT-media to become available, so a tape from the scratch-pool is mounted instead one from the CatalogBackup-pool..

I now took out the only scratch tape from the library, trying to force the backup to continue on the cat-tape as mentioned under 3. during 4.

After step 3. it waits for the media to become available and mounts the correct tape :

1/29/2009 1:59:36 PM - requesting resource hgol1fmc-hcart3-robot-tld-1
1/29/2009 1:59:36 PM - requesting resource hgol1fmb.NBU_CLIENT.MAXJOBS.hgol1fmb
1/29/2009 1:59:36 PM - requesting resource hgol1fmb.NBU_POLICY.MAXJOBS.Hot_Catalog
1/29/2009 1:59:37 PM - awaiting resource hgol1fmc-hcart3-robot-tld-1
     Reason: Media is in use., Media Server: hgol1fmc,
     Robot Number: 1, Robot Type: TLD, Media ID: N/A, Drive Name: N/A,
     Volume Pool: CatalogBackup, Storage Unit: hgol1fmc-hcart3-robot-tld-1, Drive Scan Host: N/A
1/29/2009 2:00:18 PM - granted resource hgol1fmb.NBU_CLIENT.MAXJOBS.hgol1fmb
1/29/2009 2:00:18 PM - granted resource hgol1fmb.NBU_POLICY.MAXJOBS.Hot_Catalog
1/29/2009 2:00:18 PM - granted resource CATDON
1/29/2009 2:00:18 PM - granted resource IBM.ULTRIUM-TD3.000
1/29/2009 2:00:18 PM - granted resource hgol1fmc-hcart3-robot-tld-1
1/29/2009 2:00:18 PM - estimated 138690192 kbytes needed
1/29/2009 2:00:20 PM - started process bpbrm (6012)
1/29/2009 2:00:22 PM - connecting
1/29/2009 2:00:23 PM - connected; connect time: 00:00:01
1/29/2009 2:00:29 PM - mounting CATDON
1/29/2009 2:01:11 PM - mounted; mount time: 00:00:42
1/29/2009 2:01:12 PM - positioning CATDON to file 3
1/29/2009 2:01:16 PM - positioned CATDON; position time: 00:00:04
1/29/2009 2:01:16 PM - begin writing

This works, but I am still at a loss why a tape from scratch is used instead of waiting for the correct tape from the CalatogBackuppool to become available.

[Andy_Welburn]

---

@Jaap Hartog wrote:

... any suggestions for how to compress ?

 

---

Master Server properties Global Attributes tab: 'Compress catalog interval after nnn days'.

Off by default, so no compression of catalog. If you do decide to use this, a good suggestion is to drop it down in increments until you're at a level that is suitable for your environment. Otherwise, the first time it runs the 'Image Cleanup' it may take some time!

Search for 'compress catalog' in this forum or the knowledge base - there are a lot of good pointers & a few caveats.

NB:

Haven't actually noticed it, but I have a feeling our Catalog may use 2 tapes every now & then - we end up with more than one ACTIVE tape in our CatalogBackup volume pool - so it's either using 2 tapes or will request a new tape instead of appending to the previous days. Will have to check next time to see at what point it does this.

[Jaap_Hartog]

Andy,

in my entry before you I reported that I succeeded in getting the Catalog on 1 tape, so size is not the issue.

But that was only possible by removing all other scratch-pool taes from the library.

Performing  a Hot Catalog backup should ensure the media to be chosen from the CatalogBackup-volumepool, or am I wrong ?

[Andy_Welburn]

I agree. Just thought you wanted to know about compression also.

In most (99%) instances our catalog backups go to one tape (there is no size issue in that we use LTO3 tapes & catalog is ~100Gb) or start on one that's nearly full & complete on another. But, I have a sneaking suspicion that every now & again our catalog backup is doing the same as yours & utilising 2 tapes.

Makes me wonder if there are occasions when one job completes & the next starts but, for whatever reason, NetBackup does not release the tape/drive in time for the next backup to utilise the same tape. The latter then thinks, "Oh well, I'lll just grab another tape from scratch & use that then". With you then removing all your scratch, it can't do that & so thinks "Suppose I'll have to wait until you want to release that tape to me then".  [ Sorry, I've just given my backups there own intelligence & ability to speak ]

[J_H_Is_gone · Accepted solution]

I have not seen this issue, but then I have my catalog policy set up to use a storage unit that only as 1 drive.

[Andy_Welburn]

---

@J.Hinchcliffe wrote:
I have not seen this issue, but then I have my catalog policy set up to use a storage unit that only as 1 drive.

---

Now there's an idea! Thanks Judy, I'll give that a whirl.

Just to confirm this issue did arise again last night & because the limiting resources were available (in my case this limiting factor is available tape drives) the catalog did indeed use a second tape. The backup finished using the first tape (NOT full) but the next part of the backup did not continue to use it, loaded a 'new' tape on another drive whilst the first was being unloaded. Annoying! Obviously the catalog behaves differently to 'normal' backups in this regard - is there a separate timeout that is in effect I wonder?

[Jaap_Hartog]

Thanks Mr. Hinchcliffe, that did the trick !!!