We have a volume that contains data served via NFSv3 to a production system. From time to time, we'd like to use SnapDrive for Unix (SDU) to create a snapshot of that volume and mount the data on a test system. The test system should not have access to the production volume, for obvious reasons.
I have been able to create the snapshot and mount it in a different place on the production server, no problem.
# snapdrive snap create -fs /data/prod -snapname refresh_20171230_0040
Starting snap create /data/prod
WARNING: DO NOT CONTROL-C!
If snap create is interrupted, incomplete snapdrive
generated data may remain on the filer volume(s)
which may interfere with other snap operations.
Successfully created snapshot refresh_20171230_0040 on corp-dc-8040-nfs:/vol/vol_data
snapshot refresh_20171230_0040 contains:
file system: /data/prod
filer directory: corp-dc-8040-nfs:/vol/vol_data/data_prod
# snapdrive snap connect \
-fs /data/prod /data/stgtst \
-noreserve -clone unrestricted -verbose \
-snapname corp-dc-8040-nfs:/vol/vol_data:refresh_20171230_0040
connecting /data/stgtst
to filer directory: corp-dc-8040-nfs:/vol/vol_data_0/data_prod
Volume copy corp-dc-8040-nfs:/vol/vol_data_0 ... created
(original: vol_data)
Successfully connected to snapshot corp-dc-8040-nfs:/vol/vol_data:step8img_stg_20171230_0040
file system: /data/stgtst
filer directory: corp-dc-8040-nfs:/vol/vol_data_0/data_prod
0001-860 Info: Host interface 172.16.194.56 can see storage system corp-dc-8040-nfs,
but has read-only NFS permission to directory /vol/vol_stepimages/stepimages_prod.
If this is intentional (examples: your routing setup will only use allowed
interfaces; the directories are mounted with the read-only option; etc.), you
may safely ignore this warning.
Otherwise, we suggest verifying NFS permissions on the storage system to avoid any
potential I/O errors.
This last bit appears to be a warning, because when the command completes, the snapshot is mounted on /data/stgtst and I can successfully create, modify, and delete files & directories in that share. So far, so good.
However, when I try to run the same command on the test system, which is not included in the export policy for the production volume, it fails as follows:
# snapdrive snap connect \
-fs /data/prod /data/stgtst \
-noreserve -clone unrestricted -verbose \
-snapname corp-dc-8040-nfs:/vol/vol_data:refresh_20171230_0040
connecting /data/stgtst
to filer directory: corp-dc-8040-nfs:/vol/vol_data_0/data_prod
Volume copy corp-dc-8040-nfs:/vol/vol_data_0 ... created
(original: vol_data)
Cleaning up ...
destroying empty snapdrive-generated flexclone corp-dc-8040-nfs:/vol/vol_data_0 ... done
0001-860 Info: Host interface 172.20.36.30 can see storage system corp-dc-8040-nfs,
but has read-only NFS permission to directory /vol/vol_data/data_prod.
If this is intentional (examples: your routing setup will only use allowed
interfaces; the directories are mounted with the read-only option; etc.), you
may safely ignore this warning.
Otherwise, we suggest verifying NFS permissions on the storage system to avoid any
potential I/O errors.
0001-034 Command error: mount failed: mount.nfs: access denied by server while mounting corp-dc-8040-nfs:/vol_data_0/data_prodSo the mount fails due to the test server not being included in the export policy of the production volume.
Is there a way using SDU to complete the mount on the test server by using a different export policy? What is the best practice for this type of operation?
Thanks,
Bill
