Exchange 2010 NMM backup fails sometimes

Hi Bruno,

Are you actually retaining snapshots? Could you please let me know what is your snapshot policy? This could be the reason for the failure (despite the error message complains about the command usage).

On the other hand, can you please develop more regarding "sometimes"? In what situations the backup fails? Is it maybe different groups or client instance that fails? Different schedule?

Thank you,

Carlos

I found this in event viewer of the Exchange 2010 server:

RM_ESM_2010: Executing get-MailboxServer  -Identity "WMAIL2" Properties = DatabaseAvailabilityGroup

It occurs at the beginning of the backup

Could it be an explanation ?

Hi Carlos,

We don't retain snapshots.

By "sometimes" , i mean that the same backup , same client, same schedule most of the time ends successfiully but not on some days. I can't see if an event occurred previous day of the backup which could have some influence on the backup.
Could it be related to a wrong interpretation of NMM regarding DAG ?
Actually, we don't use DAG nor configured it.

Carlos,

I think i was wrong when i said that we didn't keep snapshots.

Here are the application informations for the exchange client

NSR_SNAP_TYPE=vss

NSR_EXCH_RETAIN_SNAPSHOTS=yes   --> I think that it means that we do retain snapshots

NSR_ALT_PATH=d:\temp

NSR_EXCH_CHECK=yes

NSR_ESE_UTIL_SEQUENTIAL=False

NSR_ESE_UTIL_THROTTLE=False

NSR_CHECK_JET_ERRORS=all

Hi Bruno,

Actually is the other way around

I was asking if you really need to retain snapshots, meaning that you have snapshots being rolled-over to backup device, and other persistent snapshots, staying locally on the storage for faster restore (these are not being saved to backup device).

If you are NOT retaining snapshots, please remove that variable from the application information.

Also, can you please share the information about the snapshot policy you have configured for that group?

Can you check as well if there is any orphaned or left behind snapshots, by running vssadmin list shadows?

If no persistent snapshots (retained snapshots), there shouldn't be any snapshot left behind, so please check and delete those snapshots if possible.

Thank you,

Carlos

Hi Bruno,

execute the config check and loaded the issue.

Regards

Hi Bruno,

Yes, please set the variable to false, as the serverless backup should take only one snapshot and roll it over to backup device.

So did you run any backup today around 7:00, when the snapshot was created? If not, is there any other third party application taking those snapshots? Is this a physical or virtual machine?

If Shadow Copy is enabled, please go ahead and disable it, as that will lead to backup failures

If that snapshot is no longer needed, please delete that snapshot, to make sure we don't leave behind any other snapshot.

Thank you,

Carlos

Hi Elvin

The config checker did not show any problem.

Actually, i have additional info: I discovered that failure occurred every friday and successful end of group occurred any other day in the nwk schedule.
For the moment, i'm checking if any scheduled task or special event could interact whith the group these days.
I'll post reply asap.

Thx

Hi Carlos,

As i replied to Elvin, i'm wondering why our problem only occurs on fridays and never the other days?

For the moment , i don't have any certainty for this .

Here is the snapshot list:

>vssadmin list shadows
vssadmin 1.1 - Outil ligne de commande d'administration du servicede cliché instantané de volume
(C) Copyright 2001-2005 Microsoft Corp.

Contenu du jeu de clichés instantanés n° : {10d3b35c-adc3-4522-8335-857bcb957cfe}
   Contenait 1 clichés instantanés à la date de création : 15/06/2015 07:00:02
      ID du cliché instantané : {7bcbe819-3682-4499-95e4-d2a631aad67b}
         Volume original : (C:)\\?\Volume{d679845b-b0a2-11e1-9d0b-806e6f6e6963}\
         Volume de cliché instantané : \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
         Ordinateur d'origine : wmail2.CG10.LOCAL
         Ordinateur de service : wmail2.CG10.LOCAL
         Fournisseur : 'Microsoft Software Shadow Copy provider 1.0'
         Type : ClientAccessible
         Attributs : Persistent, Accessible par client, Pas de libération automatique, Aucun rédacteur, Différentielle

It's a volume snapshot , taken each day in differential mode, at 7H00 , on C:\ volume:
nothing to do whith powersnap snapshots taken at 4H00 at the group strating.

So, i think i'll delete NSR_EXCH_RETAIN_SNAPSHOTS=yes  or set it to False (right ?).
Regarding the snapshot policy for the group , here are the parameters:

Snapshot: yes

Policy: Serverless Backup

Pool: My pool (advfile device on F:\ local disk)

Hello Bruno,

I'm afraid there is an overlapping of the backup and the snapshot you have configured for C:\

Please note that only one VSS operation at a time is allowed, so you will have to check the schedule of the backup so it doesn't overlap, however my recommendation is to disable snapshot on C:\

Thank you,

Carlos

Hello Carlos,

I've made some updates.

Firstable, move backup of two folders from nsr snap group to normal nsr group .

Only keep APPLICATIONS:\MicrosoftExchange 2010 in snap type group.

Midified NSR_EXCH_RETAIN_SNAPSHOTS=no (in place of False which is not authorized)

Delete C:\ snapshot .

Normally, i shouln't have any problem .

I'll wait till friday to see if error persists or not.

I'll do an update at that moment.

Again , thanks for your help.

Hi Carlos,

Yes , i HAD 2 client  folders backed up within the the same group.
Now, i've separated these savesets in 2 different non-overlapping groups.
Further, by removing pool specification in the client configuration and adding it in the group configuration , the backups seem to be successful.

I'll wait till friday to confirm that this case is solved.

Thanks

Hola Carlos,

I would like to confirm that the problem is solved.

Steps folloed :

- separating filesystem and exchange backups in two non overlapping vss groups.

- Deleting mention of snapshot pool at client level

- Adding snapshot pool at group level (by editing the pool).

- adding *@* in the remote access field of the client

All works fine.

Thanks again Carlos

See you.