linux:backup-clone:backup-clone-ssd
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| linux:backup-clone:backup-clone-ssd [2022/01/15 16:09] – external edit 127.0.0.1 | linux:backup-clone:backup-clone-ssd [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Backup or Clone HDD ====== | ||
| - | There are more then enough approaches to backup or clone a SD card. I prefer to use one of the following two approaches: | ||
| - | - Creating a raw diskimage using dd | ||
| - | * Relatively easy | ||
| - | * Makes a diskimage of the complete diskspace, including not used / empty disk space | ||
| - | * Results in a large image. | ||
| - | * Relatively slow. | ||
| - | * Can only be restored on disk with identical of larger size | ||
| - | - Creating a file and partition based disk image | ||
| - | * Takes a bit more steps | ||
| - | * Makes a diskimage of only the used diskspace, including only used data (files). | ||
| - | * Results in a small image. | ||
| - | * Relatively fast. | ||
| - | * Can be restored on smaller disks | ||
| - | ===== GPT vs MBR ===== | ||
| - | GPT stands for Globally Unique Identifier (GUID) Partition Table, which is a standard for the layout of the partition table on a physical hard disk. GPT is gradually replacing the old MBR (Master Boot Record) standard, which has some limitations that only supports hard disk up to 2TB in size, and up to four primary partitions. | ||
| - | * GPT supports hard drive lager than 2TB. | ||
| - | * Windows can only boot from GPT on a UEFI-based computers. | ||
| - | * Unlike MBR, GPT hard disk allows you to create primary partitions up to 128 due to system limitations. | ||
| - | * GPT disks only support 64-bit Windows system while MBR disks support both 32-bit and 64-bit Windows | ||
| - | Identify Partition Table type using gdisk (or fdisk): | ||
| - | # gdisk -l / | ||
| - | Output should show something similar to: | ||
| - | < | ||
| - | Partition table scan: | ||
| - | MBR: protective | ||
| - | BSD: not present | ||
| - | APM: not present | ||
| - | GPT: present | ||
| - | Found valid GPT with protective MBR; using GPT. | ||
| - | </ | ||
| - | Or with fdisk: | ||
| - | # fdisk -l /dev/sda | ||
| - | For MBR partition types, output should show something similar to: | ||
| - | < | ||
| - | Disk /dev/sda: 953,9 GiB, 1024209543168 bytes, 2000409264 sectors | ||
| - | Disk model: Samsung SSD 850 | ||
| - | * * * | ||
| - | Disklabel type: dos | ||
| - | </ | ||
| - | For GPT partition types, output should show something similar to: | ||
| - | < | ||
| - | Disk /dev/sda: 953,9 GiB, 1024209543168 bytes, 2000409264 sectors | ||
| - | Disk model: Samsung SSD 850 | ||
| - | * * * | ||
| - | Disklabel type: gpt | ||
| - | </ | ||
| - | |||
| - | ===== Be aware of UUID ===== | ||
| - | UUIDs are not hardware-specific but stored in the partition' | ||
| - | However recreating the partitions manually on the new disk (e.g. smaller disk), will result in new UUID. This could result in problems when booting the new disk uses UUID in fstab. | ||
| - | < | ||
| - | cat /etc/fstab | ||
| - | # /etc/fstab: static file system information. | ||
| - | # <file system> <mount point> | ||
| - | # / was on /dev/sda3 during installation | ||
| - | UUID=b2fa29ee-670f-4d44-becc-d9ec368d4a41 / | ||
| - | </ | ||
| - | This can be solved by either changing the entries in fstab to the old style: /dev/dbX, Or by getting the new UUID and update fstab accordingy: | ||
| - | < | ||
| - | # blkid /dev/sdb1 | ||
| - | /dev/sdb1: UUID=" | ||
| - | </ | ||
| - | |||
| - | ===== MBR Explained ===== | ||
| - | A master boot record (MBR) is the 512-byte boot sector that is the first sector of a partitioned data storage device of a hard disk. The total size is 512 bytes (446 + 64 + 2 = 512). Where, | ||
| - | 446 bytes – Bootstrap. | ||
| - | 64 bytes – Partition table. | ||
| - | 2 bytes – Signature. | ||
| - | |||
| - | ==== Backup MBR ==== | ||
| - | Next command will copy 512 bytes (MBR) from disk sdX to a backup file: | ||
| - | < | ||
| - | # dd if=/dev/sdX of=mbr.backup.img bs=512 count=1 | ||
| - | </ | ||
| - | ==== Restore MBR ==== | ||
| - | === For disks with identical partitions and size: === | ||
| - | Use 512 bytes to overwrite or restore your /dev/sdX the full MBR (which contains both boot code and the drive’s partition table) with the contents of mbr.backup.file. | ||
| - | < | ||
| - | # dd if=/ | ||
| - | </ | ||
| - | |||
| - | === For disks with different partitions and size: === | ||
| - | Use 446 bytes to overwrite or restore your /dev/sdX MBR boot code only with the contents of mbr.backup.file. This will preserve the partitioning schema. | ||
| - | < | ||
| - | # dd if=/ | ||
| - | </ | ||
| - | |||
| - | ===== Find HDD block device ===== | ||
| - | Fist step is to figure out which device is our SD Card. Use the ' | ||
| - | < | ||
| - | sudo lsblk -o NAME, | ||
| - | </ | ||
| - | This should give an output similar to the following, illustrating that the SD card is connected to /dev/sdb: | ||
| - | < | ||
| - | AME | ||
| - | sda | ||
| - | ├─sda1 ntfs | ||
| - | ├─sda2 ntfs 69,9G WINDOWS 7 | ||
| - | ├─sda3 ext4 | ||
| - | └─sda4 swap 9,2G [SWAP] | ||
| - | sdb 29,8G | ||
| - | ├─sdb1 ext4 28,9G | ||
| - | └─sdb2 swap | ||
| - | </ | ||
| - | ===== Backup using dd ===== | ||
| - | This will only work for restoring to a larger or identical size disk. | ||
| - | Backup image will be very large as well. | ||
| - | ==== Create Backup Image ==== | ||
| - | < | ||
| - | dd bs=4M if=/dev/sdb | gzip > image.gz | ||
| - | </ | ||
| - | ==== Restore Backup Image ==== | ||
| - | < | ||
| - | gzip -dc image.gz | dd bs=4M of=/dev/sdb | ||
| - | sync | ||
| - | </ | ||
| - | ==== Monitor Progress ==== | ||
| - | Using dd for large SD cards could be quite lengthy. E.g. a 32Gb card could take up to 20 minutes to read. Use the following steps to watch the progress. First, find out the process id of the dd process by running the following in the new virtual terminal. | ||
| - | < | ||
| - | $ pgrep -l ' | ||
| - | 8789 dd | ||
| - | $ | ||
| - | </ | ||
| - | This shows that the running dd proces has proces Id 8789. The dd process will print out the current statistics when it receives an user signal (USR1). To send the USR1 signal to the dd process: | ||
| - | < | ||
| - | $ kill -USR1 8789 | ||
| - | $ | ||
| - | </ | ||
| - | Note that as soon as the USR1 signal is detected, dd will print out the current statistics to its STDERR. | ||
| - | < | ||
| - | $ dd if=/ | ||
| - | 0+14 records in | ||
| - | 0+14 records out | ||
| - | 204 bytes (204 B) copied, 24.92 seconds, 0.0 kB/s | ||
| - | </ | ||
| - | After reporting the status, dd will resume copying. You can repeat the above kill command any time you want to see the interim statistics. Alternatively, | ||
| - | < | ||
| - | $ watch -n 10 kill -USR1 8789 | ||
| - | </ | ||
| - | ===== Backup HDD using files archive ===== | ||
| - | This approach will work for restoring to smaller disks and will result in a minimal sized image. It consist of the following steps: | ||
| - | |||
| - | Backup: | ||
| - | * Save the partition table structure of the SD card | ||
| - | * Save the MBR | ||
| - | * Mount and save the files for each partition in an individual archive | ||
| - | Restore: | ||
| - | * Create the partitions on the new HDD card | ||
| - | * Restore the MBR to new HDD card | ||
| - | * Mount and restore the files in the partitions | ||
| - | |||
| - | Use **lsblk** to figure out the block device of the HDD card. | ||
| - | ==== Save Partition Table Structure ==== | ||
| - | Save the partition table/ | ||
| - | < | ||
| - | sudo sfdisk -d /dev/sdX > part_table | ||
| - | </ | ||
| - | ==== Save the MBR ==== | ||
| - | < | ||
| - | # dd if=/dev/sdX of=mbr.backup.img bs=512 count=1 | ||
| - | </ | ||
| - | ==== Backup the partition data ==== | ||
| - | For each of the partitions do (use the correct fs-type): | ||
| - | < | ||
| - | # umount /dev/sdX1 | ||
| - | # mkdir / | ||
| - | # mount -t ext4 /dev/sdX1 / | ||
| - | # tar -zcvf image-sdX1.tgz / | ||
| - | </ | ||
| - | ==== Restore Partition Table Structure ==== | ||
| - | Restore the partition table/ | ||
| - | < | ||
| - | sudo sfdisk /dev/sdX < part_table | ||
| - | </ | ||
| - | Now we have the empty partitions that needs to be formated. | ||
| - | < | ||
| - | sudo umount /dev/sdbX | ||
| - | sudo mkfs.ext4 -l root /dev/sdbX | ||
| - | </ | ||
| - | ==== Restore the MBR ==== | ||
| - | See explanation on MBR above. For disks with identical partitions and size: | ||
| - | < | ||
| - | # dd if=/ | ||
| - | </ | ||
| - | For disks with different partitions and size: | ||
| - | < | ||
| - | # dd if=/ | ||
| - | </ | ||
| - | ==== Restore the partition data ==== | ||
| - | Let's mount both partitions and restore the files back on the volumes. The absolute path is stored in the tar file and used to restore the files. It is therefore important that the partition is mounted in the same location as it was done while making the backup. And that you execute at /. | ||
| - | < | ||
| - | # mount -t ext4 /dev/sdX1 / | ||
| - | </ | ||
| - | Now restore the files to the partitions. | ||
| - | < | ||
| - | cd / | ||
| - | sudo tar -zxvf image-sdX1.tgz | ||
| - | </ | ||
| - | |||
linux/backup-clone/backup-clone-ssd.1642262977.txt.gz · Last modified: by 127.0.0.1