Data Backup and Recovery

SnapProtect: Problem with backup copy (tape copy) ERROR: BAD ENV OP

dankirkwood
5,177 Views
Hi Everyone,
 
Before I log a support call I wanted to ask if anyone has had experience with this issue.
 
I have a Storage Policy with the following copies configured:
  1. Primary (Snap) Copy
  2. SnapVault to another SVM on the same cluster
  3. SnapMirror to an SVM on a different cluster
  4. Tape (Backup) Copy
On some NAS volumes/subclients, I get an error when trying to run the backup (tape) copy:
 
NDMP Server reported the following error: [DATA: Operation terminated: backup configuration failure (2) on RPC error: ERROR: BAD ENV OP (for /ncww_v07_backup/CC_nspprod01_SP_22_Copy_86_ncba_v04_cifs_ncba_v04_vol_s_drive02_Mirror/.snapshot/snapmirrorSE.66c81f94-5].
 
In the NasBackup.log I see the full name of the snapshot that the backup copy job is trying to access:
 
ENV [FILESYSTEM]=[/ncww_v07_backup/CC_nspprod01_SP_22_Copy_86_ncba_v04_cifs_ncba_v04_vol_s_drive02_Mirror/.snapshot/snapmirrorSE.66c81f94-519f-46c3-b39f-39d586be02c8.SP_2_1399_991_1414827022]
 
The trouble is, that snapshot doesn’t actually exist on the SnapMirror destination volume:
 
ncww::> vol snap show -vserver ncww_v07_backup -volume CC_nspprod01_SP_22_Copy_86_ncba_v04_cifs_ncba_v04_vol_s_drive02_Mirror -snapshot snapmirrorSE.66*
  (volume snapshot show)
There are no entries matching your query.
 
 
For the other subclients/volumes where tape backups *do* work , the Snapshot names in NasBackup.log are generally something like “SP_2_xxxx”. For the ones that fail, SnapProtect seems to be looking for non-existant snapshots with a longer name, prefixed by "snapmirrorSE.xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.”.
 
The environment is SnapProtect 10 SP6 with Clustered ONTAP 8.2.1P1. I’m using Cluster-Aware-Backup with node-scope NDMP disabled on the clusters and SVM tunnelling configured in SnapProtect.
 
I have tried re-running the previous SnapVault/SnapMirror Aux copies in the storage policy, but they say there is no data to be copied.
 
The volumes affected have multiple qtrees, and I have found mentions of a bug/limitation titled "A SnapMirror tape backup from a SnapVault auxiliary copy fails if the volume has multiple qtrees” - but this bug was supposed to be fixed in SP6.
 
Any help or suggestions would be appreciated.
 
(Also cross-posting to xdl-snapprotect@netapp)
 
Regards
 
Daniel Kirkwood
2 REPLIES 2

dankirkwood
5,138 Views

So from xdl-snapprotect I've been told that a Primary -> SnapVault -> SnapMirror cascade is not supported currently for SnapProtect and cDOT, and that this is the source of my problem.

 

It might be supported in a future version of OCUM 6.x, but until then I will need to switch to Primary > SM > SV if I want an SM/SV cascade.

dave_cahill
4,736 Views

Hi Dan, 

 

did you see any update on this in OCUM 6.2? Have the same problem on 8.3 using OCUM 6.2 where the mirror is renaming the snapshot on the source and destination to snapmirrorSExxxxx and when you try and do a restore from mirror SnapProtect is saying the snapshot does not exist because it is looking for SP_X_XXXX_XXXXXXX.

 

Have a support case open with NetApp and they are saying there is no issues with Primary -> SnapVault -> SnapMirror cascades but saw this in communities and thought you might have seen an update.

 

Thanks for your help

Public