Thanks for the explanation. After some more research I decided not to install CBT with v8 Home. I don’t think It would be that useful to me.
I made the same decision. It's most valuable when you're making very frequent backups and/or when backing up volumes containing a lot of large files, such as database files or VM virtual disk files. But I'm not doing either of those things, and CBT since its introduction has received a large number of updates to address bugs or adverse behavior (sometimes with other applications), so I decided that the benefits simply weren't worth the drawbacks for me. That decision may have saved me from some BSODs, and I'm sure it's saved me from many occasions where I would otherwise have had to reboot after a Reflect update. CBT works as a driver and therefore updates will require a reboot for the changes to take effect, but if CBT isn't installed, then it doesn't need an update and therefore a reboot isn't required to complete the Reflect update -- unless there's an Image Guardian update, since that also runs as a driver now too, but that hasn't been updated nearly as much.
There's a very good KB article about it here, but basically Image Guardian is designed to allow only Macrium applications (and by default Robocopy, under certain conditions) to modify or delete Reflect backups. All other applications, including the actual user using Windows Explorer, are blocked from modifying or deleting Reflect backups while it's enabled. It is not possible to allow other applications. This design is obviously less flexible, but also allows better security. Typical anti-malware solutions try to protect all sorts of files against all sorts of threats, but also has to allow all sorts of OTHER applications to operate without interfering with their legitimate activity. That's difficult, and the typical design in that case is to use some combination of definition files and heuristics to identify malicious applications, and allow anything that doesn't seem suspicious. That is known as a "blacklist" approach. But that can lead to both false positives (blocking legitimate activity) and false negatives (allowing malicious activity). But Image Guardian doesn't have to do this, because it is focused ONLY on protecting Reflect backup files, and those will ONLY ever be legitimately modified or deleted by Macrium applications (except for manual user activity and sometimes Robocopy). And as a result, Image Guardian can afford to take the safer "whitelist" approach by saying that Macrium applications are trusted, and everything else is not trusted.
thanks it has some protective logic then. If I buy I'll get lifetime license but 12 months Essentials Support if I understand correctly
Are you talking about Reflect Home? If so, yes the license to use the software will be perpetual, so it will work forever (or as long as you keep using a Windows version that it works with). It’s only the support that expires, and on Home it cannot be renewed. The business editions work a little bit differently.
Question about Rapid Delta Restore. Are there any times when it would not be reliable? For example, if your HDD/SSD was corrupted by a power outage or a virus, would it still work?
RDR was introduced for Reflect V6, and I haven’t seen any updates to fix bugs related to RDR doing something incorrectly. I’ve seen a small number of posts on the Macrium forum from people who claimed that their system behaved differently after an RDR restore compared to a non-RDR restore, but they weren’t controlled tests with good information reporting, so it’s unclear whether RDR was the meaningful variable. Given that Macrium has a customer base in the millions, I would expect that if RDR was prone to restoring incorrectly, it would have been discovered and fixed by now.
I can easily see where power failures could leave the disk corrupt (unfinished sector write, incomplete MetaData update, etc). If you feel that may have happened (usually due to power failures or machine component failures), when doing the restoration just unCHECK RDR and REFLECT will do a "standard" image restore (as though the disk was blank to begin with) and restore everything. It will take longer (like other imagers on the market) but will be a complete image restore.
^ NTFS has mitigations built into its design for that sort of thing, and RDR does work with the current state of the file system to figure out what changes need to be made in RDR. So I wouldn’t think that a scenario like that would render RDR unreliable. But one scenario that did occur to me was making changes to an NTFS partition using a mechanism that doesn’t comply with the NTFS spec and therefore might not update the file system properly. This came up in the context of CBT in this thread, where it was discovered that CBT did not correctly identify all changed sectors when the volume had been modified by Linux Mint. Macrium’s analysis and response, as quoted by the OP of that thread, is on Page 2. But I suppose RDR could potentially be vulnerable to that sort of issue where it might not “undo” a change that should have been undone as part of a rollback.
That’s interesting. Is it possible that malware could make changes to an NTFS partition that don’t comply with the NTFS spec?
I can't speak confidently about that. I think I understand the threat model you're envisioning -- malware that wouldn't be removed by an image restore that used RDR? -- but I'm not sure if it would be feasible to put a malicious EXE on an NTFS volume and configure it to run in the background all without updating the file system to indicate that any changes had been made. I'd be surprised if something like that was possible. Maybe if you were replacing the contents of a file that already existed in the file system and was already configured to start? That seems less difficult than somehow creating a whole new file on the volume without updating the file system. But I really don't know if even that would be possible since I just don't know file systems at that level of depth. However, it seems unlikely that it would be possible for malware to do something like this while running within Windows with Microsoft's own NTFS driver. The thread I linked above pertained to Linux Mint, which uses its own NTFS driver that apparently had a bug of some kind.
In the first case, each backup set can individually have 4 diffs and 10 inc images, and in the second case, all the backup sets together can have 4 diffs and 10 inc images, right?
^ No. The retention policy counts always count across all backups within scope of the retention policy. In the first case, it would count across all matching backups. In the second, it would count across all backups. There is no way to specify “per-set” Diff and Incremental retention policies. But in the second setup, if you had backups that came from completely unrelated jobs containing completely different data all stored in the same folder, then the retention policy would purge those completely unrelated backups. That second setup can actually be useful when making image backups of Windows 10 systems though, since the fact that feature updates sometimes alter your partition map can cause even the SAME backup job to start producing sets that no longer “match” the pre-update backups. In that scenario, the FIRST setup would cause the retention policy to stop applying to pre-update backups. The second setup avoids that issue, but you should of course make sure that your destination folder ONLY contains backups created by that job. More info on that here.
Question about definition files. Can they be used indefinitely, or do they have to be recreated every so often to keep them current?
As long as you continue to use the defined backup sequence, they are indefinite. When you want to "tweak" them for some reason, they are editable. And when I wanted to use an exact definition with minor changes (do the same thing without retention, lets say), I use the <right-click> DUPLICATE function, rename it for clarity, then use the EDIT capability to make the minor changes.
^ This. A definition file is just a way to store the settings for a backup job that you selected when stepping through the wizard, so that you don't have to keep going through the wizard and specifying those settings again every single time you want to run a backup. As long as those settings remain valid, i.e. the disks/partitions selected in an image backup job still exist and/or the folders you selected in a File & Folder job still exist, then the definition file remains valid. And if something changes, e.g. the Disk ID of one of your source disks, or the path to a source folder in your F&F backup, or the path to the destination for your backups, then edit as needed.
If password $PROMPT$ is set, at what step of the backup should the password prompt appear? It doesn't show up for me. In Reflect, the Auto Restore function is triggered by the Ctrl+Shift+S hotkeys. The same keys are assigned in my other program to take a screenshot. This is the first time I have seen both programs triggered simultaneously by the hotkeys and the Auto Restore window opens and a screenshot is taken. Is it supposed to be like that?
^ Looks like you’re editing the DEFAULT settings there. Make sure $PROMPT$ is set for the definition file you’re actually running. Also make sure you’re not running it as a background scheduled task. If memory serves, $PROMPT$ only works for backups launched interactively since scheduled backups are intended to run without interaction. But reading Reflect’s online user guide might confirm that. Also make sure you’re running a Full. I don’t think you can change a password setting mid-set. If you do, new backups added to an existing set will use that set’s existing setting instead.
When doing a Rapid Delta Restore, is there a simple way to see how much data was restored? It would be good to know the actual data savings vs a full image restore.
Well, one simple approach would be to run a timeline for a day or two, then do a differential. If you then restore to the original full baseline (with RDR), only the amount of the differential would be restored rather than the entire baseline plus the diff. With Many Incrementals involved in the image chain, it's difficult to determine the actual changes involved.
The size of the differential would tell you the amount of data that should be restored. I was wondering if there was an easy way to see the amount of data that was actually restored. Like, is it reported in a log somewhere?
No, I have not seen anywhere that Reflect records the amount of data actually written to the target in a restore operation.
WinterKnight, You can use CrystalDiskInfo to check Total Host Writes to the SSD before and after restoring the image. It's only accurate to 1 GB but that should give you an indication of what's happening. Years ago I recall using an app that was more accurate but I've forgotten its name.
The forgotten app was Intel Toolbox. But only for Intel SSDs. It used to measure in 0.1 GB increments. I recall some OS restores only wrote 200 MB.
