You're right. I guess my saying "need to" was overkill. Reflect could continue the existing backup set picking up all incremental changes since the last known good incremental after the questionable ones have been removed. In the circumstances, however, starting a new fresh set with a new full backup would be what I would do myself, whether over-cautious or not. Nothing is lost in doing that except the extra (background operation) time required. The Reflect user interface allows you to select any backup image of any type for removal. (Select it under the Restore tab and then select Delete under Other Actions.) Reflect then automatically removes other dependent images as necessary to maintain integrity of that backup set. That may mean all subsequent differentials and incrementals if you select a full backup for removal, or all subsequent incrementals if you select a differential for removal. Windows Explorer will just delete whatever you tell it to as usual* without any regard for Reflect backup set integrity requirements about which it knows nothing at all. __ * -- Assuming, of course, that its modify/delete access to the selected backup file(s) hasn't been blocked by the Reflect v7.1 "MIG" feature or by some other "protected folder" utility. Neither removal of those questionable incrementals nor creation of a new full backup will alter or affect Reflects regular "housekeeping" in any way. It will continue as before retaining the number of fulls, diffs and incs as specified in your retention settings. Creating a new full backup is entirely up to you. (See above reply to minimalist.) However, it will do nothing out of the ordinary if you do. I'm not sure exactly what you mean by "lumped together" in a "jumbled mix". You may want to review the Macrium KB article regarding How backup sets are created and maintained.
You're welcome. It is quite understandable that some of Reflect's backup set management features and the wide range of related user selectable options may make it all seem more complicated and mysterious than it really is. Don't hesitate to ask for further clarification if needed.
In general, after a successful restore would you always start fresh with a new full backup, or are there any situations where you would continue with a current backup set? I use Macrium Reflect free, so for me this only applies to differential backups.
I might in some circumstances depending on image retention and consolidation settings. In this case, where retention rules had been set for a full backup to be followed by 30 days of incrementals (no diffs mentioned) and where some questionable incrementals were being removed, it just seemed (to me) sensible to make it a "break point" for initiating a new cycle under those rules. But I also agree as Minimalist and others pointed out that it isn't absolutely necessary to do that. Reflect is able to handle continuation of incrementals in the same backup set without any such break if the individual prefers that. It will "recycle" itself anyhow whenever the numbers add up to what the set retention rules specify. Each and every differential always captures all changes since the most recent full backup so that incremental 'chain link' vulnerability isn't a factor in that case.
I have another strange one on my incremental backup.V6 paid. I have incremental set to daily, and full to weekly, but every 2 weeks. Yet it is doing the full every week. What am I doing wrong?
I wonder if you have the full set to "keep 1 week" and it's forced to create a new full before it can do an incremental on day 8. Just thinking out loud.
Would it be possible for you to post screenshots of Reflect's settings (retention rules and scheduler entries) for that backup task definition? Obviously, one or the other (maybe both) is being misinterpreted somehow during the operational process. It may, perhaps, have something to do with order-of-precedence handling by the MacriumService. Between that and some W10 updates, there were a few reported 'quirks' at some points in Macrium's changeover to using the Windows Task Scheduler v2 API. What are your current Windows and Reflect versions? Mixing numeric and time-based retention limits can also be a bit tricky in some situations. __ Edit: Oops. My apologies. I see now that you're using Reflect v6 in which case its still on the WTS v1 API. So the other possibilities are more likely, although it too required some mods to handle some W10 updates.
Looks all correct to me based on what results you've said you want and, when I create a similar task definition, it does put the appropriate entries into my Windows 10 v1709 Task Scheduler. I'm left with only the possibility (just guessing really) that the behaviour that you've seen is most likely attributable to some misapplication of the mixed numeric and time-based retention rules. You could try changing either of them so that both full backup and incremental backup retentions are specified as one or the other -- i.e., either time-based or numeric. I'd recommend the latter.
If anything, if available space isn't too tight, you might want to go "overboard" on your incremental retention limit and rely mainly on the full retention limit to handle "housekeeping" for the associated incremental chains.
Might try that, but I will first see now if the full backup executes fortnightly as defined, instead of weekly.
Sounds like a good "logical troubleshooting" approach. The primary key to all Reflect behaviour is knowing that it will always default to creating a new full backup if, for any reason at all, it can't create a differential or incremental backup as requested.
I have a question about swapping backup drives and if it affects your ability to continue backup sets. If I made a full backup on external hard drive 1 and then swapped disks and made a second full backup on external hard drive 2, could I then go back to external hard drive 1 and make a differential backup?
Sure. In fact, depending on whether the drives will be available simultaneously, you may be able to take advantage of the ability to specify alternative destinations within your backup task definition. See this KB article. In each case, differential backups will be based on the most recent full backup found in that location. You may also want to note the ability to use volume identifiers for drive discovery. See this KB article.
Is it safe to upgrade to V7 yet? I like the idea of the backup files being protected from viruses and ransom-ware etc but am not sure if the bugs have been worked out of the recent (paid) version yet. Thanks in advance.
Well, it's been over a month now and, so far so good, on both my machines, so uninstalling prior to upgrading may have solved my (admittedly rather minor) problem. Thank you again. Edit: Three hours later, it happened again: a BSOD followed by a reboot and a successful full backup. I guess I'll now try Arvy's other suggestion, to recreate the relevant task scheduler.
I suppose it depends on each person's definition of "safe". I've been running it on one of my Windows set-ups since the W10 v1709 release without any serious problems. However, I don't install the Reflect v7.1 optional "CBT" and "MIG" components as I don't run multiple incremental backups within a single Windows session (which is CBT's only advantage) and I find other means for providing anti-malware protection superior to MIG's very limited scope. As for residual current issues, it has been confirmed by Macrium that rescue media created with the latest Reflect v7.1.2646 release "isn't behaving as it should when prompting for network credentials" and a "fix in a future update" has been promised. We can only hope that fix comes sooner than the promised update to the more recent WinPE v1703 or v1709 WAIKs. In the meantime, users may experience access problems while booted to Reflect's rescue media when attempting to recover backup images that are located on network shares.
