Method for replacing Windows system disk

Make a whole disk image of your current drive then remove that drive (as it has served its purpose). Put in the new drive then restore the whole disk image to that drive.

I'm personally against cloning as you are working on the source drive directly, so if anything goes wrong. It can cause a nightmare scenario but working with images, you are more safer because the source drive is unplugged from the computer and put away.

Didnt read it all... Your proposal would work... should def use the backup/restore rather than clone... 
I would do it slightly differently... but your proposal is fine (IMHO).. I would just do....
Simply..
1.Backup your existing drive, full backup.. all partitions.. etc.
2. Create bootable rescue media on your machine you working on.
3. Remove your existing SSD and add your new bigger SSD to the machine..
4. Boot using the recover media you produced in step 2.
5. Restore  your backup to your new SSD... .
Cant recall if Acronis will sensibly resize your partitions to maximise your C drive on the new drive.. ... but that a minor point.. can always resize after if needed.

I realise that my way needs an external drive.. and your way.. you could put your backup on the original disk.
But I am hyper careful on such things.. so my way, the primary consideration is that my source system disk is untouched.. and out of the machine when doing anything significant... so if it all goes pear shaped, then I have initial disk untouched and can just be slotted back in.
And who does not have a spare 1tb (min)  external USB disk lying around these days?  
 

One thing that strikes me is that you propose, if I have correctly understood what you propose) is to locate the new disk in a USB caddy the do a clone. Microsoft prevents you for making a bootable installation on a USB drive, so you need to install the new drive in a SATA or M.2 port.

I agree that doing a backup of the old drive, removing the old drive, then placing the new drive in the computer, boot from recovery media and recover to the new disk, is the best way to go. 

Note: you may end up with empty space at the end of the drive, and you will need to resize the partitions. [Do not no if this "bug" has been fixed in the latest build of ATI 25.] I use MiniTool ® Partition Wizard Free to move the hidden partitions to the end of the drive, then enlarge the other partitions.

The reason why experienced users recommend disk + partitions backup is that if you have multiple physical drives, it allows customizing of backups tasks to reflect the underlying pattern of changes. The system drive should be backed up regularly, but a disk containing photo archive is best backed up when new files are added (assuming that you only add files irregularly). 

Ian

Rodolfo,

First for everything about Disk Signature look Here

Your plan is flawed because you are wishing to replace the existing disk with a new disk.  The new disk MUST bring with it the disk signature so that the PC can identify the disk and therefore successfully boot to Windows. 

The plan you have would be successful IF you were recovering a disk image to the original disk because the disk signature is not overwritten in that scenario.  

To recover to a new disk because the disk signature must be written to it Acronis and the MVP community recommends using bootable recovery media to do so as this method will successfully carryover the disk signature from a full disk backup image.  

look to the links below for further information:

How to create bootable media

How to recover with WinPE or WinRE based media

Enchantech wrote:

Rodolfo,

First for everything about Disk Signature look 

Your plan is flawed because you are wishing to replace the existing disk with a new disk.  The new disk MUST bring with it the disk signature so that the PC can identify the disk and therefore successfully boot to Windows. 

The plan you have would be successful IF you were recovering a disk image to the original disk because the disk signature is not overwritten in that scenario.  

To recover to a new disk because the disk signature must be written to it Acronis and the MVP community recommends using bootable recovery media to do so as this method will successfully carryover the disk signature from a full disk backup image.  

look to the links below for further information:

 

AAhhh... so is this the reason Steve talks about "Microsoft does not allow you to create bootable drives from an external USB drive/enclosure"?
So its all related to these disk signatures?  so is that what is held in the  UEFI  when you select the "windows boot manager"? it in effect stores the GPT disk signature of the drive to boot to?
Is it something Acronis could fix.. i.e. for USB drives doing a restore.. allow it to write the disk signature.. even though it would create a immediate conflict... if you shut down.. swap disks.. the new disk would work?
Are there tools to manage this? so you can copy disk signatures? or update the windows boot manager to insert a  disk signature to tell it/change which disk it boots to?

This is why I lurk here... pick up little snippets of info now and again (make up for all the repetitive dross I have to plough through ;-)   )

Yoji, you may like to take a read of webpage: How to Change the Disk Signature of a Drive Without Losing Existing Data or Reformatting - which speaks to disk signatures and using diskpart to handle the same.  The article is old and is referencing Windows 7 but the principles are still good and works on Windows 11.

Ditto Steve's response.

Thank you, everyone, for your helpful feedback, advice and informative links.

Based on this additional knowledge, I have revised my plan, also incorporating the use of a second computer for the Backup Recovery process to minimise downtime of my main computer (i.e., the one needing its system disk replaced).

The two computers involved in the process are:

• VAL04, which is my main computer needing its system drive replaced
• VAL06, which is the computer being used only for the recovery of the VAL04 (system disk) backup to the new system disk (planned for VAL04).

The revised plan is as follows:

1. Connect VAL04 (‘Entire PC’) backup disk to VAL06 (via USB).
2. Connect new system disk (planned for VAL04) to VAL06 (via USB).
3. Boot VAL06 using Acronis Rescue Media (on USB flash drive).
4. In the Acronis Recovery Wizard:
   a) in step #9 ‘Select the items to recover.’, select the VAL04 old system disk
   b) in step #10 ‘Select Destination…’, select the new system disk planned for VAL04 and enable ‘Recover disk signature’
5. Once the Acronis Recovery is complete, shutdown VAL06 and disconnect all above disks from VAL06.
6. Shutdown VAL04.
7. In VAL04, replace old system disk with new system disk.
8. Boot VAL04.

Could you please advise whether this revised plan appears sufficiently safe and reliable?

Rodolofo,

Given your OP the MVP community took interest in your questions.  As a result testing has shown that your OP proposal will in fact produce the desired outcome of a bootable NEW disk without disk signature collision.  We thank you for your questioning prompting our deeper look.

Unlike previous releases of the True Image product there was no BETA testing period for the new True Image product.  As a result the only testing of the product was done internally by Acronis.  Had the MVP community been allowed to test the product prior to release we likely would have known that your proposed recovery was sound.

Since your OP proposal is the simplest of the two you have posted that plan should work for you.  One thing you need to know here is that GPT partitioning requires that a Microsoft Reserved Partition  (MSR) for short be included in the partition scheme.  Normally this partition is the second partition on disk and it is 16 MB in size.  If you are restoring your disk image to a larger disk, the recovery operation will move the MSR partition to the first partition position on disk and its size will increase to 128 MB.  This is expected behavior. 

You do not specify what your OS version is nor your OS disk partitioning scheme layout.  The information here assumes that you are using a Windows 10 + OS with a UEFI/GPT partitioning Scheme.  We DID NOT test an MBR/MBR scheme disk layout.

@Enchantech 
Thanks for clarifying. I must confess, I was confused. As I said to OP, I thought his original plan was workable and from what I knew (and have subsequently learned) about disk signatures and collisions, I was not clear why he was being advised his plan was problematic. 
So glad its clear now :)  Though I am still looking to understand how the hardware decides which hard drive to boot to. I presume its a somewhat dynamic process.. so even though it might store something like "last successful boot drive" info, if thats been removed.. it will look for what? an EFI partition? or what? So if you have two bootable drives in the system (i.e. 2 with a EFI partition), how does it decide which to boot to?.
 

Enchantech,

Thank you for your further feedback, which is very helpful.

System information is:

• OS: Windows 10
• BIOS Mode: UEFI (per Msinfo32)
• Disk Partition Style: GPT (per Disk Management)

Rodolfo,

Glad to here we assumed correctly.

Yoji,

For UEFI based systems an EFS or ESP partition is created on the Windows disk.  This partition contains the files necessary to boot the installed OS on the disk in this path: \EFI\Microsoft\Boot\Bootmgfw.efi

In Windows\System32\Boot are the EFI application files that is based on variables that are stored in NVRAM on the motherboard.  Windows boot loader uses these to boot the OS.

Look Here for more info on this aspect of the boot process.

Rodolfo Valerio wrote:

Thank you, everyone, for your helpful feedback, advice and informative links.

Based on this additional knowledge, I have revised my plan, also incorporating the use of a second computer for the Backup Recovery process to minimise downtime of my main computer (i.e., the one needing its system disk replaced).

The two computers involved in the process are:

• VAL04, which is my main computer needing its system drive replaced
• VAL06, which is the computer being used only for the recovery of the VAL04 (system disk) backup to the new system disk (planned for VAL04).

The revised plan is as follows:

1. Connect VAL04 (‘Entire PC’) backup disk to VAL06 (via USB).
2. Connect new system disk (planned for VAL04) to VAL06 (via USB).
3. Boot VAL06 using Acronis Rescue Media (on USB flash drive).
4. In the Acronis Recovery Wizard:
   a) in step #9 ‘Select the items to recover.’, select the VAL04 old system disk
   b) in step #10 ‘Select Destination…’, select the new system disk planned for VAL04 and enable ‘Recover disk signature’
5. Once the Acronis Recovery is complete, shutdown VAL06 and disconnect all above disks from VAL06.
6. Shutdown VAL04.
7. In VAL04, replace old system disk with new system disk.
8. Boot VAL04.

Could you please advise whether this revised plan appears sufficiently safe and reliable?

Personally needing to be extra cautious about this process, today I chose to test the recovery part (steps 1 to 5) of my revised plan (involving a second computer), as described above (previously posted on 'Fri, 09/20/2024 - 14:15'.  The recovery process succeeded, but there remains two issues which I still need to address:

1. New disk signature is different from old disk signature.  My original post included a concern about this, as follows:

'Addressing a different implication of disk signature replication, another forum comment suggests that disk signature replication is desirable, explaining that, if replacing the system disk (where applications are located), then it is important to retain the old disk signature as some software vendors use this for software registration, and consequently a change of disk signature might result in the software registration being no longer recognised.  If this is correct, then does this mean that disk signature replication is needed?'

Based on the above potential issue that may result due to a changed disk signature, my understanding is that I need to change the new disk signature so that it is the same as the old disk signature, and I understand that I can do this using the Windows Diskpart utility.  

I should also mention that the option to enable ‘Recover disk signature’ did not appear in my step 4b (step 10 of Acronis Recovery Wizard).

Could someone please comment on whether my understanding of both the issue and the solution are correct?

2. The size of the system volume on the new system disk is the same as that of the old system volume, and therefore the new system volume has to be 'Extended', to add the 'Unallocated' space located at the end of the disk, which is not contiguous to the system volume (partition).  When I attempt to do this in Disk Management, I am warned that 'The operation you selected will convert the selected basic disk(s) to dynamic disk(s).  If you convert the disk(s) to dynamic , you will not be able to start installed operating systems from any volume on the disk(s) (except the current boot volume). Are you sure you want to continue?'.  Therefore, I answered 'No'.

Could someone please advise me as to the recommended approach for overcoming this issue?

Your plan looks solid. I would NOT change the disk signature of the new disk to match the original disk. I have never done this. I would be very surprised if you encounter any software that relies on disk signature to continue to work.

New versions a Acronis software don't have the recover disk signature option. When you select the entire disk to recover, you will see a box to recover Track 0. You should leave that box checked.

You should download and install the free version of MiniTool Partition Wizard after you get the new disk working in VAL04. You can use it to add the unallocated space to your C: drive. Just Move the partitions after C: to the end of the disk. Then Resize the C: partition to fill the unallocated space. Your disk will remain basic and will not be converted to dynamic.

Mustang,

Thank you for your feedback on my plan, and for your advice on both the disk signature and partition management tools.

After using MiniTool on VAL06 to extend the new system disk (for VAL04), I conducted a test of booting VAL04 (where new disk planned for) with the new system disk connected externally by USB.  VAL04 booted normally and showed the new system disk (with the extended size) as the system disk. Everything appeared to be normal.

However, there then occurred two incidents which suggest that some additional steps might be required after I eventually replace the old system disk with the new one (internally in SATA slots).

Firstly, the Powerchute app (APC UPS software) displayed a warning regarding the absence of hibernation and the risk of losing unsaved data in the event of a forced system shutdown.  Unfortunately, I forgot to take a screenshot of the exact warning.  Might this warning be due to the absence of the file hiberfil.sys on the new disk, since the disk was recovered from an Acronis backup (which excludes this file)?

Secondly, I received an Acronis backup failure email, with an explanation included that '...Failed to create volume snapshot'.  This backup must have started automatically due to Acronis perceiving that the scheduled backup was overdue.  Based on the event times noted in the email, it appears that this error occured before I shutdown VAL04. Might this error also be due to the absence of the file hiberfil.sys on the new disk?

Could someone possibly advise me as to what additional steps I should complete after I replace the system disk?  For example, do I just need to turn hibernation on (using the powercfg command), or might there be more than that needed?

I think that I may have found an explanation why Hibernation was disabled when I tried booting the new VAL04 system disk via USB.  After booting, when I tried using the Powercfg command to enable Hibernation, there was an explanation that it was disabled by 'Windows to Go' (WtG).  Not being familiar with this, I did a web search, and found the Microsoft documentation, which lists features that WtG disables, one of which is Hibernation.  I do not understand why VAL04 booted into this restricted Wtg environment.  Is it because I booted from the new system disk via USB?  However, due to this experience, I abandoned this precautionary step of booting from the new system disk via USB, which I was going to use to do some additional testing of the new disk prior to physically replacing the old system disk in the SATA slot.  I then proceeded with the final step of physically replacing the system disk, which I will describe in a separate post to follow.

Just as a reminder, the two computers involved in my process are:

• VAL04, which is my main computer needing its system drive replaced (for larger size)
• VAL06, which is the computer being used for the recovery of the VAL04 (system disk) backup to the new system disk (planned for VAL04).  This second computer is being used as an extra precaution and to minimise downtime of VAL04.

The process I followed is as follows:

1. On VAL06, connect all disks (Acronis Rescue Media; VAL04 new system Disk; VAL04 Daily Backup disk)
2. Boot VAL06 from Rescue Media
3. On VAL06, recover VAL04 daily backup to new system disk:
   - in Recovery Wizard Summary step, under Options, select 'Recover files with their original security settings'
4. Once recovery complete, exit Acronis app, then exit CMD, and allow VAL06 to reboot normally
5. On VAL06, extend VAL04 new system disk system partition, using MiniTool Partition Wizard.
6. In VAL04, replace old system disk with new system disk.

The outcome of the above was that everything appeared to complete successfully, until I tried booting VAL04 with its new system disk (in SATA slot 0, where the old system disk had been).  VAL04 would get as far as the Windows logo but no further, and then would automatically attempt to reboot again with the same results and continue in this cycle repeatedly.

Consequently, I then replaced the new system disk with the old system disk, so that I have a system that is operational and until I can find a disk replacement process that works.

Could someone please advise me on where I might have gone wrong?  Did I possibly miss a step somewhere?

I don't think you did anything wrong or missed a step. I suspect Acronis assumed you were going to use the new disk in VAL06 and made an adjustment to the BCD file Windows boot from. Then when you putt the disk in VAL04 the BCD didn't match with the Windows partition. I don't know this for sure, but it make sense.

Let's try to do this in a much simpler method that will be very safe.

1. Boot VAL04 with the recovery media.

2. Make a new full disk backup of the existing Windows disk and store it on the USB drive with your other backups. Put the new backup in a empty folder so your existing daily backups are safe.

3. Shutdown VAL04 and remove the old Windows disk.

4. Install the new disk in the exact same location.

5. Be sure the new disk is initialized GPT with no partitions (all unallocated space).

6. Boot VAL04 with the recovery media.

7. Do a full disk recovery of the new backup to the new disk. Do the recovery exactly as you did above.

8. See if VAL04 boots to the new Windows disk.

9. If it does boot, use MiniTool PW to expand the C: drive.

If things don't work out, you can put the original Windows back in VAL04 and safely be back to normal.

Mustang,

Thank you for the suggestion.  It did appear from my last test that I may have more success by simplifying the process and eliminating the use of the other computer (i.e., VAL06), so I will try your suggestion once I can find sufficient time to test it carefully.

I do have one question about your suggestion, and that is to ask about the reason for your step #2 (i.e., taking a new backup instead of using my last daily backup).  Two reasons I had for using my last backup was to firstly test that I am able to successfully recover from my daily backups and secondly to minimise downtime of my main computer (i.e., VAL04) during this recovery process.  Could you possibly explain the reason for your step #2?

Step 2 may not be necessary. My thinking was based on not knowing how your daily backups are created. A simple full backup would by more straight forward to apply than a string of incremental or differential backups. There would be less chance of corruption within the backup. When you said you make daily backups it made me think they were probably incremental.

Mustang,

Thank you for the clarification.  My daily backups are incremental, so I now understand the reason for your step#2.

I have now successfully replaced the system disk in the computer (named ‘VAL04’), using the simpler approach (advised by Mustang, and by other forum members elsewhere in forum). 

Some modifications that I made to the suggested steps are underlined below, with explanations of my reasons for the modifications.

1. Ensure that new disk is initialized GPT with no partitions (all unallocated space).
2. Shutdown computer and remove the old Windows disk.
3. Install the new disk in the exact same location.
4. Boot computer from Acronis Rescue Media:
   - this media was created on another computer, as still getting error on this computer when creating Acronis Rescue Media, that it ‘cannot install driver iastorav.inf’).
5. Recover backup of old system disk, from the previous night’s (Incremental) 'Entire PC' Daily Backup, to new system disk:
   - rather than recovering from a new backup specially created for the recovery, I chose to first try recovering from my daily backup to confirm that it could successfully fulfill the purpose for which it was intended. If this did not work, I had also prepared a new 'Full' System disk backup as suggested.
   - while in Recovery Wizard, in Summary step, under Options, select 'Recover files with their original security settings'.
6. Boot computer (normally, from new system disk):
   - thorough testing of critical applications were all successful.
7. Use MiniTool Partition Wizard to expand the C: drive.

Although having used Acronis for backup for many years now, I have never recovered a system disk before this, and that was the reason for my excessive caution and earlier attempts at more unnecessarily complicated methods (that I described above).

Thank you to everyone for your patience in guiding me through this process so that I could benefit from your experience and knowledge.

I'm glad it worked out for you. It's nice that your daily incremental backup was successfully restore.