Hello:

After upgrading to Windows 8.1 in a laptop (I'm forced to use Windows because it is the SO in my job), I was asked to plug in a USB stick (16 GB at least) where a re-install copy of the SO would be backup.

Now this same laptop is asking to upgrade to Windows 10 (which the sooner or later, will be the SO in my job, too), and I'd prefer that the ONLY copy that I have of my SO (AFAIK you can't download again your copy of Windows 8.1 from Microsoft) would be backup to a safer medium, like one HD of mine.

I used a reliable USB stick for my copy, but it has been stored in a drawer for more than a year. If the thing could fail, I better try to copy it once. Also, being a proprietary software, I bet something could fail if I later try to restore the USB image in another USB. I need to clone the USB, dd is the command I should use (I think).

Of course I've read http://www.linuxquestions.org/questi...ommand-362506/ but dd is also a risky command if used carelessly, and in order to dispel all uncertainty...:

Will this work?. I thought copying the FULL USB stick to a file image would be the best solution. But for the dd options, I'm a little lost;

Why people place a bs option?. Can't the job be done in a single read-to-memory write-to-hd fashion? (BTW: I don't have 16 GB RAM, I have 8 GB. Just wondering what if I had more RAM, or if the ram I have could help in this..).

And why bs=512,4096...?. My HD has 4k blocks, but 64 MB cache memory. Why not read and write in 64 MB chunks?. Or in the whatever sector size of the USB?.

Why the notrunc option?. Why would dd truncate the of?. How would this work anyway if the of would be of less size than the if?. dd checks if vs of size in any way?.

Would you place any else options?.

And yes, I've read the man page, and I have found it explanatory, but it seems aimed at a more... "technified" audience.

Please check the accepted answer in this thread. As you can see, you don't actually need to use the bs option.
That said, have you check OSFClone? It's a FOSS utility that can get the job done without hassle.
Hope it helps!

it would be best if sdb is not in use (no partition mounted) during this operation. obviously the of= must not be on sdb.
is sdb another external storage, or is it an internal hard drive?

To insure a correct device to dd an image to, I would use dmesg and grep to get the actual block device.

First, plug in your USB stick and then type the code below in a terminal.

Here is my output.
In the last line, my 8GB USB stick is identify as sdc by the logical block size of (7.82 GB/7.28 GiB)

-cheers

There are a number of ways to determine which drive is which, and any will work, but it's essential that you have the correct devices in the correct order. It's very easy to end up with both drives blank, or some such. The syntax in the OP is correct, assuming it uses the correct drives. The block size (bs=4096) is optional, and can be whatever size you like or omitted. If you want a 4MB block size, you can use 4M or 4MB, for example.

Here are some examples: http://www.linuxquestions.org/questi...d.php?t=362506
default (if no bs is used) is 512, so if the drive has larger bs, it just speeds up the dd process some to use the correct bs but otherwise makes no real difference in the final product.

to find out the actual bs (but again unnecessary as mentioned below, 1M or 4M is fine for usb iso and img).

I use a bs of 1M or 4M when I dd a hybrid iso to a usb stick and it has no issues. It boots fine and it runs well too.

The command appears valid, assuming /home is not on the USB device you are reading (rather unlikely) AND is big enough to hold everything on the USB device. I've done this several times to backup a Raspberry PI (32GB device), though I usually compress it afterwards as there are a lot of unused blocks in the file.

The bs option to dd is buffer size. The larger the buffer, the faster the transfer can go - with less contention on the various system busses involved (large reads tend to go at the maximum DMA size, and having a single large buffer means multiple DMA transfers can be done with less setup overhead). It works best when a multiple of the buffer size is the size of the device (you won't get warning messages about incomplete buffer transfers), but other than that, a 1MB buffer is usually plenty fast, and 4MB isn't that much faster. Without the bs specification I think the default is 4K (and quite slow).

The conv=notrunc is mostly a throwaway. I think it is only useful if you are replacing parts of a pre-existing file... or using an append operation.

The default dd block size is 512 bytes -- really slow.It's meaningful only when the destination is an existing ordinary file (meaningless for a device) and you don't want the operation to begin by throwing away the current content. That would be because you're modifying or appending to the current content, or perhaps because you want to keep the same disk blocks allocated to the file and you know the filesystem behavior will support that. (Some filesystems always use new space for writes.)

I plain cloned the USB with:
Fortunately it was still in good shape and readable (it seems).

I simply choose the 4K size because it is the physical sector size of my hard disk. The process was a little slow, but I wasn't in a hurry.

BTW, I noticed that when Windows created this USB, the device was noticeable hot at the end of the process; this time when it was cloned with Linux it went only a barely hot. My guess is that Windows used the full bandwidth of the USB, but with Linux, as I only read from it sector by sector, the USB was submitted to a less stressful work and therefore heated less.

Thanks for the help!

may be because of the block size you provided.
there's usually no need to specify that, dd has some mechanism to adjust that automagically (or so i've been told).