Cloning a Drive in Linux via Commands: Difference between revisions
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 ==== | |||
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
- nvme1n1p1:
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