If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
I ran into a case you might find mildly amusing.
I was moving some data around (drive consolidation) and happened to move a 1TB MRIMG file off a disk. For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. It does this Source Disk ----- Destination Disk [1TB of writes] checksum(Destination Disk) [1TB of reads] It must be done this way, to avoid "cheating" and leaving the archive not truly verified. In the same way that Imgburn pukes out the DVD, before it does its verify run. So that's how this problem can be solved with automation. If you paid for the software, there's a tick box for this, and your warning of trouble would have arrived sooner. ******* I suspect what happened, is this machine had bad RAM. The source disk was read into RAM (good so far). The MD5sum of 64KB blocks of data is computed and stored in the MRIMG. Then the data is copied to the disk (perhaps using a different RAM buffer). At this point, the data was corrupted by the bad RAM on my machine. Now the checksum, and what was written to disk, don't match. I didn't notice this, until checking this MRIMG today. I had a similar "bad" archive a couple months ago, and just discarded it. The bad RAM actually showed up, while I was testing the Windows Memory Tester. I was not able to fault isolate to the nearest stick, so replaced all the RAM. When I ran a test backup today (1TB MRIMG), a Verify run on that one passed. So the new RAM appears to be OK. ******* The message here is, if you're using the Macrium free version (without AutoVerify), you should occasionally do a verify run on one of your images stored on your external. Just in case you've got a hardware problem. Like Dirty Tape Drive Syndrome, where all the backups you're making are "bad", you want to catch this problem before your external disk contains nothing but "bad" MRIMG files for recovery. Like, say you have Ransomware on the computer, right at this instant, you reach for the external, start a restore, and every image you access is "bad". Then, like a Dirty Tape Drive, you're screwed, even though the hard drive backup methods are immensely better than the dirty tape drive era we used to live in. I was the guy at work, who promoted Cleaning Cartridges for the tape drives, but this had little effect on user practice, often with humorous effect (the "learn the hard way" method). It's not that I hadn't thought of running verify. It's just it never occurred to me, I should be doing it more often, as a means of spotting defective hardware before it was too late. Paul |
Ads |
#2
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
Paul wrote:
I ran into a case you might find mildly amusing. I was moving some data around (drive consolidation) and happened to move a 1TB MRIMG file off a disk. For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. It does this Source Disk ----- Destination Disk [1TB of writes] checksum(Destination Disk) [1TB of reads] It must be done this way, to avoid "cheating" and leaving the archive not truly verified. In the same way that Imgburn pukes out the DVD, before it does its verify run. So that's how this problem can be solved with automation. If you paid for the software, there's a tick box for this, and your warning of trouble would have arrived sooner. ******* I suspect what happened, is this machine had bad RAM. The source disk was read into RAM (good so far). The MD5sum of 64KB blocks of data is computed and stored in the MRIMG. Then the data is copied to the disk (perhaps using a different RAM buffer). At this point, the data was corrupted by the bad RAM on my machine. Now the checksum, and what was written to disk, don't match. I didn't notice this, until checking this MRIMG today. I had a similar "bad" archive a couple months ago, and just discarded it. The bad RAM actually showed up, while I was testing the Windows Memory Tester. I was not able to fault isolate to the nearest stick, so replaced all the RAM. When I ran a test backup today (1TB MRIMG), a Verify run on that one passed. So the new RAM appears to be OK. ******* The message here is, if you're using the Macrium free version (without AutoVerify), you should occasionally do a verify run on one of your images stored on your external. Just in case you've got a hardware problem. Like Dirty Tape Drive Syndrome, where all the backups you're making are "bad", you want to catch this problem before your external disk contains nothing but "bad" MRIMG files for recovery. Like, say you have Ransomware on the computer, right at this instant, you reach for the external, start a restore, and every image you access is "bad". Then, like a Dirty Tape Drive, you're screwed, even though the hard drive backup methods are immensely better than the dirty tape drive era we used to live in. I was the guy at work, who promoted Cleaning Cartridges for the tape drives, but this had little effect on user practice, often with humorous effect (the "learn the hard way" method). It's not that I hadn't thought of running verify. It's just it never occurred to me, I should be doing it more often, as a means of spotting defective hardware before it was too late. Paul Interesting! Thanks Paul. Guess I should turn off ram o/c before doing backups. |
#3
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
Paul wrote:
For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. According the following page, the free version now has the AutoVerify option, too. https://www.macrium.com/reflectfree Looks like a feature added to v6 Free (likely they just enabled to code already there that you had to previously pay to get in their payware version). I'm still trying to find what they mean by "backup management". Is that a retention you can set on the backup images? That is handy to prevent the destination for where the backup images from getting filled up which results in all subsequent backups failing. I'd rather have the backup program do the cleanup of too-old backups than e-mailing me about a failed backup job and then I have to do manual deletions. I'm guessing their backup management is what they refer to as the retention rules (http://knowledgebase.macrium.com/dis...onsolidation); however, since the freeware version does not include incremental backups, you cannot have a grandfather-father-son (GFS) scheme plus you lose on the space savings of incrementals. On the above web page, it says "Coming soon: Macrium Reflect 7 Free Edition". There had been rumors in their forums that v6 was the last free version and v7 editions would all be payware. Seem the freeware version typically shows up a couple months after the release of the payware version. Well, v7 came out at the end of February 2017 and after 6 months the v7 Free version has yet to show up. https://www.macrium.com/version-7 No idea if Macrium Image Guardian will be part of the freeware version. I've heard that MIG will be part of v7 Free. No idea how it works but doesn't appear to be a clone of Acronis Secure Zone or Paragon Backup Capsule which both use a separate partition that has no drive letter assigned to it and uses a non-standard partition type value in the partition record for that partition. Another trick would be to use a special volume in which to save the backup files and then use Windows policy to restrict access to that volume. Could they use the old trick of stacking a kernel-mode driver into the system file API that would block non-registered processes from accessing some part of the file system. That seems what their "architecture" diagram represents in the 2nd article below. Some [little] info he https://blog.macrium.com/better-safe...y-ef32d8605830 https://www.macrium.com/mig http://knowledgebase.macrium.com/dis...Image+Guardian From the 3rd article, "MIG is a default component in the Macrium Reflect installer available in all editions except for the Free Edition." Hmm, some say MIG will be in v7 Free but some articles say no. I've been burned by missing or incomplete features in payware backup software that I'm loathe to dole out more money thrown at a new version hoping it does everything it says it will. |
#4
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
VanguardLH wrote:
Paul wrote: For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. snip I'm still trying to find what they mean by "backup management". The Macrium V6 has a separate page, when you define a backup, that sets the backup management policy. You can have backups "rolled over" automatically. Say you have Thursday Friday Saturday on the external. You start a backup, and it runs out of space. It will delete Thursday automatically for you, and add your new Sunday backup. Friday Saturday Sunday However, if you place the backups from two machines into a common folder, Machine B will delete all the backups made by Machine A, if you do enough backups on Machine B to use the majority of the space. So you don't really want to share a single folder with two machines. During the V6 interval, Macrium staff claimed to be re-writing that management, but gave no hints at what their new policy might be. I see yet another interface to it, here. https://alssl.askleomedia.com/wp-con...management.png This is the one I was thinking of, which pops up as a page during backup definition. Just after you've defined what partitions you want to back up in the disk-management-like interface. http://knowledgebase.macrium.com/dow...%3A54%3A27.png ******* My older version here, says the next upgrade is V6.3.1835, so there's no mention of a V7 existing. I could find a reference to V7 earlier today, someone offering a "crack" for it. I couldn't find any references to why they were doing it, what they were doing, or anything. And no, when a crack is offered, I don't go to the "Home" site of the crack for details, assuming the site is booby-trapped :-) I couldn't find any other discussions about it. Paul |
#5
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
Paul wrote:
VanguardLH wrote: Paul wrote: For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. snip I'm still trying to find what they mean by "backup management". My older version here, says the next upgrade is V6.3.1835, so there's no mention of a V7 existing. And it might not be a good idea to rush to the V7 commercial version either. They implemented a block tracking scheme called CBT, that seems to be slowing down the time to do backups. This thread mentions it's now an install-time option, so you can install V7 without CBT filter driver. https://forum.macrium.com/Topic15711.aspx Paul |
#6
|
|||
|
|||
Macrium Backups and Dirty Tape Drive Syndrome
So that's where you were the last few days.
Paul wrote: I ran into a case you might find mildly amusing. I was moving some data around (drive consolidation) and happened to move a 1TB MRIMG file off a disk. For fun, I ran the Macrium Reflect "Verify" option on the file, and it failed. The paid version of Macrium, has an "AutoVerify" option, which will verify the archive checksums after a backup is finished. It does this Source Disk ----- Destination Disk [1TB of writes] checksum(Destination Disk) [1TB of reads] It must be done this way, to avoid "cheating" and leaving the archive not truly verified. In the same way that Imgburn pukes out the DVD, before it does its verify run. So that's how this problem can be solved with automation. If you paid for the software, there's a tick box for this, and your warning of trouble would have arrived sooner. ******* I suspect what happened, is this machine had bad RAM. The source disk was read into RAM (good so far). The MD5sum of 64KB blocks of data is computed and stored in the MRIMG. Then the data is copied to the disk (perhaps using a different RAM buffer). At this point, the data was corrupted by the bad RAM on my machine. Now the checksum, and what was written to disk, don't match. I didn't notice this, until checking this MRIMG today. I had a similar "bad" archive a couple months ago, and just discarded it. The bad RAM actually showed up, while I was testing the Windows Memory Tester. I was not able to fault isolate to the nearest stick, so replaced all the RAM. When I ran a test backup today (1TB MRIMG), a Verify run on that one passed. So the new RAM appears to be OK. ******* The message here is, if you're using the Macrium free version (without AutoVerify), you should occasionally do a verify run on one of your images stored on your external. Just in case you've got a hardware problem. Like Dirty Tape Drive Syndrome, where all the backups you're making are "bad", you want to catch this problem before your external disk contains nothing but "bad" MRIMG files for recovery. Like, say you have Ransomware on the computer, right at this instant, you reach for the external, start a restore, and every image you access is "bad". Then, like a Dirty Tape Drive, you're screwed, even though the hard drive backup methods are immensely better than the dirty tape drive era we used to live in. I was the guy at work, who promoted Cleaning Cartridges for the tape drives, but this had little effect on user practice, often with humorous effect (the "learn the hard way" method). It's not that I hadn't thought of running verify. It's just it never occurred to me, I should be doing it more often, as a means of spotting defective hardware before it was too late. Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|