Discussion in 'backup, imaging & disk mgmt' started by Stigg, Nov 23, 2013.
What is the size of the v8 distrib?
That isn’t being shared on a website yet. And if the V8 beta is like some other betas, it may include additional code for instrumentation or other functionality specific to the beta period and therefore may not be a reliable indicator of the production release in that regard. Or in the other direction, Macrium’s KB page as of this writing still has some features listed as Coming Soon, so they likely wouldn’t be accounted for in the current beta.
If I pay for an additional license via the 50% off offer I just received in email can I simply insert the new license # into my installed paid version thus get the free upgrade to v.8 when it becomes available?
You might have to remove the old license before you can enter a new one, but yes. And then that original license you were using would become available to be used on some other PC for V7. And you could probably buy a V8 upgrade for that one at a reduced cost when it launches too.
Good to know. Thanks again jphughan.
For those curious, the fix about Differential retention pertains to an edge case scenario, and it only affected reporting rather than actual retention policy behavior. Basically, I noticed and reported a problem with this scenario:
You have a time-based Differential retention policy
You have "Run purge before backup" disabled
All of your current Differentials are expired under that policy
If you then created a new Incremental as a child of the newest Differential, at the end of the job Reflect would end up honoring your Differential retention policy and deleting it....which would also cause it to delete the child Incremental it had just created. Even though that's technically an accurate application of the retention policy, Reflect deleting a backup immediately after creating it was not an intended outcome. Macrium meant to exclude the current backup's parent from retention policy purging in this scenario. They already had this implemented for Full backups, i.e. a Full backup older than the retention period would never be purged when creating a Differential/Incremental backup as a child of that Full.
So Macrium fixed that Differential issue a while ago, but exempting the current backup's parent Differential also caused it to be excluded from the count of Differential backups "found" at the destination. That created some confusion, because if you created a Full and just a single Differential, then all of your subsequent Incrementals created as children of that Differential would have job logs showing that no Differentials were found at the destination, because none were eligible for purging. So in this new update, Macrium revised the log wording somewhat to clarify what's happening in this situation.
I am new to Macrium Reflect and want to try it out. Some questions:
One thing which I noticed is that MR always wants to backup a FULL hard disk.
There is no menu/function "backup partition".
So when I want to backup only a partition I have to select the wrapping disk and deselect all checkboxes of all other partitions on it except my backup partition.
Can I later restore this "partition" backup into another partition (on a new hard disk) which has a different partition size?
Does MR automatically backup the file system other meta data (NTFS/FAT/FAT32/exFAT, the block size,...)?
May I ask here for some comments.
Question #1 = YES
Question #2 = YES, if the new partition is large enough
Question #3 = YES
Correct. But it will be much more convenient if you first create a definition file in which the partition-source, partition-destination and more are specified.
For Windows backup, you can select this menu, and Macrium will determine which partitions to include in the image.
Yes, you can.
Yes, but exFAT only for Intelligent sector copy.
Read here for details https://knowledgebase.macrium.com/ (search box on the left or top)
Due respect to @TheRollbackFrog, but not correct. In Reflect's "Create a backup" tab, click the partition of interest, and in the Actions menu that appears below it, select "Image this partition only". Although if you're imaging a Windows disk, you generally WANT all partitions. Either way, creating a definition file for any backup job you pla to run on any sort of a regular basis is a good idea so you don't have to step through the wizard every single time. That can be especially tedious and error-prone if you want to customize settings under Advanced Options.
If you make an image backup, yes. But not if you make a File & Folder backup. Additionally, due respect to @aldist, but capturing images of exFAT partitions using the default "Intelligent sector copy" is not currently supported. That will be coming in Reflect V8.
Due respect to @jphughan , when using the "Create a backup" TAB, at least with the versions that I use (v7 & v8 SERVER), there is no actions menu that I see. When selecting the "wrapping disk" (in @pstein words) and deselecting the partitions you don't want, only the NEXT button is available in that window to move on from. There is a "Copy this partition only" CheckBox in the Restoration menu.
Maybe we're using the app in two different ways...
@TheRollbackFrog I would have thought that saying "From the Create a Backup tab, select the partition of interest and click the Actions menu below" would've been sufficiently clear instructions, particularly for a fellow seasoned Reflect user, but in case you're a visual learner:
I've never used the "Actions" dropdown... I've only selected the partitions to be imaged and hit NEXT... which apparently uses your selection as it's DEFAULT. I guess I'll get it right someday...
I have a question : I have two drives I backup regularly. The destination is an external drive with a separate folder for each of these two drive's backup image files. I have two definition files, one for each drive. Everything works very well, but I looked to see if there were any options to combine two definition files into one, but didn't see any options for that.
Consolidation. https://knowledgebase.macrium.com/display/KNOW72/Standalone backup set consolidation
Exactly, you are right.
That allows you to consolidate backups, not definition files.
No there isn't, although that would be tricky because if certain settings were in conflict between the two files, you'd have to make a choice for which original file's setting selection you wanted to keep on each conflicting setting. And by that point it would normally be faster to just edit one of them to include whatever you want from the other one. If you just want to end up with a single definition file that backs up both of your source drives as a single job, edit one of them to expand its source disk/partition selection to include the other drive. You'll need to make a new Full backup after that since you won't be able to create a Diff or Inc backup from an earlier backup that was made from a different source selection, but after that you're good to go.
Also be aware that if your two "drives" are two different physical disks as opposed to just two different partitions on the same disk ("drive" is ambiguous and therefore worth avoiding), then if you ever choose to restore from that image backup, the first thing you'll see is a popup menu asking which source disk within the image you want to restore from. You can perform a multi-disk backup, but you can't perform a multi-disk restore in a single pass. So if you ever want to restore image backups of multiple source disks, you'll need to run back-to-back restore jobs, choosing a different disk within the image each time.
Of course, consolidation of backups, I never thought that someone would want to consolidate definition files
Agree, it did seem like an unusual question. But even backup consolidation only allows consolidating backups that are already members of the same set. You can’t combine backups from completely different sets.
Thanks. That got way too complicated for my simple mind. I was just thinking there could be a way of having a single definition file to run two jobs, Example: Backup disk one to folder blah blah. then backup disk two to folder yada yada.
It's OK, just a thought I had. Only a few more clicks to do two jobs since they can't be combined in one definition file.
Ah ok. The closest you can get to that is creating a script that calls Reflect twice, specifying a different definition file each time. But you can't chain definition files together within Reflect. And if you want to keep the backups of those two source disks separate from each other, then a single definition file that backs up everything isn't going to work.
@aldist and @jphughan
Thanks guys.I learned from you both.
What is the best way to refer to a complete physical disk drive, which may contain one or more (even many) partitions? When I said "drive", it is certainly ambiguous since each partition on that drive is also considered a "drive" by the operating system.
Please bear with me ...
Refer to them as DISKs and their pieces as PARTITIONs. Only Windows calls them "drives" when they refer to them.
In REFLECT's UI, there is a CheckBox at the beginning of the entire disk display and one for each partition on the disk. If you toggle the drive CheckBox, it will select or deselect all partitions on that disk. With them all selected, you may then deselect the CheckBox associated with each partition if you don't want it as part of your image.
Typically the entire disk is called a disk. Although in RAID situations you might have to differentiate between the "physical disks" that are members of the RAID array, and the "virtual disk" that the RAID controller presents to the system. For example, if you have a RAID 1 mirror, there will be two physical disks involved, but they will appear as a single (virtual) disk within Windows, and therefore within Reflect.
Disks have one or more partitions on them. For the Windows partition, in imaging discussion contexts I tend to say "C partition" and specifically avoid saying "C drive", because the latter is sometimes used to mean the C partition and sometimes used to mean "the entire disk that contains my C partition". Sometimes the distinction matters. I suspect the conflation here occurs because on a disk that contains a Windows installation, typically the C partition is the only one that isn't hidden, i.e. that actually has a drive letter assigned, and therefore some users think it's the only one that exists on the disk.
And lastly, each partition typically only has a single volume, which is the entity that actually gets a "drive letter" assigned to it. But there are exceptions. For example, on MBR disks it is possible to create an "extended partition" that can then contain multiple "logical volumes", each of which would have its own drive letter assigned. There are also cases where a single volume can span across multiple underlying partitions that can themselves be distributed across multiple disks, such as Windows dynamic disks or Storage Spaces. But those are relatively rare setups.
But for most cases, if you use "disk" and "partition", it will be clear what you mean.
Separate names with a comma.