Large file server restore options

[jrafter]

Good day.

Requirement: Upgrade large 2008 MS VM file server to 2016. Both servers are local in same data center in same cluster.
New 2012 server has been built. Started the process of restoring using the "Guest Files restore" option, after a couple if hours it became apparent that it was going to outlast our maintenance window of 12 hours.
Back to the drawing board...looking at the "Virtual disk restore" option. The steps involve selecting a target (new 2016 server), selecting virtual disk from source VM(2008 server). The restored virtual disk will be stored on the data store been indicated(new 2016 server). Last option is to select "restored disk type"...> the fact that the old server was using VMFS 5 and the new server is on a VMFS 6 format would this be an issue?

Also would this route of restoring be quicker than using "guest file restore" option?

Thank you in advance

[veremin]

Not sure whether I follow you on that... if you want to upgrade Windows Server 2008 VM to Windows Server 2016, why not to:

- Update it first to 2012
- Update it then to 2016

No need to restore anything in this scenario - just back up VM prior to performing in-place upgrade and restore the whole VM back in case upgrade goes wrong.

Thanks!

[jrafter]

New Server is already built as a 2016. As a best practice we typically never preform an in place upgrade but thanks for the feedback.

[bdufour]

is the file server is on the same LAN? if so, just use DFS or robocopy. both servers can be up and will not impact your maintenance window.

[jmmarton]

You should be able to restore an entire virtual disk from one server to another, and I'd expect the performance of that to be much quicker than individual FLR if you have thousands or even millions of small files within the guest. The only part I'm not sure of is the change of VMFS version. You could always try it and see if the new VM has any issues mounting the restored disk.

Joe

[Cuebid-Fredrik]

Just as a feedback about file server migrations, as we are doing a lot of them now that 2008R2 is close to EoL.
Install 2019 and use File Server Migration tool.
The file copy can take however long time it needs, because at the time of swapover you refresh/synk the changed files and then the tool does the remaining tasks.
If the logs show files not copied for any reason, or you really want to be sure, use Beyond Compare and copy over the differences.
For a 2TB file server the copy takes about a day depending on infrastructure, the synk/swap takes 2-3h of downtime.

[MPev]

Since you posted in the vSphere forum I'm assuming that's what you're using.

If your data is on a separate data disk from the OS you could just detach it from the 2008 and attach it to the 2016. I did this recently and the only thing I had to recreate on the new server were the shares. I had downtime of about 30 minutes.

Let me know if this could be an option, I can dig up the reference links I used.

[YouGotServered]

I'm a big fan of Blake's solution. I typically use robocopy or some 3rd party utility to copy files to a new share over the course of a week or so, then I do a final sync, kill the old shares, and cutover. Sometime you manually have to redo permissions and re-make your shares, but I take that as a good housecleaning opportunity. You can certainly use Veeam to do this, but it seems like that would be introducing complexity to the situation. I think it's always good to start with a new VMDK / partition / etc, you never know what kind of corruption has seeped into your old VMDKs over the years. Best to start fresh.

[bdufour]

agree with YouGotServered - we map all of our drives/shares via DFS namespace and replicate them across datacenters. if one datacenter/file server goes down the DFS file server at the DR DC takes over without any downtime. i just retired an old 2008r2 file server and just used DFS to copy the files to the new server (same DC), works well. ntfs permissions are preserved, only new shares needed to be created.

[YouGotServered]

One thing with DFS - make sure your staging area is configured to be bigger than your biggest file. We have 20+ GB PST files that broke DFS because they couldn't fit in the default (10GB I think) staging area.