Hi,

We just upgraded from a Pentium to a Xeon! Woo-hoo!

From Windows 2003 -> Windows 2003 R2 (new box is on a new IP, old box still live)

To restore, I successfully connected to the old DiskSync backup from the new machine, and chose restore.

--- Data Files: selected all folders, except the C:\Windows folder
--- System State: ticked this box.

DiskSync chugged away & restored our data, and then asked for permission to reboot (which I clicked "Reboot Now")

Apart from an "Windows Defender has had an A/V", our Terminal Services window disappeared (indicating a reboot)

This was the last we saw of it .. no ping, no RDP. Did a Remote Reset, and the IP became pingable, no RDP.

Requested a remote recovery console, but our Administrator password was not accepted. (..nor the password from the old server)

From here, I've requested a reload of the OS (plain Windows 2003, same as original server) & look forward to being able to login again & try restoring our data.

My Questions:
-- What mistakes did I make that caused the server to no longer be accessible?
-- Whats the best way to go about this restore?

Many Thanks!

Hi Breeze,

Sorry to hear that this didn't work for you. Although from what you're describing, you are not needing to do a restore. You are needing to perform a migration, big difference.

The root problem here is that you were attempting to use Disksync as a migration utility, but it only works best as solely a backup utility. This is especially true on a Windows server because it is extremely sensitive to changed hardware, and in your case, a different version of Windows. It sounds like you were attempting to restore the old OS on top of the new one. What likely happened is that the OS on your new server became severely corrupted. Keep in mind that this kind of issue would occur with any backup software that doesn't handle hardware changes.

The ideal way to do such a migration would be with proper migration tools. For instance, if you're running a web server with a database then you would only need to copy the web site files and a database dump. The OS would need to be configured independently as well as some licensed software. You will need to refer to the documentation for the software you use for best practices for this since the process for each may not all be the same. It is definitely a bit more involved than performing a restore, but the end result is that you will have more updated software and it will work properly with your hardware.

I hope this helps!

Cheers Mike, thats exactly what I needed to hear.

This time, I restored only the data & left c:\Windows alone. Took about a day or reconfiguring permissions & applications, but all appears good. Unfortunately (and not DiskSyncs fault?) because it's a different machine, all the permissions on folders where lost, so had to be manually reinstated.

Migrating IIS to the new server was initially troublesome (as there's about 3 ways of doing it), but finally worked out this was the way to go, so if anyone needs it, here's how:

On master machine, backup Metabase.xml first!

c:\windows\system32\Iisbackup /backup /b BackupName

Then copy c:\windows\system32\iiscnf\BackupName.* to c:\windows\system32\iiscnf\ on new machine

On new machine:

c:\windows\system32\Iisbackup /list (to see it’s there)

c:\windows\system32\Iisbackup /restore /b BackupName

..sure is pleasing to see all the IIS setings done & dusted! Note: Make sure any custom user accounts are already created, and they will be used.

Thanks again Mike for your valuable advice.

Glad to hear you were able to get it going, and thanks for posting what you found!

By the way, regarding the permissions, this is related to the metadata in your files/folders. Disksync doesn't modify any of that data, so when you use Disksync to copy these to another server then the owners of those files won't match the UID's of what is on the new system. This would happen on Windows or Linux.

For instance, if I were to copy a folder like /home/mmyers on a linux box, it would be owned by my user "mmyers". My user account would have a UID of say, 1000, on that server. If I were to use Disksync to copy that directory to another server, the owner's UID of that directory would still be 1000, but my UID on that new server might be 1001. This could prevent my user on the new system from accessing that directory even though nothing was changed on it. As long as you are aware of this, it's relatively simple to fix.