There is a lot of approaches, ways and tools to backup/clone one's hard drive. For instance, gparted allows to copy/paste the whole partitions, Disks can create and restore drive image. There are dedicated tools like CloneZilla and whatnot.
I would like just remind simple workflow which requires standard CLI tools.
Prerequisites
Live bootable CD/DVD/USB Ubuntu Mate installation media.
Hard drive to accommodate original (source) hard drive copy. Obviously, target HD must be equal or larger than source HD in size, i.e. storage capacity.
Preparations
If your target drive is not removable external USB drive, then it has to be inserted into your PC before you proceed.
Boot your system from live installation media and select 'trial' mode.
Connect your external USB drive.
Invoke Mate terminal.
Execute sudo su command to switch to superuser mode.
Identify your source and target drives.
For example:
root@ubuntu:~#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 55,9G 0 part
├─sda4 8:4 0 1K 0 part
├─sda5 8:5 0 7,5G 0 part
└─sda6 8:6 0 402,4G 0 part
sdb 8:16 0 465,8G 0 disk
...
That is my source drive is /dev/sda and my target drive is /dev/sdb
Procedure
Execute the following command using identified source and target drives' names: dd if=<source> of=<target> bs=2M status=progress.
For example, dd if=/dev/sda of=/dev/sdb bs=2M status=progress
Depending on your computer specs the cloning process can take from minutes to hours.
Result
The target disk is exact copy of the source disk. It can be used to
boot your system from;
restore (create) new bootable drive in case of the source disk irrecovable failure; (just follow the described procedure using cloned drive as the source drive);
restore accidentally deleted files (see below).
Notes
Probably, cloning the whole disk often, each and every time is an overkill. As an option you can mount cloned disk and synchronize files in user's home directory. There is no need to boot from live installation media. Here is how I do that, provided that my home directory is on a separate /dev/sdb6 partition:
sudo su
mount /dev/sdb6 /mnt/backup
rsync -a --delete /home/ugnvs/ /mnt/backup/ugnvs
umount /mnt/backup
Similarly, one can mount cloned drive, find and restore accidentally deleted files.
Thank you, Eugene. I completely agree with the simplicity and feasibility of that traditional approach.
The only concern I have is with the fact that the low-level "badblock" sectors and map would not be identical to both drives. (I don't know enough about whether such a bit-by-bit mirroring would lose the factory/mkfs "real" badblocks map for the clone.)
What would be the least intensive (and time-consuming) method to perform a comparison that would ensure that data was not written to a "badblock" on the second drive ?
Or are the drives (and OS drivers) now smart enough to automatically deal with that detection (tracking, block re-mapping) during the mirroring process involving the "dd" transfer?
My understanding, from postings (possibly here or StackOverflow) is that people in "production" roles never use a disk until they've run the badblocks option to ensure that those rare cases on brand new disks are not overlooked, and only "goodblocks" are made available for write actions.
When I was in the business, I had the benefit of not doing the scan because others provided me with disks that were manually scanned for such badblocks, so those two examples suggest that it would be a "necessary" first step.
Given that, would you not recommend doing the mirroring/cloning on a "partition by partition" basis, rather than "whole-disk" basis?
Quite frankly, I see no harm no benefit in backing up partitions. So to say, that depends.
My intent is to create a bootable cloned drive ready for use. Someone might prefer backup to image files. Somebody might like an idea of backing up one's documents and images only and does not hesitate to make fresh installs. That is only you can tell which approaches suit your purpose and which of them you like best.
You have actually raised a number of questions. I'll try to comment.
On the one hand, it is ensured by definition. A badblock can not be written to. That is, disk duplication terminates and emits error message when it fails to write to a badblock.
On the other hand, your question is quite correct because it follows the best information security practice which dictates that newly created backup is immediately verified for its integrity and validity.
Unfortunately, I have never seen nor heard of an easy and fast way (tool) to perform the task. (Enterprise-grade solutions aside, of course.)
rsync is not a repair tool. And yes, it can be used to compare (and synchronize) the contents of two directories (say, mount points for original and backup drives) using 'checksum' option. Another option to perform such a comparison is mtree utility which is not installed by default. Surely, there are more tools and procedures to perform the task. For instance, one can write script to walk directory trees and invoke 'cmp' command against files.
Obviously, these and similar tools operate at file level. That is not sufficient to verify the whole (cloned) disk integrity. Have a look at fsck command to check and repair a Linux filesystem as a whole.
Finally, please pay your attention to the 'badblocks' utility which is capable of scanning hard drives for bad sectors.
Hopefully, you find my comments satisfactory enough.
Thank you again, Eugene, for your detailed response.
While I understand that fsck (e2fsck) will flag bad blocks (update table and re-map such blocks) and repair structure of directories/files on clone disk, to my knowledge, such actions are disconnected from the source image (master disk) so that the directories/files on the clone may in fact be different from the master.
Given that, should the sequence be
clone using dd
compare partitions using rsync checksum comparison;
use fsck with badblocks check (since this operation, which should happen immediately after creating a new partition, did not happen because of the process used for cloning, namely bit-by-bit imaging using dd) ?
... OR ...
since the dd approach for cloning would fail if anywhere on the clone disk has bad blocks preventing the mirror (dd would abandon, unless you told it to ignore errors, which in my view is inadvisable), wouldn't you say that the process of building the mirror's structure from the ground up, namely
create partition table,
create partitions,
format partitions,
verify partitions,
make disk bootable, then
mirroring partition data using the user's non-dd preferred tool (tar, rsync, etc.)
be the method that is most likely to succeed for any non-raid context ?
No-no-no, I will not tell that some method should be preferred over another one. Drive-level backup and file-level backup are tried and tested methods and work well.
I like drive cloning because it creates exact bootable copy of my master drive in one pass. I like file copying because it is fast and allows selection of what has to be copied. And I use them both.
IMHO, fsck in the first proposed scenario serves no particular purpose and may be omitted.
To my taste, it is not mandatory to recreate partition structure in your second proposed scenario. At the same time I can imagine a situation when such a partitioning would be beneficial. By the way, you might want to add 'Make disk bootable' entry to the second scenario and the result of both proposed procedures would be virtually identical.
Your are correct that I should have noted the "bootable" step explicitly, though for myself, it was implicit as part of the attributes assigned during the make partitions.
I updated my earlier response to reflect that.
As for a preferred approach, I guess it depends on the context, but I personally can't visualize my using any approach other than the second one.
I am afraid that marking a partition as bootable one is not enough to make HD bootable. Next to it, 'grub' has to be reinstalled/recovered and '/etc/fstab' has to be updated to reflect new UUIDs of newly created partitions.
