I assume the disks are SCSI ?
If possible hook both disks up on a 3rd machine (Intel box) and use a Linux live-CD (PartedMagic is ideal for this) to boot that system.
Then make a RAW disk 2 disk copy wit GPartEd (or even DD if the disk-format isn't recognized).
That is the easy and probably most reliable way. Of course this means downtime for the production server.
If disk2disk isn't an option the recovery tape would be the only thing I guess. But how can you be certain you have a good image if you are making it from a live environment ?
I don't have any experience with HP-UX, but many old Unix systems (Ultrix, BSD, Sco Openserver, Solaris) in the days of yore could be "cloned" if they were running a mirrored disk-system using the following trick:
On the primary system just shut it down.
Pull the mirror-half from the system and stuff it in the other box (take care to place the disks in the secondary system in exactly the same slots as they originally were on the primary).
Then add empty (zero-filled) disks to both machines to restore the mirrors.
Start them up. (you might need to fiddle a bit to get it to boot from the working mirror-half: Rebuild mirrors and you are OK. (Just don't put both machines on the same network as their ip-addresses, nodename would conflict.)
Another thing to worry about: If that server hasn't been down for years there is a major chance that the disks won't spin-up anymore after they have been off for some time. Just a few seconds of stand-still could be enough to seize up the disks.
Regardless what you do: Whoever made the decision to keep running on this antique without proper backups/redundancy for years should be shot, drawn and quartered.
AD Servers are different. A Domain Controller has a directory junction on the C:\Windows\SYSVOL\sysvol directory that points to the C:\Windows\SYSVOL\domain directory:
Directory of C:\Windows\SYSVOL\sysvol
04/13/2011 01:22 PM <DIR> .
04/13/2011 01:22 PM <DIR> ..
04/13/2011 01:22 PM <JUNCTION> domainName.acme.com [C:\Windows\SYSVOL\domain]
Almost any type of a manual copy operation would result in a SYSVOL that does not come online due to a borked junction. Although to be accurate, this can occur in normal restore scenarios, so it is always advisable to check and re-create the SYSVOL junction if necessary.
Speaking of links, any Windows 2008/Vista/Windows 7 system may have thousands of links in the %SYSTEMROOT%\System32 folder for the binaries. These link targets actually reside in the %SYSTEMROOT%\Winsxs folder.
I haven't confirmed this, but Robocopy may copy the target instead of the link. Which would explain the switch /SL :: "copy symbolic links versus the target".
It's possible the system may appear to function correctly, but what would occur when it's time to perform a system update activity, that needs to maintain the files where the link targets usually reside? Perhaps it would re-create them, but that would be something worth testing.
If you're curious how these links transferred to the copied disk, you can take a before and after snapshot, then compare the files using Windiff or Notepad++.
You can use the following command to get an output the junction points on a drive:
dir C:\ /aL /s >> junctions.txt
You can use the following script in a file to get a an output of the links for a location (for example, systemroot):
for /r %systemroot% %%i in (*.exe,*.dll) do (
echo Checking file: %%i >> file.txt
fsutil.exe hardlink list "%%i" >> file.txt 2>&1
echo . >> file.txt
)
Best Answer
I think you have done things the right way :
However double-check for the network interface number (
ethX
). I've noticed that sometimes cloned VMs change theeth
number (eth0
on the source becomeseth1
on the clone)Finally, make sure you have restarted the Network on the clone to make sure that your changes in
/etc/network/interfaces
are applied :/etc/init.d/networking restart
If you are not sure, restart the clone once again (still with Ethernet cards plugged off).
To be sure, on the clone, run a ping against the new ip address of the
ethX
interface and see if it is responding. If you have a reply it's OK.Also (still from the clone and with network card still not connected) ping the actual live server ip. If you have no reply it is OK (that means you don't have a remaining reference somewhere to the old IP from the original live server).
Also, check your
/etc/hosts
file to make sure it has been updated with the new hostname.Now, you can safely plug your clone Ethernet adapter.
And, as you said, the worst that could happen is an ip address conflict that could make your live server loose its network connectivity. But it should not happen if you have double-checked the above.