dd_bak.sh

#!/bin/bash

# restore with the following command:
# gunzip --stdout <filename>.img.gz | dd bs=10M of=/dev/sdX

# pv(1) is optional and provides a progress bar
# just remove it from the pipe, when you don't want it

DATE=$(date +"%Y-%m-%d_%H-%M")
GREEN='\033[1;32m'
RED='\033[1;31m'
NC='\033[0m'

if [[ "$1" == "-h" || "$1" == "--help" || "$1" == "" ]]; then
	echo -e "simple dd backup tool by c5e3"
	echo -e "must be run as root!"
	echo -e "usage:"
	echo -e "\tdd_bak.sh <sdX> <destination folder>"
	exit 1
else
	if [[ $EUID -ne 0 ]]; then
		echo "try again as root" 1>&2
		exit 1
	fi
	echo -ne "make backup from ${GREEN}/dev/$1${NC} to ${RED}$2${HOSTNAME}_$1_$DATE.img.gz${NC}? [y/n] "
	read confirm

	if [[ "$confirm" == "y" ]]; then
		dd bs=10M if=/dev/$1 | pv | gzip > $2${HOSTNAME}_$DATE.img.gz
	else
		echo -e "${RED}no backup created!${NC}"
		exit 1
	fi
fi

wow, thanks for that very detailed explenation! the reason for using dd is, as you already guessed, a dualboot system with windows as a secondary OS. i used acronis for a long time, but last year i had troubles restoring my ext4 partitions, aside of being proprietary anyway. since dd images are a common solution for sd card images on single board computers, i tried it this way. if i had a dual boot system with two hard drives, i would backup them both in their optimal way, but since i'm using a laptop, this is not possible.
however, i think i will go for clonezilla instead of trying reinventing the wheel.

@ruario One can use gzip --rsyncable that not only makes the compressed image rsync-friendly but also limits the damage only to 32K .

@c5e3 Thanks for taking the feedback the right way. I did worry latter that my wall of text was perhaps too much. It really depends on the importance of your data, your perception of the preceived risk and your usage (e.g you do need a container format because you store the result on a Windows partition). With a combination of @ibukanov's suggested switch (assuming it is available to you) and parity files, the solution might be good enough for your own use case. With any backup method the key would be to regularly test that it recovery indeed work.

@ibukanov nice tip. I was not aware of this switch and in fact it is not mentioned in the man pages on Slackware or OpenSUSE, nor is it present on macOS. I also see some reports of users on Gentoo and Arch not having it. It seems that the presence of the --rsyncable option depends on whether the distribution has applied the patch that adds the option, since it is not part of upstream.

I would like to know why it hasn't been adopted by upstream (does it cause problems?). Also I would personally be a little reticent to use or promote it in a public script when it might not be readily available but for personal usage, assuming it is available on your distro it could be another option.

EDIT: The --rsyncable option was upstreamed with GNU gzip 1.7. However, with many distros still using older versions and patching of this feature in older versions being inconsistant, you still cannot reliably know --rsyncable will always be available to everyone who might try this script.

I have just discovered that pigz has --rsyncable built-in (from upstream, without a patch) and other similar switches such as --independent. In addition since pigz compresses using threads to make use of multiple processors and cores, you will most likely get far better performance. Finally pigz was written by Mark Adler (a co-author of the zlib compression library and gzip) so I would be fairly confident in its reliability.

So if you are planning to continue with a gzipped image or archive, pigz with appropriate switch(es), might be a better option.