SAN to SAN Data transfer
Has anyone here transferred data from a legacy SAN to another? I've been moving Tons of data via Robocopy but their has to be an easier way to migrate all data from an EMC san to a Dell compellent SAN. I'm trying to figure a way out to just move over volumes at the moment. Dell's compellent confuses me sometimes.
Comments
-
higherho Member Posts: 882Wow never mind. I have to do a lot more work to migrate this data over. Create some new fabrics and make both switches read each other on top of it. Should be fun :0
-
higherho Member Posts: 882That ended short. I was about to configure a trunk port between the two fiber switches (ISL) and the EMC fiber switch does not have it installed and the only way I can get it installed is if I purchase a license for it =/ Sheeeessshs =/
-
onesaint Member Posts: 801That ended short. I was about to configure a trunk port between the two fiber switches (ISL) and the EMC fiber switch does not have it installed and the only way I can get it installed is if I purchase a license for it =/ Sheeeessshs =/
So, what did you ended up doing?Work in progress: picking up Postgres, elastisearch, redis, Cloudera, & AWS.
Next up: eventually the RHCE and to start blogging again.
Control Protocol; my blog of exam notes and IT randomness -
higherho Member Posts: 882So, what did you ended up doing?
I have off tomorrow, so I performed a massive 500 GB robocopy. Hoping it will be complete by the time I come back. If that does not work, then I'm going to see what solutions dell can provide or if their is any 3rd party software to do it for me. I think its pretty bleak though considering I could not trunk the two switches together and create a new Fabric. I will research over the next few days to see if their is anything else I'm over looking. -
powerfool Member Posts: 1,666 ■■■■■■■■□□Use an imaging solution, like Ghost. Have volumes on each SAN that and image one to the other. If you need less downtime or something, you may need another solution. This is where virtualization would be great, as you could use something like Storage vMotion.2024 Renew: [ ] AZ-204 [ ] AZ-305 [ ] AZ-400 [ ] AZ-500 [ ] Vault Assoc.
2024 New: [X] AWS SAP [ ] CKA [ ] Terraform Auth/Ops Pro -
higherho Member Posts: 882Use an imaging solution, like Ghost. Have volumes on each SAN that and image one to the other. If you need less downtime or something, you may need another solution. This is where virtualization would be great, as you could use something like Storage vMotion.
O yea, I forgot I could do that, thank you for jogging my memory! I use Symantec Back up Exec 2011 quite often to. I will do this with the other volumes (I checked the current robocopy on the current job and it already copied over 250 GB of the 500). Storage Center 5.5 and 6.0 have a lot of options for virtualization and migration. I will create a job in Back up exec on the other share to run at 4 am. I already have a volume created too. Will let you all know how it goes. -
blargoe Member Posts: 4,174 ■■■■■■■■■□Connect the two SANs to the same switch, if you can't get the two different switches to talk to each other.
If the EMC SAN is licensed for it, you might be able to use SAN Copy to replicate the LUNS from the EMC to the Compellent over the SAN fabric instead of doing a RoboCopy. I think you can use that with a Non-EMC SAN as the destination, but I don't know whether Compellent would be one of the options. Or possibly, the Compellent may have a similar solution (I'd be surprised if it didn't, but whether you have the entitlement is another story...)
If you can do a block for block copy using SAN tools instead of RoboCopy, you will be less likely to have problems with NTFS permissions and your file created/accessed timestamps will not be affected.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
blargoe Member Posts: 4,174 ■■■■■■■■■□Use an imaging solution, like Ghost. Have volumes on each SAN that and image one to the other. If you need less downtime or something, you may need another solution. This is where virtualization would be great, as you could use something like Storage vMotion.
Yep, this would work too, and being more familiar, would probably be less headache.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
Everyone Member Posts: 1,661The trick with robocopy is to run multiple instances. You can move data a lot quicker if you split it up into several chunks and run multiple instances of robocopy all at the same time.
Well that used to be the trick anyway, I'm not sure if the newer versions with multithreading don't need you to run multiple instances to get better performance.
Many years ago, I migrated 2.5TB (millions of files) from an EMC to a Dell/Equallogic SAN with robocopy, by splitting the job up into quite a few chunks. I want to say I ran something like 12+ instances of robocopy at the same time. The move completed in less than 8 hours.
Robocopy (at least it used to) could only use a limited amount of bandwidth per instance. I can't remember how much exactly, but IIRC it didn't even come out to 1% of what you could push over gigabit ethernet, let alone what you could push over fiber channels. By running enough instances of it, you could move a lot more data at once, and come much closer to maxing out whatever medium you're transferring across.