2010-04-06 01:34 PM
I would like to SnapVault a Volume that is assigned to vFilerA to a destination volume on another vFilerB.
So I opened DFM, went to the "Backup"-tab and chosed vFilerA as "Primary Storage System" from the dropdown, entered the volume path, selected vFilerB from the "Secondary Storage System" dropdown list and finally selected the destionation volume.
But when confirming the addition of the backup I get:
"Error: The primary directory 'vfilerA:/vol/dxb_001_cluster1_sql_db/db' does not appear to be a valid backup source: NDMP communication error: bub_dir_list: 0x20500103 (SNAP INVALID PATH ERR)"
I found a KB-article saying, that wrong credentials cause this error.
But when diagnosing the connection to the physical storage system, everything is green and ok (credentials used are "root" and its password).
When connecting to the destination storage system that hosts vFilerB, changing the context to vFilerB and then initialize the Snapvault by "snapvault start -S <vFilerA-IP>:/vol/.... vFilerB:/vol/destination...." everything works fine and as expected - except that this relation is not recognized by Operation Manager like other relations between physical storage systems.
So: am I making something wrong or is this just a limitation of Operation Manager, that it can not handle vFilers?
2012-03-16 08:26 AM
Since there was no answer here, this could be a support related question. We have external and internal subject matter experts in the NetApp Support Community answering questions. If you have a NOW login, this link, SnapX Products/Software, enables you to engage them about this.
2015-09-15 04:54 AM
Since this is the only search result when you look for the error "does not appear to be a valid backup source: NDMP communication error: bub_dir_list: 0x20500103 (SNAP INVALID PATH ERR)", here is the solution:
The path you gave does not have the correct syntax. /vol in the path is too much
Instead of using 'vfilerA:/vol/dxb_001_cluster1_sql_db/db' and getting the error message, you should use 'vfilerA:/dxb_001_cluster1_sql_db/db' and everything will be fine.
Just to let off some steam at this point: NetApp could have made this much less confusing!!!