Macrium Reflect

In the videos, why does it go from Friday to Monday?

 

Software union. Negotiated that Reflect gets the weekend off?

 

As far as I understand the full is not really full at all (synthetic or otherwise), its part of a chain. A full backup is just that, one image in time that does not change. I never trusted incrementals having been burned by a corrupt incremental that rendered a chain useless. I did not trust AX64 chains either BTW, I made/make weekly full images of my PC with Paragon which I keep on a separate drive (4 images and then the external drive is rotated with an off-site drive). So what am I missing here with the distinction between video 1 and video 2? They are both chains and thus a corrupt snap in the chain will render them both useless. Yes or no?

In addition not only do we have to decide between incremental and differential, we have to decide between synthetic and full(sort of?) as well??

And what about full (full as I have described it above), can Macrium do that as well, automatically deleting the oldest one as its replaced by a new one, or is it limited to only crawling images of one sort or another?

Back to the aspirin bottle.

Edit: I just realized why video 2 is being referred to as a full backup, its because the incrementals merge with themselves not with the baseline image. Its the baseline which is the (1 and only) full image. So how long a chain would you allow before starting another chain? Corruptions in the chain would enable going back to the baseline plus up to just before the corrupted incremental snap, but thats it. And what happens if you try to restore a more recent time than the corrupted snap? And short of testing every snap how would you know prior to a situation where you absolutely had to restore?

Gads thats a lot of confusion on my part.

 

BG, most of the issues you mention above have to do with INCREMENTAL imaging no matter application performs it... your concern for the integrity of the images affecting the entire chain. This has been a concern since the beginning of digital time. Step back a few years and watch big data centers (waaaay before even minicomputers/microcomputers/individual PCs) handle their backup. To keep from spending drillions of dollars on magnetic tape reels and massive storage rooms/buildings to house those tapes, they came up with INCREMENTAL imaging to keep those limits at bay. If you think an INCREMENTAL image is questionable with today's SHA1 and MD5 checksum algorithms being stored on digital rotating storage media... how do you think those data center managers (I was one ) felt about the integrity of 12" reels of magnetic tape? Yea, the whole thing was always very, very scary... but my point is the technology is not. Incrementals have been around for over 50+ years and the process is well understood (the ability to check that backup has changed constantly)

As far as your other concerns above, you should look into GFS (Grandfather/Father/Son) backup technology. It uses INCREMENTALS in the very short term (snapshots, if I may) and DIFFERENTIALS and FULLS for long term storage integrity and reference (as well as duplicated backups if the storage is that important). And right now, Macrium appears to be offering it all, and making it as easy as you can for folks who don't wanna know too much (yes, you have to learn something... then you can set and forget).

A comment on backup integrity... GOOGLE knows that a backup is only as good as its ability to be restored. That's why it schedules, off-line, every backup it takes to be restored once again as a real integrity check... and if it passes, it's scheduled again, periodically. When it finally fails, it's reproduced using the other backups and the cycle starts once again. Sure, we can't do all that, but they do because their data is THAT important. How important is yours?

 

I like Chamlin's response best

They're just representing a "work week," Hadron. The scheduler allows to to select everyday rather than just a work week.

 

"Synthetic Backup" has nothing to do with the trust aspect. Let's start from the baseline with our thinking process here. There really is no such thing as a FULL and an INCREMENTAL when it comes to incremental imaging. The FIRST incremental is nothing more than a CHILD snapshot related to a non-existent PARENT... meaning there's nothing to start with so we do it all for the first incremental... a COMPLETE incremental (full image) as they say. Now from here on, each additional incremental becomes a CHILD of the previous PARENT... contains only changes that are not contained in the parent. I think we all understand what happens from here on.

The MERGING TECHNOLOGY used in both MACRIUM and AX64 is very similar and works in the same basic way. When you merge two snapshots, the 2nd (relative) snapshot, a CHILD, is merged back into the 1st (relative) snapshot (its PARENT)--- that's the only place you can merge a child snapshot in to --- and when the merge is complete, the 2nd snapshot is deleted and the 1st becomes (is renamed) the 2nd... its POINT IN TIME has now been moved up the where the 2nd originally was.

If you believe in this technology (and it really is pretty straight forward), AND you believe that what you used to call your BASELINE (1st FULL snapshot) is really an incremental based on no previous PARENT, then not only can you merge snapshots out in the chain, you can easily merge the 1st (relative) incremental back into the "reference" (1st PARENT) snapshot. It's this process that's called "creating the synthetic baseline"... based on the above merge description, the same merge is done and the point in time for the 1st parent moves to the point in time of the 1st child with the 1st child being deleted... it's the same process as above. The only difference is that Macrium keeps the 1st parent's name the same... for what reason, I have no idea. If they can determine the specs of a chain, they really don't even need to know a name for that new (or even old) 1st parent... I guess it just makes things a touch easier.

This should help you understand that the idea of a SYNTHETIC FULL is nothing more than market-speak for a standard incremental merging operation to a place that most have never done it before. As far as Marc's description of Video 2 meaning you have a "real" full backup... you always have a REAL full backup (everything available), it's just that the one in Video 1 moves along a timeline and always represents a differenet point in time... but it is really FULL.

 

Your understanding is mostly correct. Bringing your system back UP TO DATE works in both cases... you wind up at the last incremental taken.

If you wish to return to an incremental somewhere in your existing chain, yes either way will work.

BUT... if you chain is set up to migrate forever and has a limited number of incrementals, then your choice of return times starts to disappear in relation to when you first started the process. The "incremental" limiting will start to chuck points in time to maintain a fairly constant storage requirement... those points will no longer be available to return to. If you don't limit the incrementals, no problem... except for storage and restore time.

Your assumption about the two modes... synthetic vs non-synthetic, is correct... as long as you don't limit incrementals. As soon as the limit is imposed, you'll start losing points in time (not data). With a limit in place, synthetic mode will cause the original PARENT incremental to move it's time position each time the limit is reached. Some think that original PARENT incremental is very important, and for those they should not use the synthetic full mode.

If this is the only backup method you're gonna use, then you really need to think about how important that 1st incremental (the BASELINE) really is. BUT... if you combine the capability of GFS backup with a synthetic full moving umbrella of incrementals (different DEFINITION backup files to different folders), your long term data storage requirements can easily be met using the GFS method (Animation #3), and the separate synthetic full incremental umbrella can protect you easily against unwanted system failures of almost any type. That's why I'm using both during this test phase... trying to determine exactly how well I'm protected. No one method can cover all bases, but a combination can work very well for your backup requirements. Remember... I'm an ol' Data Center guy so I've seen (felt) some pretty nasty failure scenarios along the way... they ain't easy to get out of sometimes

 

I do need to add a li'l tidbit to the above statement. Although the technology used by both vendors above basically accomplishes the same result, the method used by Macrium is far superior in PERFORMANCE due to the approach and the merging algorithms involved (don't ask ... just measure).

 

Too many long replies to address everything individually, but my point about a synthetic backup not being a real full backup in that it is manufactured and maintained by the merging process. It starts as a full backup, but then is modified by the merging process. A real full backup to me is when the system is doing just that. Taking a full backup and never changing it afterward. Saying that, there's nothing wrong here! It just defines a "synthetic" backup.

If you don't like dealing with incrementals, you can set a backup plan that deals with differentials only. If one differential goes corrupt, it's no big deal. I set a job to keep 4 weeks of differentials and 10 weeks of full. Then take a full on the first of every months, a differential every day. I always end up with 2 month's worth of differential backups. No merging involved.

 

Thanks Mr Frog, my data is pretty important to me so I am glad to hear that MR does it all. I am not worried about disk space as backup drives are pretty cheap so for at least one portion of my regime I will continue to use full (as in my description) on at least a weekly basis and then for quick restores one of the 2 crawling methods. Which would you say was the more reliable or is it six of one and a half dozen of the other? I suspect you will say the one where the snaps merge into each other so the baseline is left alone.

 

Ah, got it, thanks.

 

Sounds like a plan, thanks.

 

Well... if you're MERGE averse (which I am not), both schemes use the same technology so if you're really afraid of merging you shouldn't use either.

But, as Marc has mentioned, you can set up your "Data Retention" schedule (say Weekly FULL and daily DIFFERENTIAL or INCREMENTAL (less storage required) for whatever permanency you'd like, then use a throw away "Protection Schedule" (crawling incremental w/synthetic full for your daily protection). That would only be used, as mentioned, for some sort of emergency restores. Even against that "crawling incremental," you can take MANUAL snaps (MicroSloth upgrades, software test, etc.) with specific comments and mix them right in with your hourly (or whatever) basic umbrella protection... all will crawl along just fine.

One of the things this app now offers in its scheduling is not just the # of incrementals to be managed as a chain, but if you take a lot of manuals along with hourly protection snaps, the "managed" chain may be described in # of snaps, # of days or # of weeks for retention purposes. Rather than have it crawl based on # of backups (which a lot have been talking about in the forum), you can base it on # of days. This way your umbrella can be the coverage you want, regardless of the number of snaps in that coverage. This way you'd always know the umbrella was at least one (two, threee, whatever) days/weeks in length, regardless of how many MANUAL snaps you decided to use along the way. This method is perfect for rooting out old corruptions (Ransomeware that installed itself 3-days ago) or just normal protections against software installations, MicroSloth bad updates, whatever. I would s'pect that would be the most popular umbrella protection method (especially for those who like to do a lot of manual protection snaps). The GFS discussed earlier (weekly FULLs, daily DIFFs) will handle data retention only.

 

"Who Rha!"

Now THIS man is getting VERY EXCITED

 

First thanks mainly to Froggie and Pete for all the testing and explanations they have done.

I have one query which I am not sure if it has been answered. I have Macrium 5x (pd) and find that it is very slow making a full backup. It takes 6 mins to make the image from 34GB of original data versus 2 min with Active@. I would like to know if there has been an improvement in the speed of Macrium. Both programs were using the default settings.

 

From the little I've read, I think I understand that there are three(?) ways of backup(?) Full, Differential and Incremental.. What's the difference between differential and incremental?

 

Thanks Pete

That would equate to about 2 mins for 34GB if you can pro-rata it like that. So I asssume from that that it is faster. Presumably you haven't tried on V5?

 

My 35.1gB test image was taken in 6-min by a 3.4ghz i7 from a SATAIII SSD to a 7200rpm HDD.

Your Active@ time above equates to 300mB/sec... which I find extremely hard to believe unless you're doing SATAIII SSD to SATAIII SSD, and even that is very hard using Windows normal file flow.

 

SanyaIV... I'm sure you know what a FULL is. A DIFFERENTIAL contains all the changes since the last FULL was taken (it grows with time), and an INCREMENTAL contains all the changes since the last INCREMENTAL (or FULL if no incrementals exist yet) was taken. Based on that, Incrementals will in almost all cases be smaller than differentials. BUT... that also means than an incremental backup will require all other incrementals in that chain (since the FULL) to reconstruct the current image, a differential on the other hand only needs the FULL and itself to reconstruct, no other data is required.

 

I have to add to this that my observations above are based on a SYSTEM image, not a DATA partition image. A data partition can contain some really compressible (and a lot of non-compressible if MUSIC and VIDEOs) data and could make those numbers palatable.