2

I use a notebook with Mint Linux, and for a few days I'll be using Windows. So I would like to "save" my OS and later put it back on the same drive.

Its using full disk encryption (the one that comes default on Mint install).

Booting up a live CD with Linux then creating a copy with something like:

dd if=/dev/sda of=/media/externalhd/mint.img

[Here I format and add windows] and after I'm done boot up with a live CD again and do:

dd if=/media/externalhd/mint.img of=/dev/sda

Should work, right?

  • 1
    Correct, this should work, also worth noting that there are possible alternatives to wiping your system based on your requirements and hardware. You could use a VM running windows, or depending on your partitioning scheme you may be able dual boot windows and Linux without losing any data. – Centimane Sep 22 '16 at 18:09
  • 2
    why not shrink the linux partition temporarily and do a dual boot? – Rui F Ribeiro Sep 22 '16 at 19:11
  • Just an opinion but I think dd really bytes for these type of situations. – mdpc Sep 22 '16 at 19:43
  • BTW: to increase the speed increase the block size to a HUGE value (i.e. include the parameter bs=1G). Also, I'd include the 'sparse' option to reduce the size. – mdpc Sep 22 '16 at 19:49
  • Question: Exactly how large is /dev/sda? Do you have the appropriate media to contain all of this output? It will be AT least the total size of the underlying disk not what df or du says. – mdpc Sep 22 '16 at 19:51
1

Your commands are fine and as has been pointed out this will save all the empty space on your drive too. However if you choose the secure wipe option when you installed the system the drive's empty space will be full of random noise so compressing the output buys you very little.

You should use a larger block size for the copy and avoid polluting the systems buffer cache to make the raw reads faster.

  • The dd options iflag=direct or oflag=direct read or directly from the device bypassing Linux's caching layer.
  • The dd option bs (block size) tells dd how much data to read or write at once, modern disk drives work much faster with larger chunks of data.

Compression is CPU intensive and gzip only uses a single core, meaning this will likely be the limiting factor speedwise for the copy. Using pigz which uses all CPU cores will make it faster but still likely to be CPU bound.

As a rough ball park with a modern CPU I would use compression if storage space was an issue or if you are connected by something slower than USB2. USB3, SATA or 100Mbit+ networking will almost certainly be faster than gzip so will gain no speed but might save some space.

The commands I would use in the case of slow connection to storage (ie 10Mbit ethernet or USB1/2) or lack of space are:

dd if=/dev/sda bs=1M iflag=direct | pigz -c > /media/external/image.sda.gz

If you have a fast connection to storage and the space used is not an issue I would use the following command:

dd if=/dev/sda of=/media/external/image.sda.raw oflag=direct iflag=direct bs=1M
0

It works but it is not the best way. The image will be very big because of the zeroes on the raw data. If you want to avoid this behavior you can do something like this:

  dd if=/dev/sda | gzip > /media/externalhd/backup.img.gz

Gzip knows that zeroes dont need to be considered on the image, but just counted, so the image will be smaller, specially if you have some free space on the disk, plus this with the gzip compression, so it is times better.

  • Than you Luciano! That will really save a good amount of time. – Daniel Oliveira Sep 22 '16 at 18:42
  • Caution: compression of binary data can actually lead to a size increase in the resulting output file. – mdpc Sep 22 '16 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.