Confused about MR retension rules


Author
Message
pokeefe
pokeefe
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 26, Visits: 85
I have recently switched from Acronis True Image and am struggling to understand the Macrium Reflect backup retention rules.  I have finally realized that he differences between the products are not just a matter of semantics; the concepts seem to be radically different.  Even though this may not make sense in the MR world, but initially I want to maintain the same backup schemes I'm use to until I get more familiar with MR.

For one set of files I take daily scheduled backups plus an occasional manually invoked backup.  I want to retain 5 chains of a full plus 6 incremental backups.  After I've taken enough backups there will be 4 chains of a  full+6 incr and a chain of a full + 0-6 incrs.  This would maintain 28-34 backups with the oldest chain of 7 being deleted each time a new full is created.  No consolidation would be done.

I though the specification for this would be 5 full, 6 incremental, no differential.  But I've just read that the "Retain <n> incremental backups" refers to the total incrementals, not the number chained off a full.  If that is the case, I don't have any idea how to say when I want another full backup taken.  In fact, I don't have any idea at all how to define this retention plan

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
So to confirm, you want 5 Fulls with 6 Incrementals EACH?  And then if you don't want any Incremental consolidation, that means that the only time any Incrementals would be purged would be when their parent Full was purged, since there's no way to purge old Incrementals without consolidation, because simply deleting them would invalidate the subsequent Incrementals in the chain.  Are you ok only ever purging Incrementals as a group that way?

If you want at most 5 Full backups each with their child Incrementals and only want a given Full's Incrementals purged when the Full itself is purged, then set your Full retention policy to 5 backups and disable your Incremental retention policy entirely.  There's no point specifying an Incremental retention policy if you'll only ever be purging them when the parent Full is purged, which causes any remaining child backups to be deleted anyway.  And keeping the Incremental policy disabled will allow you to create manual Incrementals within the week if ever desired without risk of triggering any consolidation as a result.

Edited 29 June 2020 11:38 PM by jphughan
pokeefe
pokeefe
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 26, Visits: 85
So to confirm, you want 5 Fulls with 6 Incrementals EACH? And then if you don't want any Incremental consolidation, that means that the only time any Incrementals would be purged would be when their parent Full was purged, since there's no way to purge old Incrementals without consolidation, because simply deleting them would invalidate the subsequent Incrementals in the chain. Are you ok only ever purging Incrementals as a group that way?

Well, that's the way I've been doing it for about 12 years.  At least one (and I think a couple others) of the MR competitors do it that way.  As I said, I think MR's technique is radically different that what I've seen in the past. so I have trouble understanding it.

If you want at most 5 Full backups each with their child Incrementals and only want a given Full's Incrementals purged when the Full itself is purged, then set your Full retention policy to 5 backups and disable your Incremental retention policy entirely.

Another point of confusion here.  I'm used the the backup process determining what kind of backup to take.  If an incremental scheme is in use, if it's time for a full, it takes a full; if it's time for an incremental, it takes an incremental and adds it to the chain anchored on the last full.

That apparently how it works in MR.  I understand setting a retention of 5 Fulls, but I don't see how to say when to create a Full.  Do I set up multiple schedules - one for the Fulls and once for the Incrs?  If so, how do I tie the Incrs to the Full?   (I'm pretty sure that's not how it works.  I'm lost.)

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
Deleting Incrementals as a group is certainly doable, but you don't HAVE to do it that way in Reflect if you don't want to.  The virtue of consolidation is that you don't have days where you only get one new backup (a Full) but lose an entire week's worth of backups, for example.  You can instead follow a "one in, one out" idea.  So for example you could have a plan whereby you capture one Full each week and an Incremental every day, and you always retain the last 2 weeks' worth of daily Incrementals, but you want the last 5 weeks' worth of weekly Fulls.  So after you had 2 weeks' worth of backups, as you worked through Week 3, each time you created a new Incremental, the oldest remaining Week 1 Incremental would be purged.  So in this setup, you would purge child Incrementals of a given Full BEFORE you purged the parent Full itself.  The idea here would be that for recent history, you might want to have daily backups available to restore from, but if you need to reach back farther in time, you might be fine only having weekly backups to choose from.  Reflect lets you configure retention policies that would achieve that.  You don't necessarily have to delete backups in the same order that you created them.  Macrium has a nice animation of this Incremental Merge concept here.  There's a variation of this called Synthetic Fulls where the Full itself gets "carried forward" in time as well rather than the oldest two Incrementals always being consolidated.  That avoids the widening "time gap" that is otherwise created between the Full and the oldest remaining Incremental.  But if you're creating Fulls on a fairly regular basis, Synthetic Fulls might not be worthwhile.

But if you would prefer to stick with purging an entire set at a time as you've been doing, then yes you would create multiple schedules associated with a single definition file.  I've provided a screenshot below of the schedule and retention policy that would achieve what you described in your first post.  Note that since the Full and Incremental schedules are set for the same time of day, on days when both a Full and Incremental would be scheduled, Reflect will automatically ignore the Incremental and only perform the Full, which makes it a bit easier to specify schedules like this without having to manually create exceptions for "Full days".

In terms of how Incrementals get tied to a Full, whenever creating an Incremental (or Differential, for that matter) Reflect always "appends" to the most recent "eligible" backup at the destination.  So if you request an Incremental, it will be appended to the most recent "matching" backup at the destination, regardless of type (Full, Diff, Inc), since Incrementals can be appended to existing Fulls, Diffs, or Incs.  If you were to request a Diff, it would be appended to the most recent "matching" FULL at the destination.  In terms of what constitutes a "matching" backup, when performing image backups, an existing backup would only be considered a match for the new backup being created if the existing backup contains EXACTLY the same partitions as the ones being backed up in the new job.  That means no additional or omitted partitions, the same partition sizes, and the same partition "offsets" (position on disk).  So for example it wouldn't be possible to create an Incremental as a child of a completely unrelated Full backup even if you were sending backups from multiple unrelated jobs all to the same destination folder.  But by the same token, if you ever adjust your partition map by shrinking or extending a partition, that will cause future backups created by the SAME job not to be a "match" for your existing backups.  At that point, you'll need to create a new Full.  If your schedule specifies an Incremental and Reflect can't find any "matching" backups at the destination to append to, then it will automatically create a Full and note this deviation and the reason for it in the job log.  Sometimes upgrading to a new release of Windows 10 can cause changes to your partition map, so this can happen unexpectedly.  In addition, by default the retention policy is set to act only on MATCHING backups. This is a safeguard for cases where multiple unrelated backups are stored in the same folder.  But that means that if your new backups no longer match the old ones, then your retention policy will no longer act on those older backups.  That can be addressed by setting your retention policy to act on all backups in the destination, but if you do that, make sure your destination folder stores ONLY backups created by a specific job, otherwise Job A could purge completely unrelated backups created by Job B.  More info about this Windows 10 upgrade issue here.

But here is a screenshot of an example job schedule and retention policy that would achieve what you described in your first post:


Edited 30 June 2020 1:28 AM by jphughan
pokeefe
pokeefe
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 26, Visits: 85
Thank you.  I'm going to have to read that a few times before I absorb it all.

BTW, I've seen several older postings from other people who have come from Acronis True Image.  They, too, were confused.  Maybe, from my description of what we are used to, you can understand why.  Macrium Reflect is a very different beast.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
I haven't used Acronis in any meaningful way, and not at all recently, because I've been happy with Reflect.  But even Reflect had a simpler (though much less powerful) retention policy in the V5.  Back then, you could only specify the number of backup SETS to retain.  So you could choose how many Fulls and child backups to retain at any given time, but there was no way to constrain how many Diffs or Incs within a given set could be retained.  As a result, the strategy I described above of keeping the most recent 2 weeks' worth of daily Incs while keeping the last 5 weeks' worth of weekly Fulls wouldn't have been achievable in any automatic way.  And just in case you haven't already checked, Reflect's online user guide is pretty good about explaining how the retention policy works.  You can access it from the Help menu within Reflect itself.

alQamar
alQamar
New Member
New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)
Group: Forum Members
Posts: 30, Visits: 49
Hi Pat, welcome onboard. If you have questions let me know. We can dig through it. Haven't had the time to read it all. 
I think I've understood the concept for retaining.
Edited 1 July 2020 11:18 PM by alQamar
pokeefe
pokeefe
New Member
New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)New Member (35 reputation)
Group: Forum Members
Posts: 26, Visits: 85
Thank you, but I think I now understand enough for a while.  I was missing the fact that I could (and needed to) define multiple schedules for each task - one schedule for the full backups and a more frequent schedule for the incremental (or differential) backups.  In the future I will look into various consolidation schemes, but for now I just want to make sure I'm taking approximately the same backups with MR that I was taking before.

alQamar
alQamar
New Member
New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)New Member (49 reputation)
Group: Forum Members
Posts: 30, Visits: 49
Aye! Glad you figured it out.
Edited 2 July 2020 12:18 AM by alQamar
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search