On Wednesday 30 Mar 2016 05:28:29 meino.cra...@gmx.de wrote: > Mick <michaelkintz...@gmail.com> [16-03-30 03:56]: > > On Tuesday 29 Mar 2016 19:53:45 meino.cra...@gmx.de wrote: > > > The real thing: > > > The usbstick has a partition table, which was the reason to ask > > > for a way to preserve it. > > > > OK, I wasn't sure if it did. > > > > In this case as I suggested, fdisk will show you the number and size of > > partitions. minfo will show you the geometry of the partition, should you > > wish to manually recreate it in the future. However, there are tools to > > help avoid manual partitioning! ;-) > > > > To answer exactly what you asked, copy the partition table (assuming all > > the USB stick contains is a single primary partition) by using good ol' > > dd: > > > > dd if=/dev/sdX of=~/mbr.img bs=512 count=1 > > > > > > Reverse the command to paste the MBR and partition table back. That > > should > > bring you back where you started when you first bought the USB stick. If > > for some weird reason the USB stick partitioning scheme included extended > > and logical partitions, then read one additional step below. > > > > > Again my questions: > > > Where are the partioning/format defining on the device? > > > If there are only stored the beginning of the device: How > > > much do I need to copy? > > > If there are tools to extract all needed informations of the > > > partioning/formatting and to recreate exactly that kind of > > > partitioning/formatting later with that or other tools: > > > Which tools do I need and how to use them? > > > > First copy the MBR and partition table using dd as I suggested above. > > Then > > use sfdisk --dump to create a text file with information on the size and > > positioning of the remaining partitions. > > > > sfdisk --dump /dev/sdX > sdX.dump > > > > > > To restore first run dd in the reverse order: > > > > dd if=~/mbr.img of=/dev/sdX bs=512 count=1 > > > > Then change the file director on the sfdisk --dump command: > > > > sfdisk --dump /dev/sdX < sdX.dump > > > > Needless to say you will need both 'mbr.img' and 'sdX.dump' files to > > restore the drive partitioning scheme to its original state, if it > > contains more than one primary partition. When you are restoring the > > partition tables, double check the /dev/sdX name or you could damage some > > other disk in your system! > Hi Mick, > > yeah! That's the informations I needed! Great, thank you. > > By the way, somehow "half offtopic": > > In the past I did hd-cloning (full contents, not only partition > schemes etc.) with dd. For a 1TB-disk this tooks quite a while.
I think by default dd will use bs=512 which will take forever when copying a large drive. In this case increase the block size to something more reasonable, like e.g. bs=4096. > Then I came accross an article, which uses "pv" for that purpose: > > pv < /dev/sda > /dev/sdb (as root...;) > > THAT was fast! PV probably uses larger block sizes by default. You could test this with a known file size and compare the transfer time between dd and pv. > I mentioned it here, because (may be) someone else wants to copy/clone > a complete flash drive for backup purposes for example and may > experience an increase speed with pv instead of dd. > > If one wants to copy only parts, dd is the winner. Also worth mentioning is dcfldd which unlike dd can show progress of the bit stream and also produce hashes of the transferred output. It has the same performance as the dd command though. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
