Clone Linux Live USB flashdrive

[Dr_JRE]

If i wanted to clone a USB drive that has a working linux install, could I simply drag and drop the files then grub-install /dev/sdc?

is there a better way?

 

[Aristotelian]

If that doesn't work, I would try booting from the USB drive, then use the "Make Startup Disk" utility.

 

[powerhouse32]

From within Linux, open a terminal window. As root user (sudo in Ubuntu), use:

dd if=/dev/olddrive of=/dev/newdrive bs=32M

where /dev/olddrive points to the source disk (like for example /dev/sdd) and /dev/newdrive points to the new blank disk (like for example /dev/sde). Your target drive will be overwritten and if it contained data it will be lost forever!

WARNING: Before you even try using the above command, check the following:

1. You can't use dd on a live Linux system. That is, if you want to copy your USB drive, don't boot from it !!! So the best is to boot into a live Linux USB stick. If that is not an option, you need to mount your Linux file system on the USB drive to "read only".

2. Make absolutely certain that you specify the right source and destination drives !!! The command df should list the mounted file systems. Check to make sure you got it right, else dd will happily overwrite an existing disk with data on it. Don't mix up the if= and of= command option - "if" stands for input file and "of" for output file, though in this case you clone an entire disk!

3. The target drive MUST be equal or larger in size than the source drive (USB disk), else dd will fail.

There are zillions of options for dd, you can also create an img image file of the entire disk, or use dd in combination with gzip and an image file to get a compressed image file on your target drive.

If used with great caution (!!!), dd is your best friend for cloning. It copies the entire disk with boot sector and MBR and partition table etc. to the target drive.

If the target disk is larger than your source disk, you will have some unused space on it. That's no problem as you can easily format that extra space (or resize your partitions) to make use of it.

By the way, dragging and pasting won't give you a bootable disk! You can do that and then install your MBR and/or bootloader manually, but that's a pain in the neck. Again, you can't use drag and drop when you boot from your USB drive (see point 1 above).

A final note on dd: it won't give you any progress indication and it WILL take a long time, depending on the size of your USB drive. It will copy the entire drive, so be prepared for some hours of waiting until it completes.

Good luck!

 

[ex_bubblehead]

....
1. You can't use dd on a live Linux system. That is, if you want to copy your USB drive, don't boot from it !!! So the best is to boot into a live Linux USB stick. If that is not an option, you need to mount your Linux file system on the USB drive to "read only".
....

One correction. You can clone a live drive. This is how forensic live captures are performed. I've done thousands.

 

[powerhouse32]

One correction. You can clone a live drive. This is how forensic live captures are performed. I've done thousands.

Using "dd" ?

Anyway, cloning a live drive for forensics may be different to cloning a bootable USB drive to get yet another bootable drive.

Like to share how you clone a drive?

 

[ex_bubblehead]

Using "dd" ?

Anyway, cloning a live drive for forensics may be different to cloning a bootable USB drive to get yet another bootable drive.

Like to share how you clone a drive?

Here's just one way:

Live memory copied to an image file
dd if=\\.\PhysicalMemory of=d:\images\memory.img conv=noerror

Binary copy over network using dd as follows:

Netcat Listener: nc -l -p <porttolistenon>
Netcat Client: nc <destinationhostname> <porttosendto>


Typically dc3dd or dcfldd are used in place of dd as they have additional features useful to forensics.

The result is bootable if required.

 

[jimmybgood]

Sure, you can run dd on a live drive, but what you will get is a mish-mash of the various states that the source drive was in during the copy process. The result may not be consistent and may not be bootable.

For example, if someone using the source drive upgrades the kernel, the file metadata may point to one inode for the kernel yet the metadata may have already been copied over pointing to some other inode on the drive.

Perhaps by "live" someone means mounted. Then, if the OS is not operating on it, you can get an exact copy, but certainly for the purpose of the OP, he should dd with source and destination drives unmounted.

Another way to clone is with rsync. It's faster and doesn't have the constraint that the destination drive needs to be at least as large as the source. It doesn't even have to be the same filesystem type. But it would have to be formatted first and the boot loader installed at the end.

There is also find | cpio. Play around and see what works.

 

[powerhouse32]

@ex_bubblehead: Yes, there are zillions of ways to use dd. Thanks for mentioning some of the more exotic ones, at least for ordinary Linux users.

But as to the OP question, the dd if=/dev/source of=/dev/target, when both are not mounted, will give him an exact copy which is bootable. Copying a live (or mounted) file system can and most likely will be problematic when he/she wants to use the newly created clone to boot the computer.

@jimmybgood: Thanks for pointing out rsync - I used to run it regularly to update my NMT and copy / sync media files. It works nicely. For the reasons you mentioned (i.e. having to install the boot loader at the end), I find dd easier and safer, as long as the target drive is equal or bigger than the source drive.

You are right about using dd on live/mounted drives - dd will happily copy each and every folder and file (actually every bit of data) that's on the source drive, including all the stuff that's actually only created when the system is booted (like /proc or /dev or /sys folders). I don't know what that will do when the system is booted from the newly created disk, but it most likely will not play very nice.

 

[jimmybgood]

It was an interesting discussion. I'm going to try that live memory file copy procedure sometime. As a note, I believe that when the kernel changes to the real root system, it will just mount the virtual filesystems /dev /proc and /sys over what may have been copied, thereby hiding them from user and system.