Video Screencast Help

Incremental Hot Catalog Backup after Vault Catalog backup not working

Created: 15 Nov 2012 | 10 comments

Hi all,

I'm having the following issue on my netbackup 7.1 configuration.

I run every morning a vault catalog backup. The schedule used is producing 2 (supposed full) copies of our catalog. One copie is going off-site, the other one  is kept on site.

Then, I want to run an incremental (cumulative) catalog backup, but it doesn't work : size of the INC equals size of the full (vault).

Looking at the files produced, my vault backup appears with extension UBAK (user backup and not FULL as I expected).

It doesn't seem that my INC is taking into account the vault backup, ans is doing a kind of full...

Is that normal?

Is it possible to produce a Full Catalog through vault and then Incremental (diff or cumul) through the same policy but different schedule?

 

 

 

 

Discussion Filed Under:

Comments 10 CommentsJump to latest comment

Marianne's picture

Seems all of us missed this post back in November...

INC backups only work when they are in the same policy as the FULL.

It is normal to see INC schedule backing up all data when no FULL schedule has run in the same policy.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

watsons's picture

Always when having this scenario, I would check if the cumulative schedule you set is actually CINC, or had been changed.

If it's indeed CINC, I would enable verbose nbpem logs to have a further look to see why the schedule picks up another FULL, could it be due to the archive bit or timestamp checking.

Btw, was the first FULL catalog backup completed with status 0 or status 1?

muppetshow's picture

Hi Marianne,

Thank you for up(ping) my post!

All scheduled used for my catalog backup are in same policy.

But it seems that schedule with vault type is not considered as full?

Is that normal?

Marianne's picture

To be honest, I have very limited vault knowledge/experience.

I have just gone through all the recommendations for Vault Catalog backup and steps to create the Vault Catalog schedule.

The schedule type is 'Vault Catalog Backup'. This says to me that the 'normal' onsite copy would still need a Full schedule as reference point for Incrementals.

I have unfortunately no facilities to test this.
Hopefully our Connect experts using Vault in their environments will share their experience...

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

watsons's picture

Checking my vault config, the schedule I selected for my vault-driven policy is "Vault Catalog Backup". Unlike a normal schedule, I don't find something like "Vault Catalog Full" or "Vault Catalog Differential" , I look into the admin guide and it does not show those as well.

I guess the only schedule valid for Vault is the "Vault Catalog Backup" which is a full. How did you actually select the schedule to be "Full" or "Incr" schedule?

RLeon's picture

It goes something like this...

The duplication feature in Vault profiles - if you choose to use it - does not duplicate catalog images, even when they should be included for duplication according to your image selection criteria in the first tab.

To see why that is the case, it is important to understand that the primary function of NetBackup Vault is to facilitate ejecting tapes and sending them offsite, amongst other housekeeping and tracking stuff.

If you want each batch of tapes to be sent offsite to also include the catalog images, then you would want the catalog images to also have "knowledge" of these very images that are to be sent offsite together.

Here is an example to show what would happen if the above is not the case:
03:00 - Client1 backed up, Copy1 created.
04:00 - Netbackup Catalog backup
05:00 - Client1's latast backup is duplicated to Copy2.
06:00 - Vault sends the latest Catalog backup and Client1's Copy2 offsite, in the same batch of tapes.

As you can see, the Catalog images in this case would have no knowledge of Client1's Copy2, even though they are sent offsite together in the same batch of tapes.
This will cause headaches if you use this Catalog backup for recovery. You will not see Client1's Copy2 in the Catalog even though you know it's there in the tapes (If you could tell, that is...). So you'd still have to import Client1's Copy2 if you need them.

Because of the above, Vault does not duplicate existing Catalog images. Its solution to the problem is to force its own Catalog backups (which is what you are using already, via the Vault Catalog Backup Schedule). This ensures that the Catalog images going offsite will also have the latest information of the other images they are going offsite together with. Making them more consistent - and therefore useful - for disaster recoveries.
Using the previous example, the Vault-created Catalog backup will have "knowledge" of Client1's Copy2 that it is going offsite together with.

(Note: Even though using Vault to send non-Vault-created Catalog images offsite is supported, it will still cause the above problem, and is therefore not a very useful feature.)

 

Having gone through the above, it is not difficult to see why the the Vault Catalog Backup schedule will always create Full, and why existing Incrementals will not reference this Full.
The Vault-created Catalog backup should be self contained and relevant to the batch of tapes it is sent offsite together with.
To see why that is, you could try to work out the the problems you'd see during Catalog restore in the following scenarios:
1. An onsite Catalog Incremental references an offsite Catalog Full. Disaster strikes and you need to restore the Catalog using that Incremental, because it is the latest Catalog backup.
2. An offsite Catalog Incremental references a Catalog Full that was sent offsite in a previous Vault job.
3. An offsite Catalog Incremental references an onsite Catalog Full. The "site" is demolished due to disaster, and you are to restore the Catalog using the offsite tapes.

RLeon's picture

I see you are relying on the Vault-created Catalog backup as your Full for both onsite and offsite copies, and is trying to add an Incremental schedule to reference it.

The correct and typical setup for the Catalog policy schedules should instead be:

Full Schedule - Points to an onsite-only Catalog media pool.

Incremental Schedule - Points the same onsite-only Catalog media pool.

Vault Catalog Backup Schedule - This is also a Full, but points to a different Catalog media pool that is for offsite use; this schedule is to be triggered by Vault.

muppetshow's picture

Hi,

So it seems that I have no other solution than dissociate my catalog backups (onsite and Vault).

Knowing that, my issue is how can I reduce time to produce these 2 catalogs backups. Each of them takes about 6 hours (for about 300 Go) => 12 hours each days used for these tasks. Time during which I cannot do any maintenance tasks.

Is there a way to get better performances?

My catalog is on a Aix 5.3 master server.

 

 

Mark_Solutions's picture

The Vault Schedule window shows as Red in the Admin Console - that indicates an Application backup so will not be valid (i think this has pretty much been covered now!)

So you need two copies of your catalog .. perhaps just use inline copy ..on the schedule tab select multiple copies and set it to the same STU but your different volume pools

Alternatively use a Storage Lifecycle policy that does the backup to the first tape and then duplicates that to the second tape

Hope this helps

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

RLeon's picture

For large catalogs, this is always problematic.

Using inline copy to create two catalog copies at the same time (one to an onsite pool, and another to an offsite pool) will still have the inconsistency problem described in my previous example - the catalog not knowing about some of the images it is going offsite together with.

The only way around this problem is to either:
1. Use the Vault created catalog backup
2. Make sure that no other jobs that writes to your other offsite pools (backups or duplications) run AFTER your inline catalog backup job, then send catalog-copy2 offsite with the other offsite tapes. This ensures that the catalog going offsite would have the most up-to-date knowledge of the other images it is going offsite together with.

Essentially, options 1. and 2. have the same effect.

 

If a little inconsistency is acceptable, then the inline copy method could be a good solution for keeping the backup time around 6 hours and also giving you 2 catalog copies. (2nd one for going offsite)
Note that inline copy will add some overhead and it will probably take more than 6 hours, but should be less than 12.

 

You may also want to consider Catalog Compression and/or Catalog Archiving to keep the catalog size under control, in order to shorten the time it takes to complete both normal and Vault catalog backups.
You will find details on these features in the Nbu admin guide vol1.
Personally, I do not recommend them; they come with their own share of problems...