Mick <michaelkintz...@gmail.com> [16-03-30 17:12]: > 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
I had experimented a lot with the block size argument of dd previously and it seems I never had find the sweet spot. May it was simply an blind and unfortunate dance around it...who knows. pv did it right from the beginning the correct way with a super simple command: pv < /dev/sda > /dev/sdb :) I installed dcfldd just a momnent before and will experiment with it - thanks for mentioning it! By the way: For what stands the 'dd' for ? (Think unix!) :) Best regards Meino
