Cloning Multiple Dupes


Author
Message
tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
I'm struggling to set up Macrium for recurring, automated cloning to multiple backup copies and could use some help.

I have three drives for all of my work files: an original on which I do my work, a backup clone that is attached to my computer at all times that runs automatically at 2am, and a second backup clone that is stored off site. I swap out the two clones every month.

When swapping the two clones, I'm struggling to get the second backup clone to pick up where the last one left off when using the same filename, drive letter, and Macrium backup task.

What's the best way to set up the backup task and name the drive and/or assign a drive letter to get cloning two separate backups of the same main drive to work?
Can I use the same task, filename, and drive letter for both clones?
Or do I need separate tasks, but I'm ok using the same drive letter and drive name? (for instance - T: Backup - Photo 1 for both backup drives)
Or do I need separate tasks, drive letters, and drive names for the two clones? (for instance - T: Backup - Photo 1A, U: Backup - Photo 1B)

I know some of this has to do with how windows perceives a drive as being the same or different from another drive, and I'm still learning my way around Windows so any insight you have on all of this would be hugely appreciated. Thanks! - Tom
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok first of all, you mention cloning but then also mention picking up using the same “file name”, and then talk about backups. So are you performing clones or image backups? Those are not interchangeable terms. It seems like you’re performing image backups, but I want to be sure. If so, this isn’t difficult to set up. I have a client that performs image backups to a rotation of 9 destination disks that are swapped daily. The entire thing is managed from a single definition file. In my case I use a third-party utility to make sure that all destination disks in the rotation are always assigned the same drive letter regardless of which one is attached, but Reflect has another way to do this internally if you’d prefer, and if you’re only dealing with two destination disks that might be easier. But again first it has to be clear exactly what sort of job you’re trying to run here. And if you ARE running clones rather than image backups, I would suggest that switching at least one of those disks over to storing image backups rather than storing a second clone copy of your source disk would be a superior strategy. The advantage of a clone disk is that if your primary disk fails, you can immediately install that clone disk and get back to work. But the advantage of image backups is that you can store multiple historical backups, giving you access to older versions of your data rather than just a single version as is the case with a clone — but you do need to restore that image backup somewhere rather than being able to operate directly from the “image disk” as you can with a clone disk.
Edited 23 December 2020 5:29 PM by jphughan
tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
Sorry for the confusion. I am looking to clone the drives. I have versioning in my cloud backup (using Crashplan for Small Business) in case I need to roll back a change. I need my local backup cloned so I have an easy swap for zero downtime during the workday.

So with that said, any advice on the four key questions:
What's the best way to set up the backup task and name the drive and/or assign a drive letter to get cloning two separate backups of the same main drive to work?
Can I use the same task, filename, and drive letter for both clones?
Or do I need separate tasks, but I'm ok using the same drive letter and drive name? (for instance - T: Backup - Photo 1 for both backup drives)
Or do I need separate tasks, drive letters, and drive names for the two clones? (for instance - T: Backup - Photo 1A, U: Backup - Photo 1B)

Thanks again!
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok, that helps.  If you want to clone Source Disk A to both Target Disk B and Target Disk C at different times, you want two separate definition files.  (I'm not sure what you mean when you refer to "tasks" and "filenames", unfortunately.)  In terms of drive letters, clones don't directly use drive letters because Windows assigns them dynamically.  Under the hood, a clone job says "For this clone job, the disk with unique identifier ABC is the source, and the disk with unique identifier XYZ is the target, and Partitions 1-4 [or whatever] on the source need to be cloned."  This means that Reflect will find the right disk even if a volume on it is assigned a different drive letter.

So here's your step by step:
  1. Connect one of your clone target disks.
  2. In Reflect, select your SOURCE disk and select "Clone this disk".
  3. In the wizard that appears, select your target disk as the destination and select which partition(s) from the source you want to clone.  If you want everything, just click Next.
  4. Optionally define a schedule if desired.
  5. When you click Finish, if you want to run the job now, keep that box checked.  But either way, check the box to save the job as an XML definition file and name this job "Clone to Target 1" or whatever.
  6. Repeat Steps 1-4 above except this time choose your second target disk as the destination and name it something else to differentiate it.
At this point, in your Backup Definition Files tab, you should see two definition files, one for each target disk.  At any given time when you want to clone to that disk, right-click it and select Run Now.

In terms of drive letters, Windows mostly handles that.  If you want to define custom drive letters, use different letters for each destination disk.  Again, Reflect does NOT rely on drive letters for finding clone targets. But if you for example manually set the first target disk to X, then disconnect it and set the second target disk to X, then Windows will forget that X was ever supposed to be used for the first disk. If you pick different letters for each, then Windows will remember those special assignments for each disk as long as nothing ELSE ever uses those special letters -- which is why it's good to use letters farther down in the alphabet to avoid those letters getting used by the default "next available" letter assignment.

In terms of "drive name", I'm assuming you mean volume label. The source disk's volume label will be cloned to the target. You can rename the target afterward if you like, but that will get overwritten each time you use a new clone.  There's an enhancement request around here somewhere to specifically allow specifying a different volume label for the target to make it easier to differentiate source and destinations, but that's not available today.

tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
This is super helpful! Thank you so much Smile

I think all of this makes sense. Let me say it back to you and pose a few questions along the way to make sure I'm tracking correctly.

To clone to two separate target disks I need two separate definition files (what I was calling tasks). One pointing to Target 1 and the second pointing to Target 2. I can set up each of those to run on a timer every night when I save the XML file. Will Macrium giving me a frequent warning if I don't have one of those Target disks connected while it's stored off-site for a month? And if Macrium does give warnings is there a place where I can turn warnings off or lessen the frequency at which warnings appear? I'm very on top of my backups, so I'm not worried about forgetting, and unnecessary warnings annoy me a lot, so I want to avoid them whenever possible.

Every hard drive has a unique identifier within Windows. Whether it's ABC for one drive or XYZ for another drive. Is there a place where I can see this unique identifier to note it for my records?

If I assign Target 1 a drive letter of Z, then I unplug Target 1 and assign Target 2 also a drive letter of Z, when I unplug Target 2 and plug Target 1 back in Windows won't remember that it had a drive letter of Z and will automatically assign it the next available slot. Do I have that right? I prefer assigning drive letters so I can keep my backups grouped together in the second half of the alphabet so I don't confuse them with my working drives/source drives. I currently have ten backup drives total between the backup set on site (5 drives) and the backup set stored for the month off site (another 5 drives), so if I'm understanding you correctly then I need to use a unique letter for each of the ten drives which puts my backup drives on drive letters Q-Z to fit them all in since Target 1 & Target 2 can't both be assigned the same drive letter. Am I on the right track?

When I clone a drive, Macrium will assign the cloned Target 1 drive the same volume label as the source disk. If the source disk was called Photo 1, I can't have my cloned drive called Backup - Photo 1 to distinguish it from the source drive. Macrium does not currently have this functionality (that I very much want!), but they are aware that people are requesting it. Is there a way to run a script at the end of a clone operation to rename a target volume after the clone operation is done? Even with my backup drives assigned letters in the second half of the alphabet, I'm still worried about accidentally confusing which is my working drive one day and then cloning over that day's work because the work was saved on the backup by mistake; it's unlikely, but I'd prefer to eliminate the risk. If that happened I would still have the versioned copy in the cloud, but I may not immediately notice my mistake the next day when I start working on a different set of files that don't immediately overlap with the previous day's work and then restoring the missing work would be complicated. The ability to rename a target volume after cloning is huge. I would love to see this functionality sometime soon. Is there another way besides running a script to pull this off? Is there a place I can add my enhancement request to the pile?

Thanks again! You're extremely clear and helpful, and I appreciate the time you put into responding.

- Tom

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Happy to help!  In terms of your additional questions:

If the destination isn't available at the time a clone job fires, the job fails with an error that the destination wasn't available. And the Log tab will show a job log with a failure result. There's no preflight check or warning before a Reflect job runs.  In terms of notifications, Reflect will show the Windows "toast" style notifications when a job starts and finishes, but otherwise you don't have any notification options for clones.  Backups (image and F&F backups) have email notification options, but those aren't available for clones today.  That will be coming with Reflect V8 though.  But if one of your targets will only be connected once per month, I wouldn't recommend setting up a daily schedule for that job.  You could set a monthly schedule if you're that precise about exactly when the off-site disk will be connected, or (the solution I'd recommend) you could just keep that definition file in Reflect with no formal schedule at all and just run the job on a purely manual basis.  If you're already going through the manual effort of bringing a disk back from an off-site location, it seems likely that you'd remember to actually run a clone job to it, so a purely manual routine there doesn't seem like a problem unless I'm missing something here.

The unique identifier isn't unique to the disk at a hardware level.  It's an identifier that gets randomly generated whenever a disk is initialized.  If you were to "clean" the entire disk, i.e. to mark the entire disk as empty (which is different from just formatting a partition), then when you initialized the disk again as either MBR or GPT, you'd get a new identifier.  But if you want to see the identifiers, the screenshots below show you where you can view them in Reflect, one from the "Create a backup" tab that shows your currently connected disks, and the other showing the identifiers within the settings of a clone job definition file.  GPT identifiers use a different format from MBR identifiers, and my screenshots show one of each in both places.  A note on the identifier style for MBR disks.  Reflect shows that identifier in hex, but at least some Windows tools show that same identifier in decimal.  So if you were to look at the same disk through Windows tools, it would look different.

One other thing to be aware of: If you ever do install one of your clone disks as the new "primary" disk, you will now have a clone job -- possibly with a schedule associated with it -- that still specifies your new primary disk as the destination of the clone job.  That will not be what you want in that situation, of course.  Fortunately though, those jobs will fail because Reflect won't be able to take that disk offline while Windows is running from it.  But you will have to edit your definition files if you want to proceed with clone jobs in that scenario in order to make your former destination disk your new source.

You're correct about how Windows handles drive letters.  But if you're dealing with 10 disks, that's a large chunk of the alphabet. In that case you might want to enlist the assistance of another application that I use for a client, called USB Drive Letter Manager.  It's free for personal use and inexpensive for commercial use.  Despite the name, it works with disks other than USB and can do a whole lot more than manage drive letters, but I'm only using it for what the name implies.  It can be configured to assign drive letters in all sorts of ways, but in my use case that might appeal to you, I have it set so that whenever a new USB disk is connected, it checks all volumes on that disk for a file at a specified path, in my case \DriveLetter.ini.  If it finds that file, it reads that file and then assigns that volume the drive letter stored in that file.  And then on all 9 disks in my client's backup disk rotation, I have an identical copy of that file saying that the volume should be assigned drive letter Z.  As long as I don't have more than one of those disks connected at a time, each disk will be Z when connected.  And if I ever DO have more than one disk connected, disks after the first one just get the default "next available" assignment for that specific occasion -- but if that disk were subsequently connected on it own, it would be Z again.  The catch in your case will be that you're dealing with clone disks, not image backup disks, which means the only way for that type of file to get there would be if it also existed on the source.  Having USBDLM look only at USB disks rather than SATA/RAID disks might allow you to create this type of drive letter file on your source disk so that it ends up on all of the destination disks and USBDLM only ever reads it when it exists on those USB disks.  Otherwise, there are other ways you can have USBDLM assign letters.  The documentation for that application is pretty good.

In terms of post-clone volume label changes, you could achieve that with a script.  Reflect will even generate a script based on a definition file if you right-click the definition file and select "Generate [PowerShell/VBS] Script".  In the wizard that pops up you'll even see some options to customize pre- and post-job operations, such as running an application before and/or after the job.  But even if you don't use any of that, if you know PowerShell or VBS, you can simply customize the script that Reflect generates in order to add the desired functionality.  Then you'd associate your schedules and manual executions with the script rather than the definition file.  When the script runs, among its operations will be calling Reflect to run the linked definition file, but you can also have it do other things before and/or after.  The trick will be making sure you target the correct partition for volume label changes.  If you have some way to guarantee drive letter assignment of the clone target, you could use that, e.g. "Change the volume label of drive Z to [whatever]".  The other option that occurred to me was to use the unique volume identifier.  Just like whole disks have unique identifiers, so too do individual volumes.  But those get regenerated every time the volume is formatted, and I'm not sure what happens with a clone.  I can't test this at the moment, but I suspect that in a clone scenario, Reflect might regenerate the volume ID of the target because Windows may not allow two volumes with the same ID to be mounted at the same time.  That would be a problem in a case like this since there would be no way to know what the volume identifier will be after a clone.  But I'll tell you what. If you figure out a way to get consistent drive letter assignment to your clone targets, then I will help you with the scripting piece.  I know a bit of PowerShell, and a command that says, "Rename drive Z to [this]" would be pretty simple.

Here are the screenshots I mentioned earlier showing the unique identifiers of GPT and MBR disks. Enjoy! Smile



Edited 24 December 2020 12:24 AM by jphughan
tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
So the toast style warning will pop up when the cloning happens and then disappear, but there won't be any lingering notification if a job fails unless I look in the log tab? I'll be asleep when the clone job runs, so toast notifications aren't an issue, but failed job notifications would be annoying, but it doesn't sound like there will be any.

When I go to my off-site storage I swap the five backup drives that I've had running for the last 30 days with the ones that have been sitting in storage and the out-of-date drives take their place for the next 30 days. For instance, the Target 1 set of drives will be used for say January and the Target 2 set for February, and then in March I'll go back and swap those out for the Target 1 set again for all of March. Should I make the definition files all run every night even if only half of the expected targets are attached at any one time? Or would it be better to modify the XML files at the start of each month so only half of them run? I'm assuming definition files be modified once they've been created.

Good reminder on revising definitions if a clone ever needs to swap in to be my primary working drive. Only one of my five main drives has Windows running on it, so it would definitely have been an issue if I hadn't remembered to do that; though if I am swapping in a clone for the source drive then the source drive is likely out of commission and unlikely to be connected going forward (and if it is it will have been re-initialized so Macrium won't recognize it because the Device ID will be different at that point, right?).

USB Drive Letter Manager is a great suggestion! I never would have found that on my own. Unfortunately, filtering by connection won't work for me: of my five source disks, two are Thunderbolt 3 RAID arrays (technically two partitions on a single four drive array), one is my internal M.2 SSD, and the last two drives are two partitions on a single USB 3.0 drive. All of the target drives are USB 3.0, so raid and M.2 should be easy to set up within USBDLM, but cloning the two USB drives to another USB drive poses a problem for assigning a drive letter after cloning.

I read through the manual and a few options stand out for designating the correct drives. First, do you think a Volume Serial Number or a Device ID would stick around on the Target disk after cloning or would it be replaced by the Source disk's values for those two things? Because that seems easy enough to set up if it would. The other option I came up with is that since I'm working with partitions on several of my backup drives I could make the partitions slightly odd sizes by a few hundred KB or MB to distinguish them from the original and use Drive Letters by Drive Size to assign drive letters.

Also, does USBDLM allow for and/or options so I could pair criteria for USBDLM to decide if a drive letter can be assigned or not? For instance, could I have it look at the volume label first, then if the label is what it's expecting (say Video 2) then the program would check the drive size and if that is also the expected value (say 7.9 TB instead of 8 TB like it is on the source drive) then it would assign the designated drive letter of V. Would that work?

And your offer to help with the PowerShell scripting is so kind. Thank you Smile

One concern I have with scripting regards when and how USBDLM kick in. After Macrium runs the clone what is the target drive's current drive letter: the one it had before the clone or the next available one Windows could assign? And does USBDLM kick in automatically after the clone to change the drive letter or does USBDLM need to be scripted to run after the clone job? Then, of course, after the correct drive letter has been assigned a script could run to assign the correct volume label based on the drive letter. But I think I'm a little confused about how drive letters are assigned during and after cloning, particularly once USBDLM is added into the mix.

And thank you for the screenshots! Is the unique ID there what the USBDLM manual referred to as a Volume Serial Number or is it a Device ID? I thought the two terms were the same thing, so I was surprised to find them separated out in the manual, which only made the screenshots all the more confusing. Haha.

But that said I'm starting to wrap my head around a game plan for how to set this up and that's thanks to you :

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok, I thought you had two disks here that were being swapped on a monthly basis.  But in fact you have TEN disks, and you want to use CLONING to ALL of them?  It’s unfortunate you’re not using image backups, because that would make all of this a whole lot easier. At my client that has the daily rotation of 9 disks, the entire image backup routine is managed by a single definition file that has a single schedule entry — Incremental backup every day — because they’re using an Incrementals Forever with Synthetic Fulls strategy.  And it works because the definition file just needs to target the Z drive each time, which USBDLM handles easily since the destination disks aren’t overwritten with image backups as occurs with clone backups.

I don’t know if USBDLM allows you to “chain” rules together so that it only assigns a letter if all of the criteria are met. I suppose you could give it a try by combining multiple rules as shown in the documentation examples and seeing whether it only matches when ALL conditions are met or when ANY conditions are met.

If you need to clone USB to USB in some cases, I agree that poses a challenge for USBDLM. In terms of solutions, I’m not entirely sure what happens to volume identifiers in a clone scenario. My guess is that the first time you clone Volume A (with Volume ID A) over to Volume B, you will find that Volume B has new Volume ID B, not the same ID as Volume A.  But going forward, if subsequent clones can use Reflect’s Rapid Delta Clone feature, then new Volume ID B will be retained, rather than you getting a new volume ID on the target every time. On that subject, if you use the partition size method, make sure the target is still at least as large as the source. Rapid Delta Clone can’t be used when the target is smaller than the source, and that capability can be a huge time saver depending on the amount of data you’re cloning.

In terms of post-clone drive letter assignment, when a clone completes the volume gets mounted for general use again (after having been taken offline so that Reflect gets exclusive access to it during cloning), and at that point what happens would be the same as what would happen if you had just connected that disk after having it disconnected. So without any other influences, Windows would assign that volume a drive letter however it would have otherwise. Or if you have USBDLM, then it will see that a new volume has appeared and then determine if it’s supposed to take any action on it based on the characteristics of the device/volume and your USBDLM configuration. In my scripting offer, the assumption was that you would have set up a routine whereby any time you connected a disk or finished a clone to that disk, it would get assigned a specific, predictable drive letter. And in that case, then the PowerShell script can just say, “Assign drive Z this volume label.”

As for my screenshot, Volume Serial Number, and Device ID, those are all different things. The Disk ID shown in Reflect applies to the entire disk. The Volume Serial Number is randomly generated when a volume is created and can be found using the “vol” command shown in the USBDLM manual. But that’s actually different from the volume unique identifier that I referred to above and that Reflect can use for identifying destinations for image backup jobs (so that drive letters aren’t a factor), which you can see in Reflect by clicking a specific partition and checking immediately underneath the “Details” heading in the navigation column along the left edge. The Device ID is a hardware-level identifier that does NOT change, but it’s also unique per PRODUCT, not per unique device — so if you had two identical WD USB 3.0 external drives, they’d have the same Device ID. And those are found on every type of product, not just storage devices.

I think you may need to experiment a bit here to see what happens with volume identifiers and Volume Serial Numbers after an initial clone and then after subsequent clones that use Rapid Delta Clone. If you find that either of them does NOT change when RDC was used, that may give you a good solution here, because if RDC can be used, then for the most part it will always be possible to use it. Swapping to a new source disk would likely throw a wrench into the works there, but those occasions are unlikely and presumably infrequent enough that it could still make sense to perform drive letter assignment based on something that you’ve found “survives” RDC cloning. If you ever encounter a situation where RDC couldn’t be used and therefore get a new volume serial number and/ or unique identifier, then the only thing that breaks is drive letter assignment. That wouldn’t be the end of the world, and typically after the first clone that couldn’t use RDC, subsequent clones would be able to again — unless there’s a condition that will always prevent RDC from being used, such as cloning to a partition that’s smaller than the source (regardless of how much space is being used) or cloning non-NTFS partitions.
tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
Sounds good! I'll play around with it this week to see how I can make drive letters stick and let you know how it goes.
tgwilkinson
tgwilkinson
New Member
New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)New Member (12 reputation)
Group: Forum Members
Posts: 11, Visits: 60
I setup USBDLM today. I have it using DeviceID to assign drive letters. I read a cybersecurity company's article that said DeviceID is written into the firmware of the HDD, which should mean it will stick around after cloning. Now I just need to test that theory.

I went to test it today with Macrium, and I was reminded of the other problem I kept running into with cloning using Macrium. One of my backup target drives is 14 TB and, using partitions on that 14 TB drive, it's supposed to serve as the backup drive for four separate hard drives -- two are 2 TB M.2 internal SSDs and two are 3-6 TB partitions on a single USB drive (so the source is three physical drives total going to a single physical target drive with four partitions).

But when I go to clone the source partitions, Macrium wants to make all new partitions on the target drive (as shown in the first and second images below). I cannot figure out how to make Macrium clone the source partitions and drives onto the already existing partitions I made for them. The sizes match perfectly down to the byte, but the program doesn't want to play nice.

In the example from the pictures below, how do I make E: Music 1 clone onto U: Music 1 (one of the middle partitions)? At the moment, it seems like Macrium will only allow me to clone E: Music 1 to either the first partition (SSmile, which it will resize to make that work, which doesn't make any sense to me because U: Music 1 is the perfect size for it and I can't figure out why Macrium wouldn't default to the perfectly sized available option.

Since that wasn't working I decided to try another option and clone both partitions on the source drive (E: Music 1 & H: Video 1) to see what would happen and (as you can see in the third image) Macrium would then decide to erase all three pre-existing partitions on my target drive and start from scratch with a partition labelled S: and a second partition which will be auto-assigned a drive letter.

How can I set up my clone job/definition file so Macrium is cloning to the correct partition with E: Music 1 going to U: Music 1? And how can I set it up so that I'll later be able to clone all four partitions/drives to this one physical target drive partitioned into four?

(note: the gap, the unassigned drive space of 1.82 TB in that first image is to backup a drive that doesn't exist yet. It'll be labelled T9 SSD 2, so that's why it's positioned there, but again the source drive doesn't exist yet, so I didn't see the point of creating the extra backup drive (TSmile just yet. Just trying to futureproof wherever possible).






GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search