Imaging a Linux (or Windows) Disk without Macrium -- Not cloning

Hi folks

Again the wonders of DD -- if you need to image (not clone as that's simple enough) a disk for use as a backup and you don't have an available copy of Macrium to hand it's very easy to use DD to image a disk to a file and restore it. Works on any type of disk.

Preferably from say a VM boot a live distro -- fedora is an easy "Windows like" system or use the WSL in Windows

I prefer storing these images on another external drive but it can be done on local HDD if enough space - but if doing this inside a VM it's better to use an external device for obvious reasons !!

so mount the external drive -- mount /dev<device> -t auto -o rw /mnt (/mnt will exist on your live distro)

and simply do the following dd if=/dev/sda conv=sync,noerror bs=128K | gzip -c > /mnt/image.gz



This might take a little while to run depending on size of HDD being imaged so go for a beer or whatever.
To restore -- again boot live distro and as root :

gunzip -c <your image file.gz> | dd of=<target disk>

You can also do this in the WSL on Windows (both backup and restore)

Don't be afraid whether using Windows or any other OS to use the command line !!

Cheers
jimbo

Yeah, dd is a great tool. The biggest downside to something like dd over Macrium is that these other tools often create a very large output file, largely the same size as the original volume.

For example, on my Raspberry PI, i boot from a 240GB SSD. I only have about 5GB worth of stuff on the PI, but when I do my backup, it takes 240GB of space as it's copying the drive byte for byte, from beginning to end. A tool like Macrium is only going to grab the blocks being used and result in a substantially smaller output file. Like 1-2GB in size.

pparks1 said:

Yeah, dd is a great tool. The biggest downside to something like dd over Macrium is that these other tools often create a very large output file, largely the same size as the original volume.

For example, on my Raspberry PI, i boot from a 240GB SSD. I only have about 5GB worth of stuff on the PI, but when I do my backup, it takes 240GB of space as it's copying the drive byte for byte, from beginning to end. A tool like Macrium is only going to grab the blocks being used and result in a substantially smaller output file. Like 1-2GB in size.

Hi there
When used as above in my original post (Imaging rather than cloning and with compression ) then my entire 250GB SSD (including 2 VM images (W219 Server and W10 Pro) created a .gz file of 38GB so compression is really good

it "gunzipped" -- restored with decompression to a test SSD and booted perfectly.

Price is of course time -- but one can "fiddle around" with the bs (doesn't mean B/S !!) parameter to get a decent buffering size which speeds it up a little.

Cheers
jimbo

Nick Harbour's dcfldd offers a few useful improvements over dd.
dcfldd

hdmi said:

Nick Harbour's dcfldd offers a few useful improvements over dd.
dcfldd

Hi there
the problem with that it looks like the program hasn't been maintained for around 15 years -- dd at least is built into the kernel so will be current with new Disk geometries, latest linux kernels and file systems.

Suggestions though are always worthy of merit. However you can see that this is really old software - reference to the DD command in your link shows commands to convert EBCDIC tapes to ASCII etc -- that's really old legacy stuff (IBM Mainframes etc !!).

IMO I'd just get to grips with DD - it always works if used correctly and if you buffer it correctly (where possible) it can be speeded up.

Thanks for the suggestion though.

Cheers
jimbo

jimbo45 said:

Hi there
the problem with that it looks like the program hasn't been maintained for around 15 years -- dd at least is built into the kernel so will be current with new Disk geometries, latest linux kernels and file systems.

Suggestions though are always worthy of merit.

Cheers
jimbo

The last update was released about a year ago. See: GitHub - resurrecting-open-source-projects/dcfldd: Enhanced version of dd for forensics and security