New Hard Drive migrate /Home

Dear all good morning,

I have to backup home and I’m not sure how to.

My current hard drive is failing and I must send it in for the warranty.
My home directory is in this hard drive (sdb) and my root directory is on an SSD (sda).

How can I backup my home directory to later restore it when I get a new hard drive?

This hard drive was not being detected sometimes when booting and when that happened, tumbleweed would not let me get into KDE space, it would get stuck on the login screen, based on this I would presume the restoration of the home directory would need to be done through CLI.

I was following this link making a tar backup but have no clue on how to restore it when I receive the new HDD. https://en.opensuse.org/SDB:Home_backup

linux-ecr9:/home/gabriel # fdisk -l
Disk /dev/sda: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 992A30F0-0077-4B91-9641-46640C199826

Device         Start       End   Sectors  Size Type
/dev/sda1       2048  14256127  14254080  6.8G Linux swap
/dev/sda2   14256128  14288895     32768   16M Microsoft reserved
/dev/sda3  161079296 162103295   1024000  500M EFI System
/dev/sda4  162103296 213657599  51554304 24.6G Linux filesystem
/dev/sda5  213657600 397977599 184320000 87.9G Microsoft basic data


Disk /dev/sdb: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: TOSHIBA HDWD120 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: A47C241A-97C3-4B5E-8384-165877E10E3C

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 3907029134 3907027087  1.8T Linux filesystem
gabriel@linux-ecr9:~> df -h | grep /home
/dev/sdb1       1.8T  324G  1.4T  19% /home

Thanks!

When you receive your new disk you have to format it with a filesystem (maybe the same type as your old disk, but this is not mandatory); you can do that on another system (say, by using an usb external enclosure) or just swapping it in the current system and either logging in as root via the command line (just append “3” to the boot command line at the GRUB menu) and working with CLI tools like parted or the like, or keeping a LiveDVD on hand and using the live system with GUI tools like GParted, YaST-Partitioner or what you like.
Then you have to edit /etc/fstab in your current system, to reflect the changes made; at least, the new /home partition should have a new UUID that must be in /etc/fstab for the system to mount /home correctly.
At that point reboot, log in as root in a terminal (for instance via CTRL+ALT+F1) and issue:

sudo tar zxvf /home/**myBackup.tgz** -C /

(pay attention, the line in the wiki for restore has a wrong filename).
Please note that the SDB page refers to backup and restore of a single user. Since you plan on swapping the entire disk, be careful and store the backup file myBackup.tgz on another disk or media; you should change the commands accordingly, whenever /home/myBackup.tgz is mentioned. Also you have to repeat the procedure for every user on that /home/ disk, or backup the whole disk by changing the commands accordingly. Please ask if that is not trivial to you.

Hi Orso first thanks for putting in the time for such a detailed explanation!

I’m now waiting for this commando to complete, it is taking a long while but that is OK.

sudo tar cpzvf /home/myBackup.tgz --same-owner /home/gabriel/

I’m planning on copying myBackup.tgz into an external hard drive, and when I get the new hard drive back, I will format it into the same FS, EXT4, with the LiveDVD you mention through Yast partitioner, then copy myBackup.tgz into the drive and then issue the command replacing the text to match the location of the tgz file.

sudo tar zxvf /home/**myBackup.tgz** -C

Editing the /etc/fstab file seems pretty straightforward, I found the command sudo blkid lists all of the UUID on the system, so then I would need to copy and paste the appropriate UUID into fstab.

Please mind that “/” missing in your last line (possibly a copy/paste error), the correct form is:

sudo tar zxvf /home/myBackup.tgz -C /

Your plan seems good, just ask here in the Forums if needed.

Just a side question. What’s the advantage of using tar over dd in this case? I found out that dd also clones the UUID.

Apart from the fact that it is clear that dd copies everyting byte by byte, thus when there is a UUID represented in those bytes, it will be copied with the masses, I also wondered why a dd could not be used. As long as it is to a partition of exect the same size.

If you have two disks side by side you can use dd to clone the first onto the second, but if you need to send the failing disk for repair / swap you need something that just copies files somewhere in the meantime and you don’t have a spare partition to do that in general…

Until now I had the idea that we were talking about the copy of a file system on a partition, not about a disk.

In any case, you are correct, if you want to copy “the contents” (that is the files as they are in their tree structure) from one file system to another (of the same or different size and/or of the same or different type; well the size must be enough to get all files in it of course), you use tar (cp can do this also while keeping ownership and permissions).

When using dd on a partition, the end-result will be the same file system with the same size and the same contents, byte for byte, and then better should be copied to a partition of the same size (a smaller partition will give you I/O errors and a broken file system, a larger partition results in spoiled space and an unusual situation).
You could dd to a file on a file system large enough to accomodate such a large file (several GB?) and then later dd (back) to a partition. But because of the size that may not be an advisable way to go.

You can of course also dd a disk (whole disk). Then you will have it including the MBR with partition table, or the GPT and it’s copy and all and everyting. Again the output must be large enough. And when it is larger, you will not even see it as free space in your fstab listing.

BTW I am fully aware of the fact that for @OrsoBruno and others this is all very, very logical and well known. But I have the idea that sometimes people here are in doubt about what is a disk (mass-storage), what are partitions, what are file systems, what tools to use on what, etc.

dd copies the partition while tar archives the files on a partition:

erlangen:~ # df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  407G  258G  148G  64% /home
erlangen:~ # 

Cloning the partition with dd requires copying 407G. Using tar results in archiving 258G. With compression the resulting archive could even be substantially smaller. Archiving will be by far slower than cloning.

Indeed much much slower.
My tar of approximately 250 GB took almost 2 hours, unfortunately tar and gzip only use 1 core of the 8 I had available.

So, I have the tar backup ready and also backed up all made a duplicate backup outside of the tar of all important files such as photos. I places this tar and files on an external hard drive.

I’ll be formatting the defective HD today and will mail it tomorrow.

Uncompressed tar has some advantage over dd:

erlangen:~ # time tar -cf /HDD/archive.tar /home

real    **33m42.467s**
user    1m23.644s
sys     10m45.208s

erlangen:~ # dd if=/dev/nvme0n1p3 of=/HDD/archive.iso bs=4M status=progress
443316961280 bytes (443 GB, 413 GiB) copied, 3416 s, 130 MB/s
105713+1 records in
105713+1 records out
443395604480 bytes (443 GB, 413 GiB) copied, **3416.58 s**, 130 MB/s
erlangen:~ # 

Copy speed is limited by disk write speed. While tar copies used data only dd needs to copy all data:

erlangen:~ # df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  407G  262G  144G  65% /home
erlangen:~ # 

Thanks Karl, I certainly learned something. Using tar for a proper compressed, efficient backup instead of a brute-force-cloning “backup”

All may have there advantages and disadvantages. When talking about backup it depends on the type of disaster one wants to prepare onselve, etc., etc.