I am trying to migrate data using fs_copy. I would like to do an initial full copy and then an incremental. Looking at fs_copy and celerra replicator documentation i've followed the following steps, but yet my incremental copy takes just as long as my initial copy. Here are my steps:
1) create first checkpoint of source file system
fs_ckpt fs46 -name fs46_ckpt1 ¿Create
2) copy first checkpoint to destination file system
fs_copy -start fs46_ckpt1 fs52 -option convert=no
then i copy a 30mb file to my source file system
3) create second checkpoint of source file system
fs_ckpt fs46 -name fs46_ckpt2 ¿Create
4) copy incremental changes between fs46_ckpt1 and fs46_ckpt2 checkpoints
to destination file system.
fs_copy -start fs46_ckpt2 fs52 -fromfs fs46_ckpt1
Here this is where i am having an issue ..this incremental processs should only copy the 30mb that changed between the snapshots ..but it seems as it's doing a full copy again because the time it takes to complete this operation is the same as the initial copy. When i mount the file system i do see that 30mb file that was captured with the second snapshot. What am i missing ?
yes, checkpoints are mounted. How big of a file system do you think i need to work with to see the difference between full and incremental copies. I am planning on migrating a 2T file system, but was trying to see if there was a better way without keeping source file system in read-only mode for ~8hrs
its kind of an "inverse HSM" - the Cerra mounts the source via NFS or CIFS and takes over its original IP. The original is placed "behind" the Celerra and stub files are created on the Celerra pointing to the original data. Once a client accesses a file it gets pulled over, stored on the Celerra replacing the stub and sent to the clients. You can then also have script accessing all files to trigger the migration.
Once everything is done you just convert it to a normal file system.
it used to be for EMC professional service only - but is now supported and documented for customer use. Take a look at the Celerra documentation library - there is a whole manual about it.
So a kind of a background migration with minimal downtime and client changes
Its not going to be faster than fs_copy - just more choices. Its also heterogeneous - it supports quite a number of source servers besides Celerra - listed in the support matrix
The only downside is that once you have started, you have to pull thru - there is no fallback since you have new data in the new file system and still missing some old files from the old file system.
you were absolutely correct. It does take some time, based on the file system size ..to get compare the changes between first and second checkpoints. I created a 400G file system, first fs_copy process took 15min to complete, i turned around and created second snapshot and it took 5min to complete even though there were no changes made to the source file system. So i migrated 4x2T file systems and everything went smoothly. It's awesome, NTFS were intact, tree quota settings remained the same and since i remounted to the same mount point, all my sharepoints did not have to be re-exported. Now we just need a file level copy tool to migrate file systems
Rainer_EMC
6 Operator
•
8645 Posts
361
0
Posted March 4th, 2007 14:00
However for very small tests you probably wont notice a difference in elapsed time - incremental needs some setup time and preparing the blockmap.
for a longer running one you can do a fs_copy -info to and look at blocks_transferred - but be aware that its quite "jumpy"
fs_copy customer reporting leaves some info to be desired - you are welcome to file a product enhancement request for it.