Macrium Reflect

Sure. I will up the retention no. of full backups so I don't lose the old ones .

 

Just a suggestion, but you might also want to give your new backup task definition (XML file) a new name different from the old one. That way, if you wanted to, you could "diff" compare the two XML files to see exactly what changes were made. In any case, you'll also want to re-check your task scheduler entries to ensure that they're set to use the new task definition and only the new task definition. If using the GFS plan template, there will be three of them. Don't worry about overlapping datetimes amongst the fulls, diffs and incs. Reflect's order of precedence handling will sort that out.

 

I went through this exercise, but I am increasingly convinced all my backups (full, diff, and inc) are disk backups, but strangely, for some reason in each case, the last (redundant) 11.92 GB Lenovo Recovery partition is unticked.

I plan to remove this anyway with @Brian K's help, so will revisit this afterwards, and then redefine all the backups.

 

Your supposition about the existing backup task definitions is quite likely to be correct. At the time they were created, they very probably did include everything on the drive in accordance with its partitioning layout at that time. As I mentioned above, however, Reflect's backup task definitions specify numerically which partitions are to be included so that any changes to a drive's layout (such as adding, deleting or moving partitions) can invalidate those numerical specifications for all backup operations thereafter.

Recreating your backup task definitions (and related task scheduler entries) as suggested will ensure that they are consistent with your current drive layout.

__
P.S.: In fairness to Macrium, I should add that none of that implies any fault or deficiency in the Reflect application. That's just the way it works and there are very good and sound reasons for its reliance on numerical ordering of partitions when backup task definitions are created or updated.

 

v7.1.2646 Home Edition is not able to restore from an ReFS partition. I backed up my system partition to an external USB hard disk formatted in ReFS v3.3, and MR wasn't able to read from that backup partition. I'm back to Drive Snapshot, which has read and write access to ReFS disks.

 

Maybe it's because you did not make the MR PE under Windows 10 v1709? Do that and MR should be able to read from ReFS. The file system support should be provided by the PE itself, not MR, as I understand it. I might be wrong but it's worth a shot.

 

AFAIK, Macrium's WinPE is still based on 1607.

 

No wonder. In this case, best way to do it is to create a PE under Win10 v1709, and run MR as a portable app on it. Or, use Win10PESE (and use Windows 10 v1709 as source to build it) to run MR as a portable app.

ReFS is not mature enough yet for home use - too much hassle.

 

Yes, thanks @Arvy, the numerical ordering does explain everything. I will redefine all my tasks after further cleanup.

 

@paulderdash -- You're welcome. I can certainly understand that not all of those task definition particulars nor all of their consequences are obvious.

Very good advice. The WinPESE project has been updated recently for use with Windown 10 v1709. However, using that install.wim version to get ReFS compatibility could be tricky as MS is removing ReFS support from some editions, presumably including some of the install.wim index numbers. The Workstation Pro edition should be okay, but I haven't actually tried it yet myself and so can't confirm from direct experience. Can you?

 

Reflect WinPE Network Issues: User may experience access problems while booted to Reflect's rescue media when attempting to recover backup images that are located on network shares. It has been confirmed by Macrium that rescue media built with the current Reflect v7.1.2646 version "isn't behaving as it should when prompting for network credentials" and a "fix in a future update" is promised.

We can only hope it comes sooner than the promised update to WinPE v1709, or even WinPE v1703 for that matter.

 

Not sure. I haven't used MR for a long time. But as I understand it as long as the ISO contains either Enterprise or Pro WS version, the PE should contain the packages for ReFS. But this is just my speculation. Wait for someone to test it.

 

Okay, thanks oliverjia. I was mostly just curious as I don't actually use ReFS. Maybe I can test it myself using the install.wim index for the Pro edition when I get around to re-building with Win10 v1709 and the latest Win10PESE project download. As I understand the most recent MS moves, the current Windows Pro edition should still be able use an existing ReFS set-up, but may not be able to create one itself.

 

Been using MR for a few months and am very satisfied with the program. The few restores I've needed to do have always been within a 24 hour period so have only needed the latest incremental. Today was different. I needed to use the incremental from 4 days ago to correct a problem. Restore worked fine and all is well. After browsing the most current backup from this morning and replacing documents etc. that were missing, I am now wondering what to do with the intervening incrementals. My problems are somewhere within those 4 backups. Will it impact the chain in any way if I delete them? Will it impact future backups if I leave them?
My setup is simple - 1 FULL then daily incrementals - retained for 30 days - then oldest one is eliminated. In a month they will automatically go away but don't want them to pollute the future daily backups.

 

@jopa66 -- Having mounted the most recent incremental backup and having used it for recovering up-to-date versions of individual user data files (documents, images, etc.) that you know are okay, it would then be best to remove the questionable members of that existing backup set after the last known good incremental that you restored. You'll then need to start a fresh new series with a new full backup image of your fully restored set-up. Provided that you use Reflect's user interface to remove those questionable incrementals, it will maintain the integrity of both the old and the new backup sets.

 

Is new full backup necessary? I've been in similar situation in past and just continued previous chain with no problems.

 

@Arvy I kinda understand that with incremental backups.

But would the same be true of differential backups? Also, is it safe to delete redundant diff backups through Explorer?

Edit: Can someone just confirm how 'you use Reflect's user interface' to delete backups?

 

minimalist, it's not.

depending on how many incrementals you have allowed in your settings, the oldest incremental may get consolidated into the next recent, and eventually get consolidated with one of the 4 you did not want.

if these 4 days of incrementals are useless to you, you can delete them thru the user interface and thus carry on from the last known good one.

you can keep them, and the next incremental added on the end will then be your new last known good if the earlier one gets consolidated. depends on your own whim.

as i've mentioned before i set it to keep two 'chains', and six incrementals. i do a full every friday night and incrementals every other night. if i make a major change during the week, and do a manual incremental, it may trigger a consolidation if i have 6 incrementals already. that takes a lot longer. when i do the new full it deletes the oldest full and all it's linked incrementals, keeps the current chain and starts a new one. this is usually enough for me. if you have lots of room, you can keep more chains.

i also occasionally manually copy a full into a usb hard drive folder as insurance. i made a full for the fall creators update and stored it there separate folder from the folder i sync the scheduled backups, as a justincase. then carried on with the next insider fast lane build update and created a new full after it completed successfully.

 

in the gui, select the 'restore' tab, each listed backup, incr. or diff. has a selectable 'other options' in it's lower right, one option is to delete. if you delete a full, it will also delete any associated incrementals (or differentials). best done with this option, as it can mess with macriums internal indexes and make things harder to find.

differentials are not chained or dependent on the earlier diffs, so can be deleted willy-nilly. incrementals deleted from the chain, break it and the incr. newer than it are useless and would be deleted if you use the gui, but will just take up space and be confusing if you manually use explorer to delete a mid chain incremental.

incrementals can be more space efficient but more vulnerable than differentials.

 

Aah thanks @kronckew! I was going to the Restore menu item along the top ...

I see that now under the Restore tab. So simple when you see the answer, doh.

 

Thanks Arvy. Have deleted the 4 questionable incrementals as I don't want whatever problems they contain to come back to haunt me. Was very easy process within the MR GUI. But, if I now do a new FULL, will this also delete all of the older incrementals? I do sometimes have occasion to browse these older backups individually and would hate to lose whatever gems may be hiding in there. I think I understand that everything would get lumped together and be put into the new FULL, however I would rather not have to contend with such a jumbled mix of data.

 

Yes I do similar - it depends of what problem I try to "solve" by restoring. If I just tested some software and want to remove all traces, I usually don't delete increments. Once when chkdsk showed some errors, I deleted increments to avoid filesystem errors in later increments.

 

Before using MR I did the same, also with no problems. But now I just feel a little "safer" by restoring previous image.