This post is more than 5 years old
21 Posts
0
3111
May 17th, 2017 08:00
Netapp migration - Snaplock to Smartlock - Filenet Questions
Hello everyone,
We are looking to migrate our current Netapp arrays over to Isilon, however there is some concern with corruption as well as what the best methodology would be for performing this migration. We have an environment that relies on the Netapp Arrays for it's snaplock technology (Filenet, out of the box no extra modules) and files that are written (well moved into) snaplock shares are also entries in a concurrent database. If it any point the two get out of sync there is corruption. To add some extra anxiety to the migration there is no good backup of this data (one of the reasons we are migrating) there is a mirror but it's LAG time is almost a 3 months.
My questions would be:
What is the best way to transfer all the files (looking for a tool, or functionality in Isilon maybe)?
How do I preserve retention during this transfer (don't want 3 year old files with 7 year retentions, starting over and be retained for 10)?
Any issues with corruption?
Anyway Isilon can be a target for a VSM (Volume Snap Mirror), that is have the Netapp NAS replicate/mirror to Isilon (longshot I know lol)?
Sorry for all the questions am just desperate for some good info.
crklosterman
450 Posts
0
May 17th, 2017 14:00
eespin,
Honestly the best approach for moving SnapLock data to SmartLock (and yes I'm biased here, but I'll qualify it), is to use DobiMiner. I could spend an hour writing up why exactly, but I already did in a blog post about 4 months ago that you can read here:
http://datadobi.com/blogpost/the-mechanics-of-a-worm-data-migration/
I even went to the extent in that post to record an actual NetApp SnapLock to Isilon SmartLock WORM migration. It's only about 7 minutes, long; apologies in advance for having to listen to me for 7 minutes if you watch it
.
You don't want to use isi_vol_copy (or any other ndmp-based mechanism) to move data like this, especially if you are keeping this data around because it's under SEC 17a4 or some other regulatory retention requirement, because you'll never get proper chain of custody, which we provide in every WORM migration as illustrated in the demo.
I'm happy to discuss it more if you'd like, just drop me a line:
-Chris Klosterman
Principal SE
Datadobi
chris.klosterman@datadobi.com
Peter_Sero
4 Operator
•
1.2K Posts
0
May 17th, 2017 12:00
Two whitepapers worth looking at:
https://www.emc.com/collateral/tool/h15756-netapp-to-onefs-migration-tools.pdf
https://support.emc.com/docu79786_OneFS-8.0.1-Built-In-Migration-Tools-Guide.pdf?language=en_US
WORM (Snaplock) is briefly mentioned in the second one.
hth
-- Peter
eespin
21 Posts
0
May 22nd, 2017 14:00
Went through your info, and it certainly peaked my interest and I'd love to use it- the problem is I work for a Government agency and it's pretty difficult to buy things outside of our procurement cycles so I'd rather stick to something I have in house.
Sounds like isi_vol_copy or rsync might be my best bet here.
crklosterman
450 Posts
0
May 24th, 2017 07:00
We've done US DOD and other government work before, but I certainly understand the issue with procurement/budget cycles. The other alternative is that sometimes archiving/document management applications, like FileNet have their own built-in repository migration capabilities. Might be worth a chat with your IBM rep, because just blindly moving over data under retention means that you have to either update the database with the new location, or cutover the whole name of the old system.
Some other suggestions:
Whatever you do, don't use a "free" tool for a WORM migration to an Isilon cluster in a compliance mode. Why? Once the data is committed, there is no privileged delete, so if you put it in the wrong path, or have the wrong permissions, or whatever you're pretty well stuck. The only way to delete data on a compliance mode Isilon cluster is to reformat the cluster. The way DobiMiner/DobiMigrate does it is by doing the commits, and copying the permissions and retention times during a final copy operation, after the last incremental is done.
Test, test, test. Stand up a virtual Isilon cluster that mimic's your production, and copy over a tiny subset of the data with your chosen method, test it, then do it again, make sure you have the steps down perfectly.
Anyway, feel free to reach out if you want to talk through it.
~Chris Klosterman
Principal Pre-Sales Consultant
chris.klosterman@datadobi.com
eespin
21 Posts
0
September 27th, 2017 18:00
Thanks for all your help, I had no idea this was you but you were out to present onsite our SE brought you on and you did a presentation of Data Dobi to us and some AppDev folks. It was great man, I appreciate all your insight on this.
crklosterman
450 Posts
0
September 28th, 2017 16:00
Glad to hear it!. Yeah it's a small world, and I don't believe in co-incidence in this industry.
~Chris