Backup practices, Macrium Reflect Free

Hello!

I would like to talk about best practices for backing up a home PC. I am using Macrium Reflect Free for full system images which I do monthly (always offline, with the Rescue boot USB) and I will soon start using FreeFileSync for weekly (or maybe even daily) data file backups. All my data + Windows 10 OS is on one internal SSD (Samsung nVME 960 EVO). I store the system images on an external (USB connected) HDD. For the FreeFileSync data file backups I'll be using an external (USB connected) SSD (nVME), because it's fast. I also copy the Macrium system image files to another HDD which I store at another location. I don't use any cloud services or any other forms of backup. So, I have 2 external HDDs with Macrium system (or rather full-disk) images and I'll soon have a nVME SSD with date file backups mirrored onto it. I would think that is quite sufficient?

Now on to questions. The first three were already discussed in the huge Macrium Reflect thread so I'll continue with those 3 first.

1. Rescue media. Am I getting it right that, the only difference creating rescue media of different PCs are the drivers off of the particular system/PC? So, which drivers - I'm guessing the disk drivers, USB drivers and NIC drivers? I only need the USB driver cause I backup to an external HDD via USB connection. What about the disk drivers? I have an internal Samsung nVME 960 EVO as my source drive. If I create the rescue media on my computer, will I be able to create and restore system images on another computer with a different drive, let's say a regular old HDD or an Intel SSD or nVME or whatever? And what if it has a different type USB make and driver? Will it still work with the Rescue USB made from the other PC? This is still pretty confusing to me although it was already explained in great detail in the other thread (thank you).

1.1 Another example: Let's say I have a PC with 64-bit capable CPU, but I have installed 32-bit Windows 7 OS on it. It's disk is a Samsung SSD, MBR partitioned. I have another PC, with 64-bit Windows 10 on it. It's disk is a regular old HDD but GPT partitioned. If I install Macrium Reflect Free on the first PC and create a Rescue USB with Windows 3.1 PE, will I be able to use that Rescue USB on the other PC, to create+restore system images? And vice-versa (creating a Rescue USB with Windows 10 PE on the Windows 10 x64 GPT PC and then using that Rescue USB with the Windows 7 x86 MBR PC)? Will it work, if not, why, where does it break?

2. I fist make a full disk system image and then do differential backups (until they become too big, then I delete all files and make a new full disk system image). When testing an image I only mount the latest differential image file, but that tests the first full disk system image too, right? I'm sorry, I don't know if I should name my images full system images or full disk images...

3. If I understand it right, the Macrium image verification only verifies the image file itself. The real test is mounting the image file and opening a data file off it, right? I really don't want to do a full system image recovery to another disk and then swap it with my internal disk for testing. Is that the ONLY way to truly test the system image?

4. This is how I go about my Macrium system (full-disk) image backups: with Reflect Free installed, I create a bootable Rescue ISO, I chose the Windows 10 PE Rescue media and then using Rufus I make a bootable Rescue USB (flash) drive. Then I use the USB Rescue drive to boot into it, then I start with a full system image to my external USB HDD and then I do monthly differential backups. I always do the Verify image when the backup is over (always only the most recent image file). And after that I always boot into Windows, mount the last (differential) image and open one a file off it. After that I consider the backup good and valid. Am I doing things right?

I think I've asked enough, for now... I'll really appreaciate if you guys comment on / answer (some) of my questions.

 

PS: 5. - I just created a 2nd differential image (...-02-02.mring) a couple of minutes ago on one of my PCs, but with clicking on the 1st differential image (...-01-01.mring) and creating a new one off it from there (please see the pic). Is that exactly the same as clicking on the full image that was made first (...-00-00.mring) and creating the new/latest differential from it? I think yes. So I can safely delete the old differential (...-01-01.mring) file and can recover my disk using only the "...-00-00.mring" and "...-02-02.mring" files, right?

https://i.imgur.com/VjMQNHd.png

Thanx.

 

1. Rescue Media contents. Assuming you use all of the same settings across all PCs (Base WIM selection, various options), then drivers will be the main difference. If you use BitLocker and enable the auto-unlock option, then Rescue Media built on different PCs will have different auto-unlock files, although you can always manually unlock partitions by opening Command Prompt in Rescue and using manage-bde. As for your specific driver questions, if you use WinPE 5 or newer, you don't have to worry about USB drivers because WinPE 5 and above have native support for USB 3.x. The only exception might be something like a PCIe to USB bridge controller as might be built into a Thunderbolt dock, but outside of those rare exceptions, USB drivers aren't an issue. At least until USB 4.0 arrives, where this might come up again. In terms of NVMe, that has been natively supported since WinPE 4. However, if your system has the Intel Rapid Storage controller enabled, which in the BIOS is sometimes called "RAID mode" or "Intel RST mode", then your Rescue Media might need drivers for that. Windows PE includes Intel RST drivers, with newer releases carrying newer versions, but if you have a system that's newer than the WinPE kernel you're using, then it might not have a suitable driver built in. Ethernet and WiFi drivers are similar story, in that Windows PE maintains a library of drivers built in, and they cover a wide range of hardware, but won't necessarily cover your specific hardware. If you want to avoid creating and maintaining separate Rescue Media for each PC, then your best course of action is to test boot a given Rescue Media build on all PCs of interest and see if all of the hardware you need it to see is visible. If not, then you might still be able to generate a "universal" Rescue Media build by taking the drivers from your various systems and copying them to the appropriate Drivers folder on one PC, in which case all future Rescue Media builds created on that PC will contain all of those drivers, even if they're not relevant to that specific PC.

1.1. Try to avoid Windows PE 3.1. It lacks support for USB 3.0, NVMe, UEFI boot, I think BitLocker, and probably some other stuff. Unless you find that you have a PC that simply will not boot a newer version of WinPE, then skip it. In fact I would go with WinPE 10 (or WinRE if you're running a Windows 10 system) as a starting point, then work backwards only if necessary, because that way you'll start with the broadest hardware support built-in. That can come especially in handy if you find yourself needing to migrate to a new PC unexpectedly. I've seen several reports on the Macrium forums of people whose PC died, so they got a new PC only to find that their Rescue Media build that worked fine on the old PC didn't work on the new PC's hardware -- because its old WinPE 3.1 kernel didn't know how to deal with any of the new PC's hardware. As to your other questions about the CPU architecture of Windows you have installed (32-bit vs. 64-bit) and MBR vs. GPT, none of that matters. Your Rescue Media doesn't care about what version of Windows is installed on the hard drive or even whether it's MBR (Legacy BIOS) or GPT (UEFI), since of course Rescue Media can work even if the hard drive is completely blank. The only things to be aware of are that a) you can't boot 64-bit Rescue Media on hardware that doesn't support 64-bit (although again, just having 32-bit Windows installed doesn't make a difference here), and b) if you intend to use Fix Boot Problems, you need to boot the Rescue Media in the same mode, i.e. Legacy BIOS or UEFI, that the Windows OS you're trying to fix would be booted. So if you have an MBR disk, you'd want to boot in Legacy BIOS, whereas with GPT you'd want to boot in UEFI mode. The reason is that the fixes attempted by Fix Boot Problems depends on how the Rescue Media itself was booted, and attempting UEFI-related fixes on a disk intended to be booted in Legacy BIOS mode is not likely to be helpful. But otherwise, there is absolutely no requirement that you use Rescue Media based on the same Windows kernel as the Windows version installed on that PC's hard drive. Doing that can sometimes allow Reflect to just copy necessary drivers right out of the host OS, whereas if you use some other kernel for Rescue Media then you might have to supply drivers manually, but on the other hand newer WinPE kernels often have more hardware support built-in to begin with, so going with a newer kernel (e.g. WinPE 10 even if you're running Windows 7) can often mean you don't need to supply drivers at all.

2. The simple act of mounting a Differential backup for browsing doesn't really "test" the Full backup. I mean yes, if the Full backup were missing, then Reflect likely wouldn't be able to mount the Diff (although I seem to remember Macrium adding an option whereby you could ask it to try to mount whatever it could in emergency situations), but just because an image mounts successfully doesn't necessarily mean the Full is perfectly fine -- or the Differential you actually selected, for that matter. It's entirely possible that part of either backup file might be corrupt or unreadable and you wouldn't notice until you tried to actually ACCESS certain specific data in the backup while it was mounted. If you want to test the condition of your backups, you'd need to run a full Verify operation on all backups in the chain. Verifying a Differential does NOT include verifying its parent Full, fyi. As for full system images vs. full disk images, the former isn't particularly well defined. It could mean an image of all partitions required to boot your system (although not necessarily data-only partitions you might have on that disk), or it could mean an image of all disks inside your system (a single image backup can optionally contain images of multiple sources disks). A full disk image would be an image of all partitions on a given disk.

3. Verifying a backup is a much better test than simply mounting an image and trying to read some random piece of data. As I explained just above, your ability to read some random file does not mean that everything ELSE in the backup will be readable. But since you asked this question, perhaps the more important question to ask YOU here is, what exactly are you trying to test here? And why exactly do you think that "just verifying the image file itself" is not a good test? The express purpose of a Verify operation is to confirm that all of the data in the backup is readable and that it has not been altered since the data was originally written into that backup file. If you want to test that the backup contains accurate copies of all of your source data, then there isn't really a good way to do that, especially when dealing with data that came fro ma Windows partition where things are constantly changing. But if you had an image of data that didn't frequently change, I suppose you could mount a backup and perform hash comparisons of data in the backup vs. data on the original source drive, but that would be tedious.

4. Your process is fine, although again I'm not sure what confidence you're trying to gain by just mounting a Differential backup and trying to read a random file -- but I've already delved into that above. As to the rest, why are you creating an ISO and then using Rufus rather than just having Rescue Media Builder create Rescue Media directly onto your flash drive? There's nothing WRONG with Rufus, and keeping an ISO of known good Rescue Media (in a location you'd be able to access if your PC was down) is absolutely a good practice in case a Reflect update breaks Rescue Media, but outside of a few specialized situations, I'm not sure why you'd want to use Rufus rather than Rescue Media Builder to create a Rescue Media flash drive. As for verification, I personally see very little value in doing that immediately after a backup is created, although rather than going into that here, I'll link you to this post of mine in the Macrium forums, which in turn links to two other threads that have more info on that. And lastly, I don't personally see much value in performing backups from the Rescue environment rather than within Windows (unless you really want to capture some data that VSS would purge from a snapshot?), but I recently had that discussion in the general "Macrium Reflect" thread on this forum, which I'm guessing you already saw, so if you still want to do it that way, then obviously it's your PC.

 

Yes. In fact, whenever you choose "Create Differential" or "Create Incremental", Reflect will always create the requested backup as a child of the newest "eligible" backup in the same set as the backup you selected, regardless of which backup you actually chose. When creating a Diff, the newest eligible backup will always be the Full because a Diff is always a direct child of a Full. There's no such thing as a Diff that is a child of another Diff (or an Inc). And if you were to choose "Create Incremental", then Reflect would create it from the latest backup in the set. So for example if you had a set consisting of a Full, a Diff, and an Inc, and then you selected the Diff and clicked "Create Incremental", the new Inc would be created as a child of the latest Inc, not the Diff you selected. Reflect does not allow you create a "forked" backup set, whereby your Diff would end up with two Incs as independent direct children. That could become very confusing to maintain anyway. Similarly, if you were to click "Create Incremental" on a Full, then once again Reflect would create the new Incremental as a child of the latest backup in that set, not as a direct child of the Full (unless the Full was the only backup in the set, of course). That said, you can certainly have multiple Diffs as independent direct children of a Full, but if you ever wanted to create an Inc, it would always be created as a child of the newest Diff in the set. You would NOT be able to create two Diffs and then switch back and forth between creating new Incs off each of those existing Diffs going forward, i.e. you can't create and maintain two separate "tracks" in your set simultaneously.

Fyi if you select any backup in the Restore tab and select Other Actions > Delete backup, the interface that pops up will show you all backups in that set, and if you choose to delete a given backup, any child backups that would be rendered unusable as a result of deleting the backup you selected will ALSO automatically be selected for deletion. This makes it very clear which backups depend on each other and helps you understand the ramifications of deleting a given backup. It also prevents you from ending up with "orphaned" backups taking up space, i.e. backups that are no longer usable because a required parent backup has been deleted. That's one reason it's preferable to delete backups from within Reflect rather than Windows Explorer.

 

Thank you both for replying. It's a lot of new info for me.

 

Useful to the rest of us as well. Thanks for raising this new topic. Great info.

@Peter2150 Wow! No idea you tripled up on images. That's real solid security prevention reliability.

Taking notes. No names.

 

My modus operandi with Macrium home edition v. 7.2.4601 [UEFI]:
I usually keep one full backup image of the last windows upgrade on 3 external USB hard drives and one full backup of Windows without any program installed.

As for my routine, one full backup weekly and daily incrementals, usually first thing in the morning (deleted at the end of the week) on 2 external USB hard drives.

After a Macrium update, I perform an incremental and a restore within windows to check its functionality. Macrium has never failed a restore in 4 years, although occasionally I backup with Windows' own program just in case. Sometimes I use Macrium as a time machine to test programs properly, especially if a reboot is required.

 

Hi,

I would like to ask for an opinion on a backup practice for a home user (me). I'm asking for my main desktop Windows 10 PC, which has a single NVMe SSD installed. At the moment I'm only doing a monthly full disk image (well, with Differential images) using Macrium Reflect Free. On to an external USB drive from which I then copy the big mrimg file(s) to the second USB drive I have on another location.

I will start doing disk image backups weekly, I think. My question is, what do you think, should I additionally start using FreeFileSync for a (weekly) mirror of only my data files? I can see that as an additional measure, in case Macrium somehow fails, meaning I can't recover my Macrium full disk image to boot or even manualy recover my data files off it. I always mount the latest image I create and then open a file or two, but that's not a thorugh test. So, what do you think, is FreeFileSync needed in my case or is Macrium Reflect Free enough?

I have a bonus question, it's a bit off topic. If any of you guys are familiar with the CCleaner's Wipe Free Space function - if I use it to wipe free space on a SSD that has Windows 10 on it, will I be able to recover previously deleted files off it (using a Deep Scan from Recuva for example)?

Thank you.

 

Most of us that use file replicators or synchers do so because we keep our important files OFF the OS volume (to keep the main OS partition small for imaging purposes). If your files are not within the OS partition, synching or replicating is a good practice, otherwise, Reflect's imaging should be more than adequate.

If Windows sees your NVMe disk as an SSD (and I believe it does), the TRIM function is active within Windows. That function will cause the SSD to completely wipe previous DATA when you delete a file... recovery should not be possible using any deep file recovery tool.

 

Thank you for your on point answers, I really appreciate it.

I have all my files, OS and data, on a single C partition, so I guess I should stick with Reflect imaging only. I hope Reflect never disappoints, haven't yet, so far. It's just the tought that the mrimg are huge files and if something goes wrong... I don't know, having the data files just plain copied (mirrored) on another drive seems less prone to problems to me... But I may be wrong thinking so?

About TRIM and file recovery... I've read about it and some people say you should zero fill the drive, some say you should wipe the SSD with the manufacturer's proprietary software, some use Parted Magic etc. You say that SSDs don't need any of that, that files that are deleted from the Recycle Bin should not be able to be recovered using, let's say, Recuva?

Again, thanks, and if anyone has anything to add, please do.

 

Following on from TRF's comments. I suggest resizing your C: partition smaller and then create a data partition. Move your non OS files into the data partition.

Then you can backup the OS and the data partition separately.

 

I had it arranged like that on my previous desktop PC, but found it impractical for other reasons. I'll keep it all on a single partition. If I'd go with the FreeFileSync, I'd just select certain folders to be mirrored to the backup drive... But I think I'll just stick with Reflect. It's hard to decide... Thank you.

 

That's what I'm saying. Zero filling an SSD is a waste. Things like Parted Magic have a function available called SECURE ERASE. It is a well defined modern disk command that does different things to different drive types. A SECURE ERASE issued to an SSD causes the SSD to erase every NAND block in its inventory... leaving you with a completely BLANK disk, ready for formatting. It's a little bit of an overkill but works very well. The Windows OS TRIM command is issued to the SSD following the de-allocation of Windows disk blocks which occurs during any kind of full DELETE operation. On the receipt of a TRIM command from the OS, SSDs usually perform one of three operations... it will either ZERO out, ONE out (the block gets filled with ones) or write RANDOM DATA within the block. This all depends mainly on the manufacturers NAND block design and the controller it uses with the SSD.

If you don't believe me, create some known files then delete them... making sure they have been deleted from the trash. Once this is done, in usually about 20-30 seconds max, try any data recovery tool you have... they'll all fail (unless Windows does not have TRIM enabled which some times happens under Windows 7 when just replacing your HDD with an SSD).

 

@ TheRollbackFrog: You seem pretty certain and I didn't know before that files couldn't be recovered off SSD drives (with TRIM enabled). I will make a test anyway, I will try it out because I want to experience it myself. Should it work that way if I attach a SSD as an external drive via USB and then create files on it, delete, wait a couple of minutes and then try a deep scan with Recuva?

@ Peter2150: So Macrium Reflect never ever failed you in any way? That's great to read. For a home user like me, your approach seems overkill. After all I've read on here, I think I've decided on only using Reflect Free with full disk + differential images of my whole disk. No FreeFileSync for data only files. I will keep on mounting and testing files after each backup.

I have yet another subquestion, reagariding Reflect's image Verify function which I always performed right after the image was done. So, is mounting a freshly created image and opening a file from it a proof that the image file is OK in aspect of the Verify function. Wow, what a sentence, I'm not a native English speaker, I'm sorry. I'm trying to say, if a file from a freshly done image opens up, does that mean that I don't have to do the Verify, because it will 100% show it's OK and it's just a waste of time?

Thank you, both.

 

TRIM is NOT SUPPORTED across the USB interface so I imagine that deleted files may still be available if you try and dig them out of deletion darkness. If this is done later than sooner, that space may have been reused by the FileSystem and the file may not be viable (same as doing the process on an HDD).

I'm not sure I completely agree with @Peter2150 on this (LOOK OUT... incoming!! ). In order for a mounted image to successfully mount, all that needs to be consistent is the main file structure ($MFT). When verifying a single file, the only thing that needs to be correct is the pieces of the main file structure that point to the location of the file, and the file content itself. This can easily be done with a mounted image even though the image may be in error... other files (their structure and content) may be flawed.

When you VERIFY an image, ALL the file DATA and their structures are CheckSummed and compared against a CheckSum that was created when those DATA blocks were originally written to the image. The CheckSum used is wide enough in its arithmetic value whereby a flaw in either the file structure or the DATA would be hard to miss. The IMAGE VERIFY is a much more definitive check of the files and their associated DATA content.

Pls remember... an IMAGE VERIFICATION immediately following the imaging process only tells you of the DATA integrity at that time. BIT ROT that may occur due to long term storage may affect the integrity of that image at a later time.

 

I probably should clarify this a bit. The newer USB3.x specifications not only handle faster bandwidth but they also support the UASP (USB Attached SCSI Protocol). With that as a given, TRIM is defined as a SATA interface command only so it is never issued across a UASP defined interface. There is a similar SCSI command called UNMAP which is supported across the SCSI protocol. These two commands are designed to do two different, but similar, things. What some (very few) manufacturers of USB docks have done in their dock design is to convert a SCSI UNMAP command to a SATA TRIM command and issue it to the docked SATA SSD... this allows TRIM to be performed on the attached SSD. This is a WORKAROUND, not a specification in any way... it's not defined in any spec.

Since I don't look into this very much, at this time the only dock manufacturer that supports this unspecced translation is StarTech... and only certain dock models. If you want to pursue this avenue, pls do your very due dilligence in finding out all you can about the dock in question.

 

TheRollbackFrog, thank you for replying.

 

It's the best method. Good advice ✔

 

Regardin the SSD erasure...
https://www.blancco.com/resources/wp-how-to-securely-erase-different-ssds/

Do we really need special tools to erase data off SSDs, your toughts?

 

No comment? I know I was off the topic but I'd like to know what you guys think (I think I already know for some of you but would like to read more than one take on it).

 

The same exact process is required to "cleanse" any storage element regardless of technology. The only difference is the tools needed to accomplish it. If you have an HDD, your choices are... drill (non-connected to the System) or DATA wiping (connected to the System). It's not quite as simple with an SSD. Physical destruction of an SSD most likely involves intense fire (burn those li'l chippies or pulverize them) or DATA wiping. With connected SSDs, DATA wiping is easy when using W07-W10 due to the availability of the OS' TRIM command. It's also easier when using any tool that supports the SECURE ERASE feature, which all the more modern storage elements support. With HDDs, the use of that command will have the HDD WRITE itself to death (internally... takes a li'l while), With SSDs the process is much simpler... the command causes the SSD to remove (or add... not sure) an internal voltage from every NAND storage chip in the device causing all the cells to fully ERASE themselves (the process usually takes 30-sec or so at the most). This, of course, is much simpler than using a standard DATA wiping tool that needs to pattern wipe the storage element in its entirety (as with HDDs) and also completely avoids the life reducing WRITE operations for SSDs. In the past, I have used the PARTED MAGIC CD/DVD/UFD stand alone LINUX environment which contains tools for erasing disks. I use the SECURE ERASE option to completely bomb out an SSD I plan to use for a new function.

By the way... HERE are some tools.

How private is that DATA anyway and does it really need destruction?

 

I know I'm dredging up an old thread, but I wanted to share my so far brief but pleasant experience with this product.

Mostly out of curiosity, and also as a possible second backup/restore solution to a paid product I'm currently using and have been using for several years, I installed this yesterday on my Windows 10 device and created a USB boot rescue media with it. This backup/restore solution, even though it's the limited free version, has easily exceeded my expectations.

As a quick test:

• First I created an image of my Windows 10 partition C drive from within Windows

• Then using the boot rescue disk, I restored.

The backup from within Windows and restore from within the rescue environment went smoothly and without a hitch. Both the backup and restore speeds were remarkably fast. Significantly faster than my current solution. I didn't record times but I would say at least twice as fast.

Honestly, for anyone with simple backup requirements who only backup occasionally without scheduling needs, such as myself, this is more than adequate from what I can see. I'm just quite simply astounded at how good this product is for free, and I found it to be intuitively easy enough to sort through the main program interface and options when creating the backup and restoring it later via the rescue media.

Is anyone here using the free version of Macrium Reflect? If so, what is your experience with it and are you satisfied with it? Any serious issues?

BTW, as per the tos please no A vs B comparisons.