IMHO thats way too nerdy. Think you could sell all that to a fee paying client who simply wants a simple system/apps back up method?
No, it's the exact opposite of nerdy. Nerdy is when you have to ensure enough available free space on a separate partition or drive because else your image file won't be able to fit on the drive. My laptop has only one internal SSD. I have a whole bunch of 3.5 inch 7200rpm HDDs in external USB3 enclosures, but they are slow like molasses when compared to the NVMe SSD. I have a separate D: partition on my SSD, but there's usually not enough available free space on that one. So, being unable to choose a destination folder that is located on the C: partition itself is one of the main reasons why I don't use Macrium. If you try to do that with it, then it throws a nerdy error message because that's just how stupid the program factually is. I know I have said this probably more than a dozen times in other threads on here and elsewhere, and, as much as I hate to sound like a broken record when it comes to Macrium, it is what it is, and soon it will be no longer free to use, anyway so...
Another good reason why I prefer the method that I use is that the UI of the Rescue Media bootable ISO is waa-aaaa-aaaaaaay less nerdy than Macrium. It's all about keeping things as simple convenient as possible. Keeping a habit of storing ALL personal user files ALWAYS on a separate partition or drive is way too nerdy even for me so, some of my files are on my C: partition, sometimes only temporarily. For reasons that should be completely obvious, these types of files should never be included in the image file. As a result the easy ability to specify file/folder exclusions is a must have. With Macrium, the only way to achieve that ability is by editing the Windows registry. Just because I am a nerd who knows how to do that, doesn't also mean that I want to do that, as there already exists an alternative solution to this, the latter solution being the least nerdy by a mile or two (or three or four or five). If you still don't know which solution
that might be, then take a wild guess. I could go on like this. But would it help? I told you in that other thread that I have patience. But I don't do bottomless pits. That's all part of me being a pragmatist, as opposed to just being a nerd or acting like one. Not trying to point any fingers here. You got the picture.
A parallel system/apps clone of C: onto internal D: drive seems entirely sensible and simple. How long it takes to do the iso img isnt relevant as its only done occasionaly when a significant change is made (new app added etc)
You are still confusing image create/restore strategies with cloning. Cloning uses no image file excepting only in situations where the cloned volume(s) is/are virtualized (like on a VM). Cloning causes the contents of one volume to be duplicated onto another volume, and the contents of the volume can be much more than just folders and files. Whereas the purpose of creating an image file─as for what we are discussing here─is to capture the contents of a volume into a file, and this file can be stored, just like any other file, on a volume that has a filesystem on it (e.g., the NTFS filesystem). Further, I already told you that the ISO file format is not intended for what we are discussing here. Other image file formats are.
It can be tested by alternately manual startup booting up to C:/D: (I used to do this on a W7 m/c to go into Linux). To repeat personal data/work files I can manage myself and keep on an ext usb drive
What is wrong with this philosophy - pls dont get nerdy again its wasted on me
What's wrong with it is that the test method that you describe does not let you detect all inconsistencies or errors that may result from cloning, even if these erros happen only very rarely. Just because you are capable to boot in Windows, use it to run your apps, go through various settings to see if they are still the same as they were before, etc. does not give you any guarantees beyond that which you are capable to see. I brought up the subject of real forensic tools like FTKImager only to make this clear. It's because, without delving into advanced subtopics like trusted methods for data verification and things like the use of MD5 hash codes in image verification type of strategies, it isn't a matter of whether people will pitfall. Rather, it is a matter of WHEN they will pitfall. Please do some of your own research instead of trying to blame me for getting nerdy. I have given you enough basic info to make it possible for you to start experimenting on your own, with my preferred method to create/restore image files. This isn't exactly rocket science, but I am here to help should you have any further questions.
