gshaw Posted June 1, 2011 Posted June 1, 2011 Just a quick thread to confirm my logic... Moving from a physical box (2003 Storage Server) to a new 2008 R2 VM, just want to shift the data over (around 500GB) as is and get up and running on the new VM... Was going to use Robocopy to shift everything over using this command... robocopy \\source_server\d$\data \\dest_server\d$\data /E /V /R:0 /W:0 /COPYALL /LOG:data_copy.log Was wondering if to up the /R and /W times in case there's any network hiccups, saw 5 and 30 mentioned as reasonable options? The other thing with Robocopy... if I run this command say 2 weeks before the migration to do an initial seed can I run it again just before the migration and it'll just hoover up the bits that have changed since or does that require the /MIR switch? Once that completes I export the registry key from the old server using this method... Saving and restoring existing Windows shares Import the key onto new server (making sure before I copy the data the drive letters match). Stop Server service, restart Server service and I should have all the shares available under the new server name. Then if I want to make life really easy for myself remove old server from the domain and shut down then reconfigure the new VM with the IP address and network name from the old server. In theory it should then appear to users and GPOs to be exactly as everything was before... (I know FSMT is there as well but I prefer the Robocopy method as it gives me a bit more control.) 1
FN-GM Posted June 1, 2011 Posted June 1, 2011 The other thing with Robocopy... if I run this command say 2 weeks before the migration to do an initial seed can I run it again just before the migration and it'll just hoover up the bits that have changed since or does that require the /MIR switch? I am going to be doing the same thing in a few weeks. You will need to use the /MIR switch yes. Doing this will make any changes that happened on your old server to the new one If both servers are on the same domain this will make the job eaiser if your not comfortable with robocopy Download details: Microsoft File Server Migration Toolkit 1.2
SYNACK Posted June 1, 2011 Posted June 1, 2011 Yes it will do all the things that you are afrer, I would use the /ZB switch also, it will take a little longer but you will have a much more robust and hassle free transfer experience. You can use the /MIR option the second tome to just quickly update it. I have done this several times in the last couple of months for various schools and it has worked well. You do want to lower the retry count as otherwise it will hang up on a failed file for ages. I would also pipe the log file to a text document for later looking over. Its just the /LOG:"filename.txt" switch. Not sure about the share restore, registry stuff as I have not done that bit but your plan seems sound. 1
gshaw Posted June 1, 2011 Author Posted June 1, 2011 (edited) Thanks for the replies, originally liked the look of FSMT but seen enough threads with weird behaviours that I feel happier with Robocopy and knowing exactly what's going on. So we're up to the following code initially then... robocopy \\source_server\d$\data \\dest_server\d$\data /E /V /ZB /R:0 /W:0 /COPYALL /LOG:data_copy.log And once that's done nearer to the time go for... robocopy \\source_server\d$\data \\dest_server\d$\data /MIR /V /ZB /R:0 /W:0 /COPYALL /LOG:data_mirror.log Or just go for the tape restore, just thinking which one will work out quicker really Edited June 1, 2011 by gshaw
ChrisH Posted June 1, 2011 Posted June 1, 2011 (edited) what does the /zb switch actually do please? It tries to copy first then switches to backup mode. Edited June 1, 2011 by ChrisH
SYNACK Posted June 1, 2011 Posted June 1, 2011 Thanks for the replies, originally liked the look of FSMT but seen enough threads with weird behaviours that I feel happier with Robocopy and knowing exactly what's going on. Or just go for the tape restore, just thinking which one will work out quicker really Looks good, robocopy will probably be quicker than your tapes but it could be a good restore test for them, in the case of bringing the share up to date quickly the second robocopy command will blitz tape.
Gibbo Posted June 6, 2011 Posted June 6, 2011 If it were me I'd break the job down into smaller ones, just in case you get a few copy errors.
zag Posted June 6, 2011 Posted June 6, 2011 Personally I would use your backup in this situation, its a great way of checking if you actually are backing up everything that is needed I use backupexec 2010.
SYNACK Posted June 6, 2011 Posted June 6, 2011 If it were me I'd break the job down into smaller ones, just in case you get a few copy errors. Thats the good bit about robocopy, it will just log it after however many retries you specify and continue unlike the rubbish copy in xp/2003 or the slightly better version in 2008.
gshaw Posted December 2, 2011 Author Posted December 2, 2011 Sleeping thread resurrection time! Had a slight change of plan with this after some of our teams were restructured, just moving our shared areas for now as the user folders need more work to sort them out for Windows 7. I'm now looking at using this command first to seed the initial copy of the data, one batch file per shared folder to be copied... robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /E /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG:Source_Folder.log Then when coming to the migration unshare the source folder (i.e. no more changes possible), run this... robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /MIR /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG+:Source_Folder_MIRROR.log After which point I then move the transferred files from TEMPAREA to their new home (and also replace all the copied permissions with those of the new folder they live in due to merging multiple folders into one for some areas) Did a test with our IT shared area and it copied everything over, MIR removed deleted files and added new ones... so far so good... have I missed anything? (as you can tell this process makes me very paranoid being that it only gets moved once every 5-6 years!) 1
albertwt Posted June 30, 2014 Posted June 30, 2014 Sleeping thread resurrection time! Had a slight change of plan with this after some of our teams were restructured, just moving our shared areas for now as the user folders need more work to sort them out for Windows 7. I'm now looking at using this command first to seed the initial copy of the data, one batch file per shared folder to be copied... robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /E /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG:Source_Folder.log Then when coming to the migration unshare the source folder (i.e. no more changes possible), run this... robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /MIR /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG+:Source_Folder_MIRROR.log After which point I then move the transferred files from TEMPAREA to their new home (and also replace all the copied permissions with those of the new folder they live in due to merging multiple folders into one for some areas) Did a test with our IT shared area and it copied everything over, MIR removed deleted files and added new ones... so far so good... have I missed anything? (as you can tell this process makes me very paranoid being that it only gets moved once every 5-6 years!) So does the command above still works with folder that are deeply nested and longer than 255 characters long ?
SYNACK Posted June 30, 2014 Posted June 30, 2014 So does the command above still works with folder that are deeply nested and longer than 255 characters long ? Yes it should, robocopy has built in mitigations for the 255 character thing, I am pretty sure it is automatic, I don't remember having to add a switch for it.
Boredguy Posted June 30, 2014 Posted June 30, 2014 We use robocopy nightly for our backup of user data, and it's never had an issue with long file names
gshaw Posted June 30, 2014 Author Posted June 30, 2014 From what I remember everything copies but you get trouble working with the files after e.g. renaming and saving. We cleaned up the files before the migration which removed any doubt. The scripts and robocopy pre-sync / difference sync method worked a treat, had them running on schedule overnight then did the shares the next day.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now