Hi, I'm getting file system errors with an increasing frequency. SMART shows zero issues which is odd to me.  The drive has 8.5 years of power on time though so I'm willing to replace it.
I have a backup definition that creates incremental daily and occasional differentials, and I have a bunch of retention rules as pictured below.  
I am stuck waiting a few days for a replacement drive.

I have been bitten by unintended consequences and rules being applied when I don't expect them.  I'm also hesitant to change my settings.  

Is there a way I can "freeze" some of my images?  I want to make sure that, no matter what, I don't lose images from before the most recent corruption.  The files are huge and spread out amongst different files that I let macrium manage, so I'm not super confident about manually copying the files.  

Thank you!
(Side note: IIRC, when I replace the drive with a similar drive and image it, Macrium will be able to continue my existing backup scheme's incremental and differentials, except using the new disk, is that right?)

Is this drive that you're going to replace just a drive that stores Reflect images or does it contain partitions or files and folders that Reflect backups on these schedules?  If this drive you're replacing contains source data you're backing up, then there will be one issue you may not have taken into consideration.  Your scheduled backups probably won't run at all until you update your backup definitions to reflect the new partition/drive metadata that will be on the new drive you're swapping in.

+x

 

dbminter - 13 February 2022 2:11 PM

Is this drive that you're going to replace just a drive that stores Reflect images or does it contain partitions or files and folders that Reflect backups on these schedules?  If this drive you're replacing contains source data you're backing up, then there will be one issue you may not have taken into consideration.  Your scheduled backups probably won't run at all until you update your backup definitions to reflect the new partition/drive metadata that will be on the new drive you're swapping in.

Hi, thank you for your response.  I understand that my question is a little odd and I might have a hard time wording it correctly.  My goal is to freeze a set of known good backups in a foolproof way that disrupts my existing scheme the least.  I want to just never have to worry about some rules in Macrium or a misclick accidentally wiping them out while I'm waiting for the replacement.  This might be considered a "nice to have" and maybe I'm being too anxious about messing with my Macrium settings.  I have experienced several instances where I hit "go" and accidentally wipe out my ability to restore things, over the years.  

My source drive is having corruption problems, about once per day I chkdsk d: /scan and it pings me to run a repair.  Also, every morning that drive is scheduled to be backed up, and macrium tells me when it encounters an MFT problem.  After I finish the repair, I get a clean scan. 

The concern is that any of my rules with macrium could kick in at any time, such as rules about what to do when you reach X amount of remaining space, and retention rules. I'm looking for a way to insure myself against any actions Macrium might take as part of the normal routine, without disrupting the routine.  It might sound paranoid, but (no joke), a while back I was in the middle of a restore operation and the software kicked off a routine that messed me up. 

Assuming that you trust the stability of your destination drive, I think your easiest and most fool-proof solution is to edit the definition file so that the images are saved to a new folder.  This will definitely prevent your retention rules from deleting anything in the original folder, thus "freezing" the original folder.  One drawback is that the first backup made using the revised definition file will create a full image.  If this is problematic for you (in terms of space or time required), then a different solution would have to be used.

I'm fairly sure that as long as you don't change the name of the definition file itself, your existing schedules will use the revised definition file that has the new destination folder, but I'm not 100% certain of this.  Perhaps somebody else can confirm.

                                

I was going to suggest something similar, but decided not to because I thought of a major drawback to this idea.  My idea was to create a temporary folder and move all the images to it, though that may require disabling Macrium Image Guardian temporarily.  The problem with both of our solutions is there will be two sets of backups now.  The old set, with all its Fulls and children, and the 2nd new set generated.  So, keeping tracking of what backup is what might prove difficult.  And you'd have more space taken up.  Plus with my solution, if you move the backups, I don't think they'd show up in Reflect's list of backups anymore.

DB, I think that moving the existing backups is riskier, in the off-chance something goes wrong during the move.  With your usual belt-and-suspenders mind-set, I would have thought you would only suggest moving the critical backups if they are copied and verified from both Windows and rescue (and perhaps using a 3rd part app to compare bit-for-bit) before deleting from the original folder.

Personally, I don't think there would be a lot of confusion having two separate backup sets.  It's even easy to toggle whether both sets or only one set is displayed at a time in the "Existing Backups" view.   

I would actually modify my suggestion to make it easier:  Just rename the existing destination folder using Windows Explorer (e.g., name it "Frozen Backups", etc.).  I don't know whether Reflect will fail a scheduled backup task if the destination folder specified in a definition doesn't exist -- if that's the case, then @BenR29 should also create a new folder and assign it the old name of the original destination folder.  This method has the benefit that the definition file does not need to be modified, and the old destination folder name can be re-used going forward.   It also has the benefit of not requiring any of the critical backup images to be moved or manipulated in any way.

If you want to display the frozen backup images in the Existing Backups view, just use "Edit" or "Browse for an image file" to navigate to the renamed folder.

                                

I wouldn't have thought moving the files to another directory on the same device, particularly a sub-directory of where they currently resided, would be that risky.  It's just updating pointers from one location to another.  The files are still in their same place in the sectors they originally occupied.  However, I guess there could be potential danger that moving the pointers to a bad section of the disc might render the contents inaccessible if those pointers didn't update properly.  e.g. the pointers were moved to a potentially bad area of the disk.

Is this drive that you're going to replace just a drive that stores Reflect images or does it contain partitions or files and folders that Reflect backups on these schedules? If this drive you're replacing contains source data you're backing up, then there will be one issue you may not have taken into consideration. Your scheduled backups probably won't run at all until you update your backup definitions to reflect the new partition/drive metadata that will be on the new drive you're swapping in.

I just realized I never answered your question directly.  Sorry about that.  From your other posts, I think we all are on the same page, but I just want to be thorough. 

The drive that I am going to replace (D: ) contains working data.  I have another drive (H: ) where I store my Reflect images.  H drive is fine.  D drive is going bad.

If I understand you correctly, you are informing me that when I swap out my D drive for a new one, my Macrium definitions will need to be updated to point to the new drive.  This is because Macrium uses metadata to ID drives, not simply drive letters as one might think, so it will not find the original drive it is looking for when I run the definition.

Understood, thank you!

(edited for clarity)

Reflect does not go by drive letters.  I think it goes by partition # or can be configured to use Volume ID?  Not entirely sure.


Once you swap in the new D drive and try to backup it up, the definition for that D backup will probably fail to run because the old drive info is no longer present.  But, it's a simple matter of editing the XML definition file to reflect the location of the new drive you swapped in for D.  The partition will probably have different start and end sectors unless you swap in a drive of the same size or same model.  Because of these different start and end sectors, you will need to update the XML.

Hi again, I'm sorry I'm trying to make sure I understand what your saying before I respond, but it's taking a while.  
I apologize if I don't show complete understanding of your suggestions.  

I like the idea of renaming my backup destination folder.  However I won't be able to fit that copy on my disk.  (hmm and if it did just barely fit, it would prematurely trigger my "low space" rules and I'd have to watch out for that). 

I have borrowed an external drive that can fit a copy of my image set. If I copy my backup data to that, I can treat it as a "frozen" copy of my backup, right?  So, the risk is that I'm reading all of the data from the drive an extra time, anything else?  

(The replacement drive arrived but was defective and the store doesn't cross-ship and the replacement would ship from overseas and would take 7-32 days... So that's a problem.  As far as my drive health, yesterday I went one day without a new chkdsk problem, but I found one today.)