1 |
On Friday, 24 August 2018 09:32:23 BST Philip Webb wrote: |
2 |
> I want to make a copy of a partition which I can use to replace it, |
3 |
> if some catastrophe damages the partition or wipes it out ; |
4 |
> it needs to be byte-byte identical, incl all permissions. |
5 |
|
6 |
You are looking to clone a partition. This is a bit by bit identical copy of |
7 |
the original partition. You could clone a partition into another, so you end |
8 |
up with two identical partitions including their boot record, fs and contents, |
9 |
or save the cloned partition into an image file. |
10 |
|
11 |
However, you may prefer to use clonezilla instead of dd. The dd command will |
12 |
copy each and every bit and byte of the partition whether it has data on it or |
13 |
not. It is not particularly efficient. Clonezilla will perform better at |
14 |
this task. |
15 |
|
16 |
Personally, I would only keep a back up of the filesystem contents with e.g. |
17 |
rsync, and reformat the partition and restore its contents in the case of a |
18 |
disaster recovery scenario. I would prefer a fs backup, especially in the |
19 |
case of a USB stick being the backup storage media. This is because rsync |
20 |
will only copy data which has changed since the last backup, rather than |
21 |
overwriting what is on the USB already. I expect using something like dd |
22 |
repeatedly will reduce considerably the life of the USB stick. |
23 |
|
24 |
|
25 |
> Can I use 'dd' ? -- eg 'dd if=/mnt/xxx of=/mnt/yyy', |
26 |
> where the partition has been mounted at /mnt/xxx |
27 |
> & a USB stick has been mounted at /mnt/yyy . Will that do the job ? |
28 |
|
29 |
Not like that. If you intend to create a clone of the partition, rather than |
30 |
its filesystem, you need to copy the whole block device, not its mount point. |
31 |
|
32 |
dd if=/dev/sdXx of=/media/$USER/<LABEL>/clone_of_sdXx.img bs=4096 |
33 |
conv=notrunc,fsync status=progress |
34 |
|
35 |
Where /media/$USER/<LABEL>/ is assumed to be the mountpoint of your mounted |
36 |
USB storage device. The above will save an image file of the cloned partition |
37 |
as 'clone_of_sdXx.img' within the existing filesystem of the USB stick. You |
38 |
could then copy this partition image to a secondary storage if you wish, |
39 |
encrypt it, compress it, etc. |
40 |
|
41 |
You'll be able to mount this image with '-o loop' and examing or use its |
42 |
contents. |
43 |
|
44 |
mount /media/$USER/<LABEL>/clone_of_sdXx.img /mnt/My_partition_image -o loop |
45 |
|
46 |
ls -l /mnt/My_partition_image |
47 |
|
48 |
|
49 |
To create a full partition clone on the USB stick rather than an image file |
50 |
change the of= operand into the block device your USB stick is recognised as; |
51 |
e.g. |
52 |
|
53 |
dd if=/dev/sdXx of=/dev/sdYy bs=4096 conv=notrunc,fsync status=progress |
54 |
|
55 |
CAUTION: If you get /dev/sdYy wrong you *will* lose data on the device you |
56 |
overwrite. |
57 |
|
58 |
You may have problems when you try to mount the cloned USB stick with the |
59 |
original partition in place, because they will both have identical filesystem |
60 |
UUIDs. I haven't tried this to know what errors it may produce. |
61 |
|
62 |
|
63 |
> There seems also to be an issue re 'bs=<some number of bytes>' : |
64 |
> what size is best ? i plan to use USB 3.0 for quicker copying. |
65 |
|
66 |
You can test what block size will transfer data faster on your particular |
67 |
hardware setup. I assume in the example below the I/O bottleneck is your USB, |
68 |
rather than your HDD. |
69 |
|
70 |
dd if=/dev/zero of=/media/$USER/<LABEL>/testfile bs=1024 count=1000000 |
71 |
|
72 |
rm /media/$USER/<LABEL>/testfile && sync |
73 |
|
74 |
dd if=/dev/zero of=/media/$USER/<LABEL>/testfile bs=2048 count=500000 |
75 |
|
76 |
rm /media/$USER/<LABEL>/testfile && sync |
77 |
|
78 |
and so on, each time increasing the bs to 4096, 8192, ... and halving the |
79 |
count to copy the same amount of data. You will soon find the transfer speed |
80 |
arrives at a peak and then reduces when an I/O bottleneck is reached. In the |
81 |
above example I have used a 1GB file, but you may want to increase this to a |
82 |
larger size to make sure you saturate your buffers. |
83 |
|
84 |
|
85 |
> Does it matter how the USB stick is formatted ? |
86 |
> Can I use a raw stick with the usual default VFAT formatting ? |
87 |
> Might it be better to replace that with a Linux FS, eg Ext2 ? |
88 |
|
89 |
If you are using the USB stick to save an image file to it, then you will come |
90 |
across the VFAT file size limit of 4GB. So, use exFAT, or ext2. |
91 |
|
92 |
If you are using a USB stick to create a partition clone it doesn't matter |
93 |
what the USB fs type is. It will be replaced with that of the original |
94 |
partition. |
95 |
|
96 |
HTH. |
97 |
-- |
98 |
Regards, |
99 |
Mick |