Unsolved
This post is more than 5 years old
54 Posts
0
1914
Best way to migrate from clar_performance to clarata_archive / Cifs
Hello,
I've been mulling over many options to migrate a CIFS share from one storage pool to another storage pool.
In this case we are migrating from clar_performance to clarata_archive. (How I wish lun migrations were supported! )
Celerra replicator is an option (it's licensed) however when I form the connection and do the migrate then switchover it marks:
Original Filesystem R/O (Expected)
Destination Filesystem R/W (Expected)
However...I need to delete and recreate the share which is somewhat of a manual process.
Also, when it does the migration it puts it on server_2 instead of the vdm that it is attached to.
Details:
NS-480 Running 5.6 Replicator V2
All Cifs shares are served from VDM2
No other VDMS exist.
I've read up on a few other options toyed with in this forum, but I really want to make this as easy and less steps as possible without having to resort to the command line if I can...
Rather than robocopying over things wouldn't it make sense that a Local Replication doing a switchover just work?
I have not tried creating say a 'VDM3' and told Replicator to use that instead of server_2 however I'm afraid I'll come up with the same results of deleting and adding the share back..
Anybody have thoughts? Pointers?
THANKS!
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
1
February 22nd, 2012 17:00
i know some folks on here are just in love with replicator but if i were doing what you are trying to do i would simply use fs_copy/nas_copy to do these steps:
1. Create destination file system with rawfs file system.
nas_fs -name fs52 -type rawfs -create samesize=fs46 pool=clarata_archive
2. Mount destination file system read only
server_mount server_3 -option ro fs52 /dmx3
3. Create first ckpt of source file system
fs_ckpt fs46 -name fs46_ckpt1 –Create
4. Copy first ckpt of file system to destination file system
fs_copy -start fs46_ckpt1 fs52 -option convert=no
5. Create second ckpt of source file system
fs_ckpt fs46 -name fs46_ckpt2 –Create
6. Copy incremental changes between first checkpoint and second checkpoint to destination file system
fs_copy -start fs46_ckpt2 fs52 -fromfs fs46_ckpt1
7. permanently umount and delete migration checkpoints (fs46_ckpt1 and fs46_ckpt2)
nas_fs -delete fs46_ckpt1 -o umount=yes
nas_fs -delete fs46_ckpt2 -o umount=yes
8. permantely umount fs 46
server_umount server_3 -perm fs46
9. permanently umount fs 52 from its temporary mount point
server_umount server_3 -perm fs52
10. mount fs52 with old moutnpoint
boydbria
54 Posts
0
February 23rd, 2012 12:00
Thanks Dynamox... I love TESTING
before production work.
Well as it turns out in my lab on my NS-120 I did some 'commandlining' with Replicator V2 and got it to work. What concerns me from some of the 'searched' solutions is this:
Setup replication session on loopback interface to the appropriate disk pool....
I waited until replications were finished/sync'd
Renamed both Filesystems from testfs to testfs_orig and testfs_replica1 to testfs
Stopped Replication ** this is the part that concerns me... testfs_orig is still mounted R/W after this command...Am I missing something I should do before removing the replication? I.E. do a switchover in the GUI or something?
$ nas_replicate -delete testfs_rep -mode both
OK
Umount both file systems:
$ server_umount server_2 -p -Force testfs_orig
**(needed to pass -Force option because mount was in a VDM)
$ server_umount server_2 -p testfs
server_2 : done
Then I mounted the filesystem in the GUI under mounts and everything appears OK
....
Can someone confirm/deny if I need to do anything before I delete the replication session? I.E. switchover so that old becomes R/O and new becomes R/W...
Thanks!
Brian
dynamox
1 Rookie
1 Rookie
•
20.4K Posts
1
February 24th, 2012 20:00
yes, you need to switchover ..source fs becomes r/o and target becomes r/w and then delete replication.
boydbria
54 Posts
0
February 24th, 2012 20:00
Thanks again. I'm gonna try it out in the lab tomorrow morning on a NS-120 I have before going into production but I think that was the 'missing step'.
There is a document on this community highlighting everything above and it is missing the switchover part... I should probably comment on that doc too after I verify in the lab.
christopher_ime
2K Posts
0
February 28th, 2012 23:00
Simply to offer another view, maybe the following post will help also:
https://community.emc.com/message/584859#584859