I'm hoping that the data is on a separate partition from the OS. That's pretty critical.
Some things to consider - /S is redundant to /E - use just the /E - /V will really slow down the copy job - I'd consider not using it, as I've found robocopy to be very robust. - If you shut down the server service on the old machine, you can use /R:0 and /W:0 - Ditto for the /ZB switch - not needed in this situation, most likely, if the server service is shut down - If the partition on the new server is empty, you will not need /MIR - You might want to do a first run with just the /CREATE switch - it can really help mitigate disk/MFT fragmentation, and you will won't need the /MIR switch - Don't forget to create the shares on the new machine I won't go into using security in shares vs. NTFS, nor making sure that shares aren't set at the root of a drive - I have my own thoughts on those subjects, but that discussion is probably not relevant to your task (I hope). Kurt On Mon, Jan 29, 2018 at 11:27 AM, Michael Leone <oozerd...@gmail.com> wrote: > I'd like to impose once more for some advice and opinions. I have a Win 2008 > R2 file server; I need to migrate everything (shares and user home folders) > to a Win 2012 R2 Storage Server, and then retire the old server. Everything > is one 1 drive, with 3 main folders (Shares,Users,Scans), total size in the > neighborhood of 2TB. Both have 4 teamed 1G NICs, so a total bandwidth of 4G. > > I'm thinking of use robocopy. I would make a full copy over the weekend: > > Source=OldFS\F$ > Destination=NewFs\d$ > > RoboCopy <Source> <Destination> /S /E /ZB /COPYALL /R:1 /W:1 /V /NP /NFL > /NDL /LOG+:<LogFile> > > That should get everything, NTFS security and all sub-folders. I thought > about the /MIR option, but I've never used it, and so am just a touch leery > (perhaps illogically). > > The end goal is to: > copy all the files and shares to the new FS; > re-name and re-IP the old FS; > power off the old FS; > re-name and re-IP the new FS to the old name. > > (this way I can power up the old FS, just in case I need it for something > I've missed) > > That *should* make things transparent to the end users. > > (ordinarily, I would think about doing a restore from my backup program > Networker. But this is a remote site, and I believe that doing a local > robocopy will probably be faster than trying to restore 2TB of what is > probably a lot of small user files and folders across a 1G link) > > What have I missed? What would make it better? > > >