1 |
On Wednesday 30 Mar 2016 05:28:29 Meino.Cramer@×××.de wrote: |
2 |
> Mick <michaelkintzios@×××××.com> [16-03-30 03:56]: |
3 |
> > On Tuesday 29 Mar 2016 19:53:45 Meino.Cramer@×××.de wrote: |
4 |
> > > The real thing: |
5 |
> > > The usbstick has a partition table, which was the reason to ask |
6 |
> > > for a way to preserve it. |
7 |
> > |
8 |
> > OK, I wasn't sure if it did. |
9 |
> > |
10 |
> > In this case as I suggested, fdisk will show you the number and size of |
11 |
> > partitions. minfo will show you the geometry of the partition, should you |
12 |
> > wish to manually recreate it in the future. However, there are tools to |
13 |
> > help avoid manual partitioning! ;-) |
14 |
> > |
15 |
> > To answer exactly what you asked, copy the partition table (assuming all |
16 |
> > the USB stick contains is a single primary partition) by using good ol' |
17 |
> > dd: |
18 |
> > |
19 |
> > dd if=/dev/sdX of=~/mbr.img bs=512 count=1 |
20 |
> > |
21 |
> > |
22 |
> > Reverse the command to paste the MBR and partition table back. That |
23 |
> > should |
24 |
> > bring you back where you started when you first bought the USB stick. If |
25 |
> > for some weird reason the USB stick partitioning scheme included extended |
26 |
> > and logical partitions, then read one additional step below. |
27 |
> > |
28 |
> > > Again my questions: |
29 |
> > > Where are the partioning/format defining on the device? |
30 |
> > > If there are only stored the beginning of the device: How |
31 |
> > > much do I need to copy? |
32 |
> > > If there are tools to extract all needed informations of the |
33 |
> > > partioning/formatting and to recreate exactly that kind of |
34 |
> > > partitioning/formatting later with that or other tools: |
35 |
> > > Which tools do I need and how to use them? |
36 |
> > |
37 |
> > First copy the MBR and partition table using dd as I suggested above. |
38 |
> > Then |
39 |
> > use sfdisk --dump to create a text file with information on the size and |
40 |
> > positioning of the remaining partitions. |
41 |
> > |
42 |
> > sfdisk --dump /dev/sdX > sdX.dump |
43 |
> > |
44 |
> > |
45 |
> > To restore first run dd in the reverse order: |
46 |
> > |
47 |
> > dd if=~/mbr.img of=/dev/sdX bs=512 count=1 |
48 |
> > |
49 |
> > Then change the file director on the sfdisk --dump command: |
50 |
> > |
51 |
> > sfdisk --dump /dev/sdX < sdX.dump |
52 |
> > |
53 |
> > Needless to say you will need both 'mbr.img' and 'sdX.dump' files to |
54 |
> > restore the drive partitioning scheme to its original state, if it |
55 |
> > contains more than one primary partition. When you are restoring the |
56 |
> > partition tables, double check the /dev/sdX name or you could damage some |
57 |
> > other disk in your system! |
58 |
> Hi Mick, |
59 |
> |
60 |
> yeah! That's the informations I needed! Great, thank you. |
61 |
> |
62 |
> By the way, somehow "half offtopic": |
63 |
> |
64 |
> In the past I did hd-cloning (full contents, not only partition |
65 |
> schemes etc.) with dd. For a 1TB-disk this tooks quite a while. |
66 |
|
67 |
I think by default dd will use bs=512 which will take forever when copying a |
68 |
large drive. In this case increase the block size to something more |
69 |
reasonable, like e.g. bs=4096. |
70 |
|
71 |
> Then I came accross an article, which uses "pv" for that purpose: |
72 |
> |
73 |
> pv < /dev/sda > /dev/sdb (as root...;) |
74 |
> |
75 |
> THAT was fast! |
76 |
|
77 |
PV probably uses larger block sizes by default. You could test this with a |
78 |
known file size and compare the transfer time between dd and pv. |
79 |
|
80 |
|
81 |
> I mentioned it here, because (may be) someone else wants to copy/clone |
82 |
> a complete flash drive for backup purposes for example and may |
83 |
> experience an increase speed with pv instead of dd. |
84 |
> |
85 |
> If one wants to copy only parts, dd is the winner. |
86 |
|
87 |
Also worth mentioning is dcfldd which unlike dd can show progress of the bit |
88 |
stream and also produce hashes of the transferred output. It has the same |
89 |
performance as the dd command though. |
90 |
|
91 |
-- |
92 |
Regards, |
93 |
Mick |