You can use SyncIQ to replicate out of a snapshot, but you can only do it on the command line.

If you do not have a SyncIQ licenses contact your Local Systems Engineer and they can provide you a demo license

Example:  If you wanted to replicate /ifs/data/.snapshot/snapshotname/dir-with-millions-of-files

• On the cli you would use a job like this "isi sync job start --policy-name=name-of-synciq-policy --source-snapshot=source-snapshot-name"Note:
• Note: you do have to have a syncIQ policy setup for the directory in question, you simply are changing the root of the replication for the job to the snapshot.  IE: in the above example you would have a sync job for /ifs/data/dir-millions-of-files

Your local SE can assist you with this, this is a very efficient way to recover large amounts of data from within snapshots.

Cloning with cp -c is very efficient with large files because no data blocks are copied.

In your case it might not help much, in addition of not supporting recusive traversal

(where the latter can be solved by a home-made script of course).

In modern OSes cp -B is default and doesn't need to be worried about.

You can give SyncIQ a try with a "copy" job within the cluster -- use localhost as target host.

If you don't have a SyncIQ license, ask your account team for a temporary license,

ideally free as for "demo" purposes.

hth

--Peter

I actually tried syncIQ, we are licensed and use it quite a bit to replicate to our other cluster.   However, when I setup a policy to replicate from the snapshot directory back to the original location on the local cluster, it failed when i started the job stating that it failed to snapshot the source, which makes sense for how synciq works.

So I guess that's where the command line argument you mentioned comes into play.  So to clarify your recommendation, when you say i have to have a syncIQ policy setup for the directory in question.  Do you mean to setup a policy like what i described above (source=snapshot, dest=original location), just only run it from cli with that snapshot argument in it?

otherwise, if i had a synciq job setup like my normal stuff (source cluster --> target cluster), it seems that if i ran that policy with the snapshot source argument, it would simply replicate the snapshots to the remote target cluster.

Actually you need a normal syncIQ policy (Just like you would configure without a snapshot)

Then use the CLI flat to define the snapshot to replicate from.

This is essentially a change root for the single run of the SyncIQ Job.

You cannot configure the snapshot into the policy, or set source=snapshot.

What you setup is to replicate an entire snapshot, and that is not what you want you want to replicate a subset of a snapshot so the CLI setup is the only way.

thank you for the info.  Though, I guess I need further clarification regarding the 'regular' policy that needs to be setup.

Since this is not normally a directory that I would have replicating locally, what am I defining as the 'source' in this regular policy?

for example, let's say /ifs/data/directory/directory_1 is the directory I am trying to restore to (the original location).  I would obviously set this up as the destination, but other than the snapshot, there's no 'source' that contains this data.  Would I just use a miscellaneous empty directory as source since the snapshot will be swapped in as source via --source-snapshot on CLI?

i.e. 

source= /ifs/data/empty_dir

dest = /ifs/data/directory/directory_1

but then run it with "isi sync job start --policy-name=temp_policy --source-snapshot=/ifs/.snapshot/snapname/data/directory/directory_1"?

thanks, i have successfully tested this now.  that was my missing piece, that I could not go back to the original location.

So I have a policy with the source as the original location and a new location as the destination.  run the synciq policy with the snapshot specified with --source-snapshot, and I got exactly the data I needed. 

I can then rename the original directory to something else with mv, and then rename the restore location to the original name.

thanks everyone.