Discussion in 'backup, imaging & disk mgmt' started by Stigg, Nov 23, 2013.
Fyi you're looking at the Edit Defaults retention policy settings. Those only apply to newly created definition files. Changes there would not affect any existing definition files. To change the retention policy on an existing definition file, right-click it and select Schedule.
The reason for setting retention policies on the other types is that not everyone wants to wait until they're ready to have a Full backup purged to remove other backups. For example, let's say your schedule specifies a Full every month, a Differential every week, and an Incremental every day. You might want to have Fulls going back 6 months, but you don't have the storage to retain 6 months worth of all of your backups -- but that's ok because you also decide that you don't need DAILY backups going back that long. You might for example be ok having daily backups (Incs) going back only 2 weeks, then weekly backups (Diffs) going back 2 months, then only monthly backups (Fulls) going back 6 months. Typically people want the greatest "granularity" of backups in their recent history, but if they need to go way back, they might be ok having fewer backups available to choose from.
Purging Differentials before purging their parent Full would cause any child Incrementals to be deleted. As for "needing" a restoration point, I'm not sure what you're asking there. The same logic could be used to argue for never purging any backups at all. At some point you have to decide you're ok purging a backup, or else get more storage. The reason people purge Diffs before Fulls is for the scenario I described above. As time goes on, they might be ok having fewer options for restoring data from far back in time.
Under the Backup Definition Files tab, click the green icon to import a definition file and find the one(s) that your scheduled backups are referencing. Then you can right-click it and select Edit > Next to access the retention policy settings. Or select Edit > Schedule to go directly to the second step of the edit wizard.
@aldist, thanks but (as I have said) there is nothing to click-on under Backup Definition Files!
That did the trick - thank you very much!
Yes, I know that, JP.
I just though that image would explain things better.
I see. Thanks. That's not my scenario though.
I just resized the 2 partitions on my hard drive, do I need to do anything in regards to MR6 Pro or will things adjust themselves at the next dofferential image (tomorrow morning)?
Since you changed your partition map, you're going to get a Full at the next backup even if you ask for a Diff. Also, your retention policy will no longer act on the old backups unless you have it set to act on "All backups in the destination folder" rather than the default "Matching backups in the destination folder". But don't choose the all backups option if you have image backups generated by other definition files in that folder.
Thank you for the reply, much appreciated. I got busy yesterday and forgot to check here for an ans until just now. I did nothing, it just ran so I guess I got a full image. What are the implications for the retention policy since it just did defaults? I assume my retention policy from the old set up remains in place for the new chain (if there is a new chain), is a new chain created and the old chain remains forever on the backup drive? A bit late now but just wanting to understand whats happening to a better degree.
I had forgotten to add in my earlier reply that one of the implications of getting a Full when you didn't expect one is you will LOSE your oldest Full sooner than expected unless you disabled the Full retention policy entirely. Hopefully that didn't create a problem for you. In terms of what happens going forward, if your job all of the default retention policy settings, then none of the backups generated by that job will be subject to the retention policy anymore. The reason is that by default, Reflect enforces its retention policy against all "matching backups" in the destination folder. For image backups, a "matching backup" is defined as one that contains exactly the same partitions, including partition sizes, as the new backup being created when the retention policy is being run. The backups you made prior to resizing your partitions no longer match the new backups you'll be creating, so Reflect will never take action on the old backups. So you can deal with this either by changing your retention policy settings to act on "ALL backups in the destination folder" (subject to the caution I mentioned in my earlier post), or just delete the old backups manually when you're ready to do so.
Thank you for the clarification, much appreciated jp
I've found that I cannot mount my Macrium backups to browse the contents. It gets to the "Assigning Drive Letters" and then ends. No error message at all. Any suggestions on where to troubleshoot?
EDIT: In addition to verifying the whole backup line, I'm going back sequentially trying to load each incremental. The base backup does work.
EDIT2: The chain verified fine. Only the full base backup can be browsed. The rest are all incremental deltas.
EDIT3: A repair install did nothing.
How long is the Incremental chain? Incremental Deltas can take longer to load since Reflect has to build the index from all backups in the chain, as opposed to regular Incrementals that each have a full index. Also, perhaps see whether you can browse these backups in the Rescue environment. Use the PE Explorer application (the folder icon in the taskbar) to browse there.
The chain is 7, including the full backup. But again, I went all the way down the line, and not even the 1st incremental would work.
EDIT: I tried mounting some incrementals again within Windows just now, and for some reason they all work now. Odd!
Macrium Reflect v7.2.4156 (April 3, 2019)
Spoiler: What's New - Bugfixes v7.2.4156
What's New v7.2.4156 - 3rd April 2019
Large NTFS Cluster Sizes
Macrium Reflect now includes support for volumes formatted with the NTFS file-system that have a cluster size larger than 64K.
Change Block Tracker
On some system using Microsoft Storage Spaces the option to enable CBT could fail. This has now been resolved and CBT fully supports Storage Spaces.
Performance Optimization. The frequency with which CBT flushes its internal state to disk has been reduced.
File and Folder Incorrect Progress Bar
Reflect Monitor would show a sliding progress Marquee instead of the actual backup progress. This has been resolved.
WinRE Wi-Fi Connection
It was not aways possible to switch Wi-Fi networks when more than one network was available. This has been resolved.
The PEExplorer application in the rescue media now includes a file deletion confirmation prompt.
'psvolacc.sys' error when browsing Images in Windows PE/RE
An incorrect error could be displayed when browsing images if the 'Enable access to restricted folders' option was selected in Windows PE/RE. This has been resolved
License Key Edition Change
When changing the installed edition of Macrium Reflect the previous license key could be retained after running the installer. This has been resolved
BitLocker Removal Warning
When resizing a restored BitLocker unlocked image the BitLocker Removal warning message box would not be displayed. This has been resolved
Various small bug fixes and changes to improve Macrium Reflect.
So lately I've been moving over more and more to Linux. I guess it's a mixture of not wanting to use Windows, wanting to try something new, and wanting to learn Linux. I'm currently using Manjaro KDE which I really like. Of course there has been issues which have taken me whole days to figure out and other just super standard settings (I thought) like mouse acceleration that is surprisingly hard to configure. I've been able to work through most of my issues but one glaring issue remains - backups.
It seems like Linux doesn't have an equivalent to VSS which seems to mean a risk of data loss when doing live backups. I'm not really an expert on this but at least that's what I've been able to find. Due to the lack of live snapshots I'm considering some sort of model where a snapshot is made at every startup or alternatively on every shutdown. If I remember correctly, Macrium Reflect supports ext4 partitions, so does anyone know if this would be possible with Macrium Reflect?
Does ext4 snapshots also support incremental snapshots?
While I'm mainly looking for ways to continue using Macrium Reflect I'm also open for alternative suggestions, although I realize that this is a thread about Macrium Reflect and not its alternatives so any alternatives could be sent as a PM as not to go off-topic.
You're correct that Linux does not have an equivalent to VSS and that this is why live backups are not ideal. (It really surprises me that Linux still doesn't have this given that VSS arrived in 2001 with Windows XP....) I don't know if capturing a snapshot at startup or on every shutdown would fully mitigate the risk of a live backup because technically the OS is still running to some degree at those times. Reflect does indeed support EXT4 partitions and can capture Diff and Inc backups of such partitions, though you can't use Rapid Delta Clone or Rapid Delta Restore. However, if you won't have a Windows environment on this PC at all, you'll have to use Rescue Media to perform the backups, and since the Rescue Media environment does not use backup definition files, performing a Diff or Inc backup involves a rather unintuitive process of going to the Restore tab, selecting an existing backup in the lower area of that window (add the folder containing your backups to the Folders to Search list if they're not already listed), and then clicking More Actions > Create Diff/Inc.
A few weeks ago, I disabled the hourly background checks by removing the check mark from the box located at Edit Defaults > Update. I left the box checked for the daily checks. Today, when I launched Macrium Reflect I did not receive an update notification for v7.2.4156. I had to manually check for it and then it appeared. Why would the daily update checks stop working just because I disabled the hourly update checks?
Had you already launched Reflect earlier in the day? If so, then 4156 might not have been advertised at that point, and then subsequent Reflect launches on the same day would not have included an update check because your daily check had already occurred.
Apologies if this is already obvious to others, but despite having used cloning tools for a long time now, this only just occurred to me. I've realized that performing periodic clones of Disk A to Disk B as a "backup" solution for Disk A -- which is especially tempting with paid Reflect versions due to the Rapid Delta Clone feature -- is actually a very risky proposition. The fundamental problem is that when a clone operation begins, your destination becomes unusable in its current state, and doesn't become usable again until the clone completes. This means that for the duration of the clone operation, you don't actually have a viable backup of your source disk -- which in turn means that if your source disk fails during the clone operation, you've immediately gone from having 2 copies of your data (before you started the clone) down to having 0 copies of your data. I have two identical external hard drives. One of them is permanently connected to my PC, and the other serves as a backup of that drive and is always kept offline except when I'm updating its contents. I used to use a file-level sync application to update the backup drive until Reflect introduced BitLocker Live Clone, which in conjunction with Rapid Delta Clone made for a much faster update routine. But now that this risk has dawned on me, I may switch back to file-level syncing, because in that case a source disk failure during an update wouldn't leave my entire destination disk in an unusable state.
My solution is to create full Macrium disk images of (A) on a backup drive (B), rather than clone (so I can keep several copies on the target drive). I retain several older images of (A) on the backup drive, and only delete the oldest copy to write a new one. So I always have more than one full copy of my drive (A) data that way.
I've come to the realization that multiple Full image backups on the backup drive is the way to go from a data security standpoint, since that avoids the mid-clone failure risk and also mitigates the image file corruption risk. The issue in my case is that even taking compression into account, I don't think I have enough capacity to keep 2 Full backups of my primary drive on my backup drive since the two drives are identical. Also, having to create Full backups even periodically would add a substantial amount of time to my process compared to using Rapid Delta Clone or file-level syncing since these are 4TB drives. So in this particular case, I might just go back to file-level syncing, since that way I'll only ever be performing incremental updates, I don't have all of my data wrapped up in a single container file, and I'm not risking the entire backup drive every time I want to update its content.
The daily check didn’t work today either, so that wasn’t it . I turned the hourly check back on and at least that still works. I got the update notification and did the update.
It takes me about 35 mins to FULL image 175GB of used space from my internal 250GB SATA C: system drive to an external USB3 1TB drive. I keep a rotation of three daily images, plus 2 monthly images on the backup drive, all run automatically from the Macrium scheduler. So that part is all hands off, on autopilot, set and forget.
I also keep a 2nd USB3 drive offline, and weekly I will connect it for a scheduled weekly image. I keep a rotation of two images on that drive. That provides coverage in the event that the other two drives fail or get corrupted.
It also doesn't hurt to occasionally make a native Windows 7 Image (Win7/8/10) manually from Windows control panel. That VHD container can be mounted and opened in Windows without any 3rd party software, in the event that Macrium ever fails to do the job.
Separate names with a comma.