NDMP error 99

Are you using NetBackup Replication Director?

Exact NetBackup version and path level please?

Are you trying to backup a NetApp volume which has a SnapMirror relationship?  If yes, please show the SnapMirror details from both sides.

Hi sdo,

I'm not using Netbckup Replication Director.

My version of Netbackup is 7.5.0.4. What do you mean by "path level" ? The location of the snapshot created ?

Indeed, the NetApp volume has a mirror to another volume. And, before, this was the mirror who was backed up, and everything was fine. But now, we backup the source volume, and the mirror has now the same errors.

Here is what I tested : 

-a full backup of a path and then an incremental of the same path : error 99 during the incremental backup

-a full backup of a directory in this path and then an incremental : ok

The only thing I see is the volumetry : all my directories until about 350G are backed up, and all the directories which falls have more than 777Go.

Sorry I meant "patch level", but you've covered that with v7.5.0.4.

I think your problem is that... this is what you used to do:

source --> snapmirror --> target --> backup         i.e. the backup was always based on the latest snapshot

...now you are doing:

source +-> backup
       |
       +-> snapmirror --> target

My understanding is that NetApp snapmirror is effectively a "pull architecture", i.e. the internal management of snapshots are maintained frrom what we view as the target, but is really the orchestrator.  i.e. NetApp is refusing to let you effectively fork the snapshots of the source.

On the face of it I can't see why you can't do what you want to do, because the snapmirror position appears to be maintained at both sides.  But from the logs, it's not NetBackup complaining, it is the NetApp complaining that it is being asked to do something that it cannot comply with.

I think you're going to have to go to NetApp and see if what you want to do is a supported topology/configuration.

I will see that, but I don't understand why this is OK for many directories (the smallers) and not for the biggers...

In which case, I'm wrong about the above, and an NDMP based snapshot can be taken from either side when an existing snapmirror relationship is in place.

AFAIK, snapmirror relationships can only be established at the volume or LUN layers.   But I'm probably wrong on this too, and maybe they can now be established at the Qtree or folder level.   Either way there's something within the NetApp blocking/rejecting the request... and so... you've guessed it... it's probably time to open a case with NetApp Support?

Well spotted Marianne - I missed that:

Date of last level 0 dump: Tue Jan 19 04:14:07 2038 

The above could be a corrupt date.

...plus an hour for daylight saving :)

That timestamp is Netbackup "infinity". 

Hope to be retired by then; hope my pension checks don't stop.

Will - you've made me have a thought...

...maybe the NDMP level 1 backup of that area is failing because the NetApp has never recorded a level 0 as having occured for some paths - i.e it is as if the client (the NetApp) lives in two policies, and policy A which does a level 0 has less paths in it, than say policy B which does a level 1.   So, when policy B tries to take a level 1 of a path, then the NetApp knows that there has never been a preceding level 0 of that path and so refuses to co-operate.

What else might cause this?   A level 0 from so long ago and/or very infrequent runs of level 0 followed the 'appearance/creation' of new Qtrees/shares/folders/files, and then an attempt of a level 1 of these new structures?  Maybe such a sceanrio makes the backups barf too.