OSS OS Copy fails/crashes...

Hi all,

I've installed DD 10 Build 2,160 on a freshly installed XP Pro SP3 machine. The OS is on drive C, NFTS, 118GB primary active partition.

After installing and running OSS, I selected the detected OS and tried to perform a Copy.

I get a dialog box stating "Copying the selected operating system will result in losing file security attributes...". I click Yes to proceed.

I then get another popup, stating "Processing, Please Wait"

If the program is running from Windows, OSS then blows off the screen with no trace. I see nothing in the NT Application event log, or Disk Director's log. The process dissapears from TaskManager.

If I run OSS from the boot window the behavior is simialar, but the OSS GUI dissapears and is replaced by a black screen with a "_" cursor in the upper left corner. It hangs that way forever.

I apologize if this is a trivial pilot error, but unfortunately, I bought DD more than 30 days ago, and although this is the first time I've used the app, Acronis will not answer this question in a Chat session for free. I'm somewhat underwhelmed so far.

Thanks in advance for any help...

 

Why are you trying to copy the OS? Is there a specific purpose or need? Perhaps there's a better method to use.

Personally, I would avoid the copy feature. It takes too long and it's has to copy all the Windows system files/folders. In the end, it's not a true copy because only the "protected" folders are copied. These have to be switched whenever you want to switch between the copies.

 

I was trying to make an OS copy as one layer in a disaster recovery plan for the XP-based machine vision systems we deploy. I recently wasted a lot of on-site time rebuilding a customer's system after its Windows install got corrupted due to a "power event". The drive and all data were fine, but Windows wasn't. I and the customer would have been rather happy to just pick an alternate copy of the OS to boot from; I presumably then could have helped them via our normal remote management mechanisms.

We ship the systems with two SATA drives, and they are both bigger than they need to be. We currently do them as single partitions. Right now, the OS and the 'hot' copies of the data (SQL, web stuff, and image data) are on the C: drive, and archives and DB backups are sent to the second disk. I've recently ammended our archive procedures to send additional copies of the data to a thumb drive.

This keeps us from irretrievably losing anything important, but it doesn't help avoid customer downtime if they experience a C: drive hardware failure or OS data corruption. We've had one of each in recent months.

I'd be happy to take suggestions that don't involve OSS, although I paid for it and would sort of like to know why it is failing.

In the end, we'd like to have a bootable clone of the system's "as shipped" C: drive (in a hidden partition?) on the second physical drive. I would be happy to create and ship a bootable USB thumb as part of the scheme.

Whatever the plan, the alternate boot scenario needs to be easy enough to invoke that I can coach someone through it over the phone. Ideally, the installation and cloning process would be at least mostly invoked from Windows, so we could do it remotely.

What would you do if it were you?

 

I would use Acronis True Image, which was designed for precisely the scenario that you are describing. Acronis Disk Director was designed to let you do partition operations on the disk, much like Partition Magic.

 

I don't know why the copy operation failed. The fact that it said the security attributes would be lost makes me wonder about how it copies the files. I seem to remember from before reading that if you used the copy feature, OSS had to be installed to a FAT32 partition. However, I couldn't find that in the current manual. I don't know why the security attributes would be lost on an NTFS partition. Acronis has not updated or released bug fixes for OSS in several years. As a result, it (and DD) are both having increasing problems working correctly on newer computers.

I would also not use OSS as a solution for this problem. An imaging solution would be much better, though it would be a little more involved.

Depending on your setups, it may be possible to install another installation of XP on the second drive. Keep the partition just small enough for XP and TI (or whatever imaging program you're using). Configure the system to boot from either XP by just selecting the drive in the BIOS boot menu (most new computers have a key to press at boot-up for this, so it's easy). This would allow quick access to your "recovery" XP, remote access, etc. If you don't want the "recovery" XP partition visible to the main OS, just unassign the drive letter in Disk Management.

 

I agree that an image-based approach makes sense. Since I already had DD Suite on the machine, I did a clone using the following steps, which appeared to work. I thought I'd post my results (and a request for feedback) on this thread before the forum closes for good.

1) Finished OS and application installations (including DD Suite) on Drive 0, with a single NFTS active partition, assigned as C:

2) Used DD to clone that partition to drive 1. Both partitions were left marked as primary and active. I assigned E: to partition on Drive 1, also in DD.

3) Used DD to clone the MBR from drive 0 to drive 1

4) Went through the various reboots required to let DD perform its partition,copy, and mbr operations. Verified that the original Windows on Drive 0 was still happy.

5) Switched the BIOS boot order to boot off of drive 1 instead of 0. After rebooting into the 'backup' copy of windows on Drive 1, changed Drive 1's Windows' Desktop wallpaper to something unique so I could easily verify which copy of Windows was booting. This all looked great, but the drive letters weren't swapping automatically, which would confuse most apps... Windows was now booting off of Drive E, and the other drive was still drive C

6) Windows Disk Management won't let you change the boot OS's drive letter, so I used DD to remap E: to C: , and vice versa.

So after a few more trials of switching the boot order between the two drives, it appears that I have what I want; no matter which physical disk I boot from, the booted Windows disk thinks it's Drive C:, and I have a secondary drive E:. I can now make my apps and archive scripts function identically no matter which drive Windows boots from.

So here are my (parting?) questions:

1) Is there some latent flaw in this approach that is waiting to bite me? Eg, is something eventually going to get angry about there being two primary active partitions? I did it that way so the user wouldn't have to fuss with a third-party tool (other than the BIOS) to activate the backup boot scenario.

2) If, in the future, I were to do this procedure with True Image instead of DD Suite, I'd be able to add another layer of recovery options (hidden/offiste images, etc), which would be nice. The Universal Restore slated for TI 2010 would be particularly comforting. But without DD, how would I deal with the drive letter assignments? Does TI or some other simple tool let you re-assign the Windows boot drive's letter? I couldn't find mention of it in TI 2009's user guide.

Thanks again for your help.

 

No, this should work now that you have the drive letter issue sorted.

You can have it both ways. If you used TI you could set up the PC the same way with an OS duplicate on the second disk. Additionally, if there is room on the second disk for additional storage you could have TI automatically create images of the main OS on a predefined schedule and store them on the second disk. You could then walk a user through the procedure for restoring one of the images back to the main disk or if the machine were still functional you could even connect to it via Remote Desktop and try restoring remotely.

The drive letter issue could have been avoided. It is a Windows issue and occurs when you boot a PC that has two identical hard disks. You created that situation when you copied the MBR from disk 1 to disk 2, thus giving both disks the same Disk ID. Then you copied the Windows partition with predefined drive letter assignments in the registry. So you had two identical disks as far as Windows was concerned.

The first time that you boot the second disk, Windows will detect this and change the Disk ID on the second disk, thus invalidating all of the drive letter assignments on that disk and causing Windows to reassign drive letters. What happens next is that while booting, the registry will already have contained a reservation for the C: drive letter in HKEY\Local_Machine\System\Mounted Devices. Since C: has been reserved, it will assign another drive letter to the Windows partition on the second disk.

The way to avoid this would have been to remove the first disk before attempting to boot the second. Once the second disk has booted once, both can be reconnected. Each will then be correct.

I'm surprised that you were able to fix this with DD. Usually it requires a trip to the registry to edit the above-mentioned key to fix the drive letters.