Every scheduled incr backup of Exchange is promoted to full

The first thing I would try to clarify here is: who is the culprit promoting incremental backup to full.

Is it NW Server or client?

First have a look at NW Server daemon.raw and /nsr/tmp/sg/.../ files to find out about any information pointing to "can't find a full, performing full backup".

In this case the NW Server is struggeling with the client and its saveset cycles and you should be able to confirm this at the NW client side in nmm.raw seeing the action requested was a full backup instead of incremental.

Or you find nothing like this at NW server then have a close look at nmm.raw file finding the backup task requested.

If this shows up a level incremental but NW client doing a full then it must be something at the client side causing the promotion to full.

Hi,

I suppose the host name and IP of the 3 new servers didn't change at all?

Could you please attach the nmm.raw file so that I can take a look?

Thank you,

Carlos

Would it be possible to share the client configuration on these machines. I would suggest you to check for multiple clientid, did you by any change provide same aliases for multiple machines. Can you provide us the exact error message you are getting or even better share the nmm.raw.

The host names and IP are new, since we migrated to the new servers when the old servers were still live. There was no point really changing the hostnames, since the clients connect to the virtual name of the DAG, and this remained unchanged.

I fully expect the first backup to be full when the hostname was changed, but not every single one after.

I never changed the hostname of any host. Three new hosts were introduced in parallel to the existing three hosts, making the DAG a six member DAG. The Exchange people then migrated the databases to the new hosts and the old hosts were decommissioned.

Hi,

Would be interesting to check in the nmm.raw file what is the complete backup command...check -l xxx if it says full then there is something wrong in the configuration, as the command being passed to nsrsnap_vss_save is level full.

Double check schedules for the client/group.

Thank you,

Carlos

Hold on, you are saying you changed the name of the physical hosts? aren't you getting some messages such as "failued to create dummy saveset for host_XXX"?

Thank you,

Carlos

The client IDs are unique between the three servers, as well as the virtual entry for the DAG name.

The application information for all three servers, I've just change the hostname to a generic name:

NSR_SNAP_TYPE=vss

NSR_EXCH2010_BACKUP=active

NSR_EXCH2010_DAG=dag.ad.local.intra

NSR_ALT_PATH=D:\mnt

Backup command:

nsrsnap_vss_save.exe -D5

I added -D5 on the recommendation from support, but so far no clues. I'll see what I can do about the nmm.raw file.

There is no error message. Nothing to indicate a problem. Some of the first entries in nmm.raw, a few seconds after the scheduled backup starts:

info nsrsnap_vss_save: Backup is level FULL. Set GLR compatibility to YES.

info NMM .. Valid snapshot policy. Group: "Exchange_2010" Snapshot Policy: "Serverless Backup" Snapshots Per Day: "1"  Retain: "0" Backup Snapshots: "All" Level: "full".

Can you start the save group from the command line and provide us the output. We are trying to find out where exactly is the level escalated to a full ? no trace of it in the nmm.raw.

Hello Carlos,

The nmm.raw file doesn't show the backup command issued with it's complete options and parameters.

I would like to address this "fault" to you for this is a really annoying thing in usual analysis process.

From this missing information we cannot tell for sure whetehr NW server or client did the change to full.

Only from the line

NMM .. Valid snapshot policy. Group: "Exchange_2010" Snapshot Policy: "Serverless Backup" Snapshots Per Day: "1"  Retain: "0" Backup Snapshots: "All" Level: "full".

found by cmorrall already we can assume the NW server already did the change.

It remains analysis on NW server regarding CFI and client-id mismatch.

Attached is the output from my last attempt at forcing an incremental with savegrp -vvv -l incr Exchange_2010. I've replaced the domain name with a generic name, that's all.

cmorral,

Can you please check the group configuration, in the tab "Advanced", what you have in the "Schedule" and in the "level" fields?

Once you check the schedule (if any) please check the configuration oft hat schedule.

Also please check in the client configuration, the option "Schedule" and please define either the level or the schedule in group or client and leave the other empty, as well as the level.

Thank you,

Carlos

Hello guenterH,

I think you are mistaken, nmm.raw will ALWAYS show the command line and the flags, please see below an example:

Command line:\n  E:\Program Files\EMC NetWorker\nsr\bin\nsrsnap_vss_save.exe -A optype=conventional -A NSR_SAVE_FROM_SAVEGRP_NSRSNAP=Yes -A NSR_SNAP_TYPE=vss -A CIRCULAR_PROMOTION_POLICY=Promote -A NSR_ALT_PATH=E:\snap_mount -A NSR_EXCH2010_BACKUP=all -A NSR_EXCH2010_DAG=exch2013dag.carlos.local -A NSR_EXCH_CHECK=no -A NSR_PARENT_JOBID=1248007 -c vm-avm-28-201.carlos.local -g Exchange -LL -m vm-avm-28-201.carlos.local -s vm-avm28-206.carlos.local -l full -q -W 78 -A snap_sessionid=1383210088 -A NSR_SAVE_FROM_SAVEGRP_NSRSNA

So i'm not sure where your statement comes from.

Having clarified this, the reason why I'm asking for that is to determine whether the issue is coming from savegrp itself, passing the wrong information to nsrsnap_vss_sae.exe or if its nsrindex/MDB not being able to check the CFI or MDB entries for that client.

Thank you,

Carlos