Tesla1856
6 Thallium

Re: Migrating to m.2 NVMe


@jphughanwrote:

@Tesla1856wrote:

@kb1qzhwrote:

 

What's the right way to migrate to a m.2 NVMe drive?

 


If I had to pick just one, I would probably pick:
- Backup data-files
- Nuke-and-Pave (wipe all and clean-install). 
It sounds hard, but remember ... You would probably be done by now. 

https://www.dell.com/community/Alienware-General/Alienware-Aurora-R6-I-wanna-install-SSD-in-it-and-d...

Your cloning trouble could be:
- You are still using Acronis and not Macrium Reflect (free version does alot)
- You are trying to do a direct clone instead of verified Image file
- Temporarily turn off SecureBoot (or some other BIOS setting mis-match). The drives use different interfaces, protocols, and drivers (see my first paragraph). 

Maybe the real answer is "The way that works".   

 


Can't argue with the logic that a clean install might have been faster under the circumstances, but:

- Although I have not used Acronis, direct clone vs verified image file should not make a practical difference to the outcome other than requiring a temporary location to store the image file and more time since you're taking an extra step.  A "verified" image file simply means that the software confirmed that the data was copied from disk to image file correctly, but if you don't use an intermediate file in the first place because you're performing a direct clone, then there's nothing to verify there, and therefore NOT having this verification does not represent a shortcoming of the clone approach.  Plus the OP may not have an external drive on which to store an image file temporarily.

- Secure Boot has absolutely no effect when it comes to hardware-level issues like SSDs, SATA vs. NVMe, etc.  It only ensures that the software bootloader that the system attempts to start has been signed by a trusted authority -- and if Secure Boot is the culprit in that scenario, you get a message from the system (not a Windows Boot Manager error or BSOD) that specifically tells you that the boot failed because the bootloader wasn't signed.


I've found the Image file helps in a couple of ways. And if you are going to create it, it should be verified after creation (like, why would you not).

- If they end-up doing a clean-install after-all, and the old spinner HDD gets reformatted for use ... if days later they realize they missed a vital data-file, it's easy to find and restore it.

- I've seen issues where Windows won't run properly or allow the previous HDD/SSD to be completely re-purposed if it detects it has a working copy of Windows still installed on it. I've had to move it to another machine to remove all it's old partitions.

The deal with SecureBoot is that there are very-few authorized "Boot-Kits" (not to be confused with Root-Kits). CompuTrace and Macrium Reflect are some of the few.

Anyway, that's just my experience ... maybe I'm doing something wrong.


Registered Microsoft Partner and Apple Developer
- Gaming when I'm not programming.
- I answer questions here, but I'm not a Dell employee.
- Consider giving posts you like a "thumbs-up"
- Posting models-numbers and software versions speeds trouble-shooting.
- Click "Accept as Solution" button on any post that answers your question best.
0 Kudos
jphughan
5 Rhenium

Re: Migrating to m.2 NVMe

For Secure Boot, you’re right that there are very few signed bootloaders, but if you’re using Windows 8.1 newer or WinPE 4 or newer (Reflect Rescue runs on the latter, as do other similar tools), and I think even certain Linux distros now, then there’s no reason to disable it. Again, if Secure Boot is the problem, the system WILL tell you, unambiguously, that the boot was blocked by Secure Boot, so disabling it “just in case” is unnecessarily reducing your security. And if the environment you’re cloning or imaging and restoring boots under Secure Boot, there is absolutely no reason the clone/restore target won’t.

Yes, a disk image can be handy to have as a safety for data if the user intends to wipe the source disk, but that has nothing to do with successfully migrating from SATA to NVMe. Having image backups is a good practice in general, but it wouldn’t change the practical outcome compared to a clone in this case. Imaging vs. cloning also wouldn’t affect the ability to wipe the source disk later since both cloning and imaging leave that disk intact. But I’ve never, ever had a problem wiping a Windows disk using diskpart’s “clean” command unless it was a self-encrypting drive where that feature had been enabled, but that’s a special case. And if you want to delete individual partitions, the command is “delete partition override”.

Funny that you mention image verification since that actually came up in the Macrium forums recently and the developers provided some very illuminating information. I actually NEVER verify because it would cause my jobs to run longer than the allowable overnight backup window and I also have a disk rotation, so if one backup is bad, I’ll have a separate backup on another disk from within a day of the backup I originally tried. But more to the point, I don’t ever verify any other copies to/from my external hard drive either, so why should I expect my image backups will do worse? I guess you could say, “But an image file has all of your data in a single file and a single wrong bit could render everything useless,” — but a single messed up bit could do a lot of damage in a lot of other cases too. Macrium themselves say in their verification KB that the probability of verification failures when writing to disks is extremely low, so it just doesn’t seem worth the time especially if you have multiple backups that are independent (rather than just copies of existing backup files). But the Macrium forum discussion came up because someone asked why there isn’t an option to verify after a RESTORE. Turns out that the verification mechanism during backups works by copying data from the source disk into memory — this transfer is NOT verified! — and then comparing that in-memory value to what was written to the image. When a restore occurs, data is read from the image file into memory, then checksums are recalculated and verified against the image contents, and then data is written to the target — and that second part again is NOT verified. Turns out that verifying the data path between the internal disk and memory is non-trivial because of things like HDD caching, even if the time penalty to do so would be acceptable, and that penalty would be quite significant. Also, if you have problems there, you’d have all sorts of other problems with your PC during daily usage.

I’m not saying that everybody who verified their image backups is wasting time because there isn’t even any theoretical benefit, but it’s certainly not a matter of “Why would you not?” There are legitimate reasons why not and other ways to mitigate that risk. I’ll also point out that image verification was only added for Reflect V6, and if I had to guess, it was probably only to satisfy customer requests rather than because the developers suddenly decided after 5 previous major releases that it was especially important.
jphughan
5 Rhenium

Re: Migrating to m.2 NVMe

One further thought to the above. Verification still is no guarantee that the image is good later. The fact that it verified immediately after it was created does not mean that it will still be intact when you need to restore from it, since you can have disk or file system issues in the interim. That came up recently in the Macrium forums too, actually. But to mitigate that, you’d be talking about going back and re-verifying existing backups on a regular basis, and that’s just not practical for most people. So for me, verification addresses a risk that is extremely small to begin with, and it doesn’t provide any “long-term” assurances, so it’s simply not worth the extra time and disk wear and tear to perform, at least not when my daily Incremental backups are 100GB+. A disk rotation is much simpler and provides additional protections that verification even in its best case does not.
0 Kudos
kb1qzh
1 Copper

Re: Migrating to m.2 NVMe

i don't mind nuke and pave. didn't do much with the laptop outside of install steam.

SO do I get reinstall media from Dell and what's the cost?

0 Kudos
jphughan
5 Rhenium

Re: Migrating to m.2 NVMe

Even easier.  You can download Windows 10 directly from Microsoft for free at the link below, and it will include an application to make a bootable flash drive.  When you get to the point to choose where to install Windows 10, I would delete all existing partitions on your SSD (should appear as Disk 0, and you may need to click the More Options link to expose the Delete button) until it shows as completely unallocated space.  Then when you get it installed, you can try using Dell Command Update to automatically detect and download the necessary drivers and/or just go to support.dell.com and download them yourself for manual installation.  Good luck!

Link: https://www.microsoft.com/en-us/software-download/windows10

0 Kudos
Tesla1856
6 Thallium

Re: Migrating to m.2 NVMe


@jphughanwrote:
One further thought to the above. Verification still is no guarantee that the image is good later. 

Back in the days of Ghost, it was more important. Then my Acronis period, to an even less extent. Now, I use Macrium Reflect.

But that's why I verify ... habit and a little extra insurance.

I've been doing daily Differentials, and monthly Fulls (so only once-a-month do verifies take very long). Works real nice. Only thing I haven't quite figured out is how to get 60 day old Differentials to purge (delete themselves), so I just check every once-and-a-while and make some room. Most machines are only running the free version.

My Synology NAS has a back-up client, but this works so well, I dare not mess with it.

 


Registered Microsoft Partner and Apple Developer
- Gaming when I'm not programming.
- I answer questions here, but I'm not a Dell employee.
- Consider giving posts you like a "thumbs-up"
- Posting models-numbers and software versions speeds trouble-shooting.
- Click "Accept as Solution" button on any post that answers your question best.
0 Kudos
jphughan
5 Rhenium

Re: Migrating to m.2 NVMe

@Tesla1856, in terms of automatic Incremental deletion, there are only two ways that happens.  The more common is Incremental consolidation.  So for example if you choose to retain 60 days of Incrementals (or an equivalent number of backups if you set retention by number of backups, which I personally feel is safer since there's never any risk of purging all backups if it's been a while since you backed up), then any Incrementals older than 60 days SHOULD effectively be purged.  I say "effectively" because purging is actually achieved by merging the oldest 2 Incrementals together to avoid breaking the Incremental chain, but the end result is the same -- the oldest Incremental no longer exists in your set as a unique backup.  Note that when the Incremental retention policy is evaluated, it counts the total number of Incrementals among all of your matching backups, NOT just the ones built off the most recent Full.

If you don't want consolidation to occur, then your alternative option is to disable the Incremental retention policy entirely, in which case Incrementals will only ever be purged when their parent Full is purged -- but in your case that would have you losing a month's worth of Incrementals in one fell swoop.

If neither of those is achieving what you want, then maybe I'm not understanding your desired behavior.

0 Kudos
Tesla1856
6 Thallium

Re: Migrating to m.2 NVMe


@kb1qzhwrote:

i don't mind nuke and pave. didn't do much with the laptop outside of install steam.

SO do I get reinstall media from Dell and what's the cost?


As far as I know, none is available. That is why they make the ISO available for download.

Actually, Dell has never been able to send you a single image file, flash-drive, or disk(s) that would return the machine to exactly how you received it (in one easy step, for example). Never (not that I've ever seen). 

I think the present situation it's more Microsoft's doing than Dell's. 

So, you can make a perfect flash-drive of it now (either from Dell or Microsoft) and use that as the foundation of your install build-up.

After you get machine built-up all perfect-like, make a Image-File at that point and save it. You will thank-yourself one-day.

The serial-number is embedded in the motherboard. It will always Activate as legit.


Registered Microsoft Partner and Apple Developer
- Gaming when I'm not programming.
- I answer questions here, but I'm not a Dell employee.
- Consider giving posts you like a "thumbs-up"
- Posting models-numbers and software versions speeds trouble-shooting.
- Click "Accept as Solution" button on any post that answers your question best.
0 Kudos
Tesla1856
6 Thallium

Re: Migrating to m.2 NVMe


@jphughanwrote:

@Tesla1856, in terms of automatic Incremental deletion, there are only two ways that happens.  The more common is Incremental consolidation.  So for example if you choose to retain 60 days of Incrementals (or an equivalent number of backups if you set retention by number of backups, which I personally feel is safer since there's never any risk of purging all backups if it's been a while since you backed up), then any Incrementals older than 60 days SHOULD effectively be purged.  I say "effectively" because purging is actually achieved by merging the oldest 2 Incrementals together to avoid breaking the Incremental chain, but the end result is the same -- the oldest Incremental no longer exists in your set as a unique backup.  Note that when the Incremental retention policy is evaluated, it counts the total number of Incrementals among all of your matching backups, NOT just the ones built off the most recent Full.

If you don't want consolidation to occur, then your alternative option is to disable the Incremental retention policy entirely, in which case Incrementals will only ever be purged when their parent Full is purged -- but in your case that would have you losing a month's worth of Incrementals in one fell swoop.

If neither of those is achieving what you want, then maybe I'm not understanding your desired behavior.


That's some good info.

No, I hate the idea of Incremental consolidation. The only Full-backups I would dare depend on is one I created naively and was verified back then (31 to 1 days ago).

So, I just want about 60 days of Differentials left on the drive at any time. Something similar with monthly Fulls (about 2) if possible ... but it's no big deal to check on it about 6 times a year and manually delete the old ones.

I guess I just need to drop by their forums and ask.

 


Registered Microsoft Partner and Apple Developer
- Gaming when I'm not programming.
- I answer questions here, but I'm not a Dell employee.
- Consider giving posts you like a "thumbs-up"
- Posting models-numbers and software versions speeds trouble-shooting.
- Click "Accept as Solution" button on any post that answers your question best.
0 Kudos
jphughan
5 Rhenium

Re: Migrating to m.2 NVMe

@Tesla1856I'm very active over on the Macrium forums under the same name if you pop over there.  Also note that Incremental consolidation does NOT mean you have to modify the Full.  You can just have Incrementals consolidating into each other rather than consolidating into the Full; the latter is called creating a Synthetic Full.  I've actually been using Synthetic Fulls for over a year on those daily 100GB+ Incrementals and it has worked absolutely flawlessly.  Believe me, the idea of modifying existing backups via consolidation made me worry a bit at first too, but I checked with the (very responsive!) Macrium developers extensively first to learn how it worked, and they explained it thoroughly.  Basically they've designed it so that no consolidation failure at any point for any reason can ever damage an existing backup or result in data loss, because the file being consolidated in preparation for purging isn't purged until the operation is done, and the file it's being consolidated INTO has all of the new data added to "scratch space" within the file, and that new data doesn't get "blessed" until the consolidation operation completes -- so basically even if you disconnect your destination drive in the middle of the consolidation, all of your original backup data will still be intact and Reflect will sort out the mess during the next consolidation operation.

Among the perks of Synthetic Fulls are that it is the most storage-efficient strategy to store a given length of backup history because you only ever have one Full and no Diffs, which minimizes data redundancy in your set.  It's also the only strategy where you can always have an EXACT amount of history rather than a range.  In typical GFS strategies, for example, on a day where you capture a Full, you get a backup to cover one new day, but you might lose a week or month's worth of backups as a result of purging the oldest Full and its child backups -- hence, you have a variable backup history.  That doesn't happen with Synthetic Fulls.  And since we've been talking about verification, forcing Reflect to go back and work with the Full in order to perform consolidation operations actually has its benefits.  Remember that guy I mentioned earlier who found that his previously verified Full was subsequently damaged?  He learned about that because his Synthetic Full consolidations started failing!  Had he not been doing that, he would have gone on building new Incrementals completely unaware that they were all useless because they all all depended on a busted Full.

But if you're still not persuaded to experiment with Incremental merge or Synthetic Fulls, then there simply isn't a way to just delete only Incrementals that are older than 60 days, for the simple reason that it isn't possible to simply delete Incrementals, because the nature of Incremental backups means that doing so would invalidate every subsequent Incremental in the chain.  That's the whole reason consolidation exists -- to give you a way to purge individual old Incrementals WITHOUT breaking your chain.  But if you don't want to do that, your only option would be to have all Incrementals deleted in one fell swoop when deleting the parent Full -- again, just disable your Incremental retention policy and choose to keep your Fulls for 3 months.  That way, when the Full that's 3 months old gets deleted, all of its child Incrementals get deleted as well, leaving you with a Full that's 2 months old and all of its Incrementals, and therefore Incrementals going back at least 2 months -- although because you'll be purging Incrementals a month at a time, you have to have the storage capacity to retain Incrementals for up to 3 months.  If you wanted to never have Incrementals older than 2 months in your set AND never consolidate anything, then you'd have to be willing to accept that at some points in the month, you'll only have Incrementals going back for 1 month.  Again, if you were using consolidation, you would be able to always retain exactly 2 months of Incrementals.