Home› AOMEI Products Support

AMBackup clone equivalent to GUI?

JerrillJerrill
in AOMEI Products Support
I'm attempting to automate a weekly SSD clone operation using AMBackup via a PowerShell script that determines the drive index numbers of the active system SSD vs a spare identically sized SSD and configures the AMBackup command arguments appropriately, similar to the one below:

AMBackup /c /t disk /s 1 /d 0 /a /o yes

This mostly works! 

However, I see that the destination drive was converted from a GPT disk to an MBR disk as part of the operation. And when inspecting the partitions in the Windows Disk Management tool, while all are present, partitions like the EFI partition is converted to a standard partition, etc.

The manually-initiated, GUI-based clone operation in the AOMEI Backupper Pro performs an exact copy of the drive as desired.

Is there a way to configure the AMBackup CLI tool arguments to perform the SSD-to-SSD clone like the GUI does? Or alternately, what is the recommended strategy to automate a weekly clone of one SSD to another SSD such that should the first fail, the second is available for immediate operation without a recovery-from-image process?

Thank you!

Comments

  • aiArtisanaiArtisan
    edited August 2023
    Hello, I am aware of BackUpper (BU) commands, but I have little experience with it. Is there a way to use use BU Disk Signature UUID to script which disk to always clone?

  • adminadmin
    @Jerrill, "However, I see that the destination drive was converted from a GPT disk to an MBR disk as part of the operation. "---The source disk is MBR? or GPT?  If the source drive is MBR, target disk is GPT, and you want to keep the target disk as GPT after clone, please modify the /o as no.
    And, clone feature currently doesn't support schedule.
  • JerrillJerrill
    @aiArtisan - I'm sure there are multiple ways to figure out which disk to clone. I believe I have this problem solved though. There is an occasion where the drive that gets mounted as C: changes between the two drives regardless of the BIOS settings. I don't understand what that is yet (i.e. The current system drive became unbootable? Why?). So, selecting source and destination by UUID (or even model number) doesn't work, but is probably an improvement over my model number approach as far as whitelisting goes. So, when a drive stops booting, I just clone the working drive over to the other again and life stays good with just a couple of minutes of downtime. I've never cloned a unknowingly busted (or about-to-bust) disk image yet, but I know that is a risk. I have everything important in cloud storage so data loss isn't an issue. I just need one functioning system drive to boot. The clone operation is more or less just to keep installed software updates current on both the two drives. A RAID array doesn't really solve the problem of Windows occasionally self-destructing, so that's why I opted for the cloning regimen. 

    @Admin - No, both drives were GPT drives. I tried to clone the drive using the command line tools and the destination of the clone was spontaneously switched to an MBR drive. I was not expecting that at all. So I'm assuming there is some fundamental information about the command line tools that I don't have. I would really just like to know the correct command line args to duplicate the GUI-based clone operation as closely as possible using the command line tools and I'll give it another try and report back. Thanks!
  • aiArtisanaiArtisan
    edited August 2023
    "selecting source and destination by UUID (or even model number) doesn't work"
    Why?

    Great clone tool not from Aomei:
    Clonezilla - non-GUI cloning
    https://clonezilla.org/downloads.php
    If the source disk has Bad Sectors, use Expert Mode > "-rescue" option to continue cloning all readable sectors

  • aiArtisanaiArtisan
    Thank you Jerrill, you are clearly a more experienced technician than myself. I am asking how you tried that, or diagnosed that?

  • adminadmin
    @Jerrill, When the two disks both are GPT, please directly use: AMBackup /c /t disk /s 1 /d 0 /a
  • JerrillJerrill
    @AiArtisan - In my case I want whichever boots up as the C: drive to be the source disk. Unfortunately, that is not guaranteed to remain one disk or the other. So, I have a list of two model numbers that my script scans for, looking for which one is C:. Yes, UUID would work for this whitelist and would probably be a better approach. But selecting the source to always be one UUID or the other could be problematic.

    @Admin - Thank you for confirming I'm on the right track. I'll experiment with this in the weeks ahead and report back,  especially if the GPT/MBR change spontaneously happens again.


Sign In or Register to comment.