use ecs for third copy

Ok, I'm not entirely sure what you are saying, but understand that if you cannot run CloudPools from a SyncIQ target unless you are failed over.  The tree that is being stubbed must be read/write and active SyncIQ targets are read-only.

Correct.  You cannot recover the data from the ECS without the stub.  The data on the ECS is stored in 1MB chunks that are named with hashes.  You must protect the stubs as you would the data.  The mantra I give to my SEs and customers is "lose the stub, lose the data".

Of course the stubs can be replicated to your DR cluster and that cluster can read the data from the ECS and can be set to update and archive to the ECS if necessary.  And stubs can be backed up with traditional backup software as well.  Keep in mind what I wrote above with respect to versioning.  That's something that real backups can give you.

Ok, that makes sense for your case. But I have seen this confusion before so it was worth mentioning here. 

But keep in mind that snaps don't go to the cloud so you will have a recent copy of your file in the cloud, but you can preserve more point in times copies on the SyncIQ target.

If your goal is to have true backups to the ECS with multiple versions and indexes, etc., consider CloudBoost from the Data Protection group.

yes the idea is really to have a third copy or a "backup" copy but without using a backup software in the middle.

Only issue here is we still an isilon to read the stub. So if we loss both isilon the data are still on the ecs but we can't read them without rebuilding a new isilon cluster and restoring the stub right

yes sure it would be more a third copy than a real backup.

Last idea would be create on a third site the minimal isilon cluster to save the stub and put the ecs behind this one

i say third copy because we already have 2 isilons replicated through sync iq.

Not exactly as you have described it.

There is no file pool policy that will put files directly onto ECS.  Files will be tiered to ECS when the SmartPools job runs.  You can have a policy that says all files under a given path should be archived to ECS but it won't happen immediately.  This is unlike file policies that are local to the cluster.  It is possible to have OneFS place the files in a given path on a particular nodepool or tier.

And it won't be a 3rd copy of your data.  When data is archived to the cloud, it's archived,  A stub is left behind on the cluster with the metadata of the file, but the data resides in the cloud (in this case, the ECS).  So you would still have 2 copies of your data.  The production copy and a copy under "backup" which would live for a short while on the cluster, but would eventually move to ECS.

Ultimately if your goal is to have a 3rd copy for let's say Isolated Recovery purposes, then stubbing and archiving really isn't the right way to go.  You need to copy or synchronize a copy to a 3rd NAS of some sort.  Many customers want this to be a different than regular DR, maybe in a cloud-hosting provider.  Perhaps using something other than SyncIQ as a transport mechanism if the target is Isilon so that you get some granularity over what data to sync, or if you perhaps want to introduce delays into the sync process on purpose to avoid replicating perhaps ransomware corrupted data.  There is a good overview of these concepts on youtube from DellEMC here:

How to Survive a Destructive Cyber-Attack - YouTube

Anyway that's something we can certainly help with using our data synchronization software if you want to look into it more, just drop me a line.

~Chris Klosterman

Principal SE, Datadobi

chris.klosterman@datadobi.com