Cloning a Drive in Linux via Commands: Difference between revisions

wiki.TerraBase.info
Jump to navigation Jump to search
Created page with " BackUp the Source Drive Structure: <code>sgdisk --backup=WhatEverFileName.bak /dev/WhatEverSDx</code> Restore to the Destination Drive: <code>sgdisk --load-backup=WhatEverFileName.bak /dev/WhatEverSDy</code> Re-Read Drive Information on the Destination System: partprobe /dev/WhatEverSDy If this error occurs: "Not all of the space available to /dev/sdc appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current..."
 
mNo edit summary
Line 1: Line 1:


It's been a long journey.  A lot of software and methods have been tried over the years.  All of them work, but with varying degrees of difficulty.
Wait, let's back up (so to speak) and lay out the objective: A Bare Metal Recovery Methodology that allows for the complete backup of an entire Rocky Linux OS based on a 'live / running' Source Drive that can then be restored on a Destination or Target Drive.
Here we go...
=== Premise and Circumstances ===
None of this works unless the drive structure has been set up properly.  In this instance, things are about as plain and simple as it gets.  A single GPT Partitioned Drive with the ROOT File System as EXT4 on an LVM Partition (has to be on an LVM Partition to allow for 'SnapShots').
Below is the Example Drive;<syntaxhighlight lang="text">nvme1n1                    259:2    0 238.5G  0 disk
├─nvme1n1p1                259:3    0    1G  0 part /boot/efi
├─nvme1n1p2                259:4    0    4G  0 part /boot
├─nvme1n1p3                259:5    0  128G  0 part
│ └─VG.NVMe.P3-LV.ROOT      253:0    0    64G  0 lvm  /
├─nvme1n1p4                259:6    0    80G  0 part
│ └─VG.NVMe.P4-LV.Storage  253:1    0    60G  0 lvm  /mnt/NVMEx1
└─nvme1n1p5                259:7    0    20G  0 part [SWAP]</syntaxhighlight>
=== The Steps ===
==== Step(s) 1 - BackUp ====
* BackUp the Source Drive Structure: <code>sgdisk --backup=nvme1n1.bak /dev/nvme1n1</code>
* BackUp each of the Partitions;
** nvme1n1p1:<code>dd if=/dev/nvme1n1p1 of=/BackUps/nvme1n1p1 bs=64M iflag=fullblock status=progress conv=noerror,sync,fsync</code>
==== Step(s) 2 -  Restoration ====


BackUp the Source Drive Structure: <code>sgdisk --backup=WhatEverFileName.bak /dev/WhatEverSDx</code>


Restore to the Destination Drive: <code>sgdisk --load-backup=WhatEverFileName.bak /dev/WhatEverSDy</code>
Restore to the Destination Drive: <code>sgdisk --load-backup=WhatEverFileName.bak /dev/WhatEverSDy</code>

Revision as of 19:19, 22 February 2026

It's been a long journey. A lot of software and methods have been tried over the years. All of them work, but with varying degrees of difficulty.

Wait, let's back up (so to speak) and lay out the objective: A Bare Metal Recovery Methodology that allows for the complete backup of an entire Rocky Linux OS based on a 'live / running' Source Drive that can then be restored on a Destination or Target Drive.

Here we go...

Premise and Circumstances

None of this works unless the drive structure has been set up properly. In this instance, things are about as plain and simple as it gets. A single GPT Partitioned Drive with the ROOT File System as EXT4 on an LVM Partition (has to be on an LVM Partition to allow for 'SnapShots').

Below is the Example Drive;

nvme1n1                     259:2    0 238.5G  0 disk 
├─nvme1n1p1                 259:3    0     1G  0 part /boot/efi
├─nvme1n1p2                 259:4    0     4G  0 part /boot
├─nvme1n1p3                 259:5    0   128G  0 part 
│ └─VG.NVMe.P3-LV.ROOT      253:0    0    64G  0 lvm  /
├─nvme1n1p4                 259:6    0    80G  0 part 
│ └─VG.NVMe.P4-LV.Storage   253:1    0    60G  0 lvm  /mnt/NVMEx1
└─nvme1n1p5                 259:7    0    20G  0 part [SWAP]

The Steps

Step(s) 1 - BackUp

  • BackUp the Source Drive Structure: sgdisk --backup=nvme1n1.bak /dev/nvme1n1
  • BackUp each of the Partitions;
    • nvme1n1p1:dd if=/dev/nvme1n1p1 of=/BackUps/nvme1n1p1 bs=64M iflag=fullblock status=progress conv=noerror,sync,fsync


Step(s) 2 - Restoration

Restore to the Destination Drive: sgdisk --load-backup=WhatEverFileName.bak /dev/WhatEverSDy

Re-Read Drive Information on the Destination System: partprobe /dev/WhatEverSDy

If this error occurs: "Not all of the space available to /dev/sdc appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or

continue with the current setting?", it is probably because of a mismatch in size between the Source and Destination Drives Storage Capacity. Easy to fix with: parted /dev/SDy, print, Fix