Rsync vs dbcopy for migrating to new server

Question

There is plenty of information about using dbcopy to achieve a server to server migration of Groupwise, and it's particular useful because initially Groupwise can be copied live.
In my case, GW resides on NSS, so for dbcopy, I need to do a ncpmount first, then
Code:
dbcopy -m -f [-p |-d]
shutdown the agents for the the final:
Code:
dbcopy -m -s [-p | -d]
DBCOPY IS SLOOOW - Well at least according to TID 7010760: "Note: Typical dbcopy throughput is 6GB/hour."
So in the interests of maximum speed my question is - If the agents are shutdown, and no dbcopies have taken place yet, or maybe the first one has, is it ok to just use rsync and not worry about dbcopy?
Code:
rsync -av --delete source-po dest-po
rsync -av --delete source-dom dest-dom
I even thought about using (with GW shutdown) sftp as it pulls data at between 1-2GB per min, then follow up with rsync as a double check.
I am yet to do some proper testing and time trials, but just wondering what others have found.
Thoughts anyone?

Answer 1

Originally Posted by gordon_mzano
Source = OES2 SP3 x86-64, NSS, physical server
Target - OES11 SP2 x86-64, NSS, virtual server on ESX with local storage.
As we are going linux to linux the dbcopy lower-case conversion is not relevant.
Yes, but there can be a catch. NSS is case insensitive, even on OES when NSS uses the long format (which is the default name space ever since OES2 SP1) . It is possible that you have been running GroupWise on OES with NSS as filesystem and are now moving to a Linux native filesystem.... that *could* warrant running a dbcopy with the m option.
But as you are moving to NSS with, I assume the default "long" namespace set, that is not an issue.
Originally Posted by gordon_mzano
Being ultra paranoid, what I did in the end after running the two dbcopies, I checked both PO sizes with `du -sm`, and the size was greater at the target by about 1.2GB.
That's not paranoid imo, that's showing good sense
But yes, it is normal that you will see a slightly larger copy on the target side. It has to do with dbcopy logs but also some other files that I have not looked closely at.
Originally Posted by gordon_mzano
So with the PO shutdown, I ran a full rsync so they were exact. I am not sure if the rsync was really needed, but I like to keep the file system lean as possible. Are there gwcheck routines that would clean up the extra files that dbcopy built up at the target? Maybe the orphaned file check that I see in the logs would do such a thing..?
GroupWise PO content maintenance jobs will clean up "stuff" like logs and unused databases/blob files etc. But it won't clean up everything.
Sure, you can run rsync to make sure source and target match up 100%, but do do so while no GroupWise agents are running against the data storage you are rsync'ing.
Cheers,
Willem