SD-Karte des Raspberry Pi sichern und klonen: SD Card Copier, rpi-clone, dd oder partclone

Die SD-Karte des Raspberry Pi sicherst Du heute auf vier Wegen: mit dem SD Card Copier auf dem Desktop, mit rpi-clone im Terminal, als komplettes Abbild mit dd am PC oder als schlankes Partitions-Backup mit partclone. Die ersten beiden klonen das laufende System direkt auf eine zweite Karte, einen USB-Stick oder eine SSD, und die Kopie ist sofort bootfähig. Die anderen beiden erzeugen eine Datei, die Du im Schrank aufbewahrst und mit dem Raspberry Pi Imager zurückspielst. Welcher Weg wann passt, welche Befehle Du brauchst und wo die Fallen liegen, zeige ich Dir hier.

Angefangen hat das Ganze 2013. Das neue Spielzeug Raspberry Pi machte tierisch Spaß, Raspbmc lief als Mediacenter und der Film kam per Samba vom NAS. Ich hatte aber nur zwei SD-Karten und wollte trotzdem weitere Betriebssysteme ausprobieren, ohne die alten Installationen zu verlieren. Also musste ich die Karten sichern oder die Partitionen klonen. Das Problem ist geblieben, nur die Werkzeuge sind besser geworden. Was damals galt, gilt heute noch: partimage kannst Du vergessen. Es kann kein ext4 und die letzte Version stammt aus dem Jahr 2010.

Welcher Weg passt zu Dir?

Die Frage ist nicht mehr „dd oder partclone”, sondern: Willst Du eine zweite, sofort startbare Karte oder eine Abbild-Datei zum Aufheben? Und läuft der Pi mit Desktop oder ohne Monitor?

Methode	Läuft auf	Ergebnis	Vorteil	Nachteil
SD Card Copier	Raspberry Pi OS Desktop	Bootfähige Kopie auf Karte, Stick, SSD oder NVMe	Klicken statt tippen, läuft im laufenden System	Kein Abbild zum Aufheben, nicht in Raspberry Pi OS Lite
rpi-clone	Raspberry Pi, Terminal	Bootfähige Kopie, danach inkrementell aktualisierbar	Auch ohne Monitor per SSH, zweiter Lauf dauert nur Sekunden	Braucht ein zweites Speichermedium am Pi
dd	Linux-PC, Mac, auch auf dem Pi	Komplettes Abbild als Datei	Narrensicher, überall vorhanden, klont wirklich alles	Abbild so groß wie die Karte, langsam
partclone	Linux-PC, Clonezilla	Abbild je Partition, nur belegte Blöcke	Klein und schnell	Partitionstabelle musst Du selbst sichern

Meine Empfehlung: Auf dem Desktop nimmst Du den SD Card Copier, auf einem Server ohne Monitor rpi-clone. Willst Du mehrere Betriebssysteme abwechselnd ausprobieren, wie ich damals, sind Abbilder mit dd plus PiShrink am bequemsten. partclone bleibt der Weg für alle, die Platz sparen wollen und mit Partitionen umgehen können.

SD Card Copier: Klonen direkt auf dem Raspberry Pi

Raspberry Pi OS mit Desktop bringt das Werkzeug schon mit. Du findest es im Hauptmenü unter Zubehör → SD Card Copier (Paket piclone). Steck ein zweites Medium an, zum Beispiel eine SD-Karte im USB-Lesegerät, einen USB-Stick oder eine SSD, und wähle bei Copy From Device die laufende Karte (/dev/mmcblk0) und bei Copy To Device das Ziel. Das Programm kennt auch NVMe-Laufwerke, Du kannst also beim Pi 5 von der SD-Karte auf eine NVMe-SSD umziehen.

Das Häkchen New Partition UUIDs lässt Du gesetzt. Damit bekommt die Kopie eigene Partitionskennungen, und der Pi verwechselt Original und Klon nicht, wenn beide gleichzeitig stecken. Das Ziel darf größer oder kleiner sein als die Quelle, solange die Daten hineinpassen, denn der Copier kopiert Dateien, keine Sektoren. Was Du nicht bekommst, ist eine Abbild-Datei. Der SD Card Copier erzeugt immer ein startbereites Medium.

rpi-clone: Klonen im Terminal, auch ohne Monitor

rpi-clone ist ein Shell-Skript, das die laufende Karte auf ein zweites Medium klont: SD-Karte im USB-Lesegerät, USB-Stick, USB-SSD oder NVMe am Pi 5. Das ursprüngliche Projekt von Bill Wilson wurde 2020 aufgegeben, Jeff Geerling pflegt seitdem einen Fork (Stand September 2026: Version 2.0.27). Die Installation ist eine Kopie des Skripts nach /usr/local/sbin:

git clone https://github.com/geerlingguy/rpi-clone.git
cd rpi-clone
sudo cp rpi-clone rpi-clone-setup /usr/local/sbin

Danach schaust Du mit lsblk nach, wie das Zielmedium heißt, und klonst mit dem Gerätenamen ohne /dev/:

lsblk
sudo rpi-clone sda

Beim ersten Lauf legt rpi-clone die Partitionen auf dem Ziel an und kopiert alles. Jeder weitere Lauf auf dasselbe Ziel ist ein inkrementeller Abgleich per rsync und dauert nur noch Sekunden bis wenige Minuten. Mit -f erzwingst Du eine komplette Neuinitialisierung, mit -s neuer-name bekommt der Klon gleich einen anderen Hostnamen. Das ist die Methode für einen Server im Schrank: per SSH anmelden, einen Befehl tippen, fertig. Wer seinen Pi ohnehin über SSH pflegt, etwa mit automatischen Updates und statischer IP-Adresse, hat damit ein Backup, das genauso nebenbei läuft.

dd: Komplettes Abbild am Linux-PC oder Mac

dd ist deswegen eine gute Option, weil das Tool zur Standard-Ausrüstung eines jeden UNIX-ähnlichen Betriebssystems gehört, auch bei macOS. Damit klonst Du einfach den kompletten Speicher, Sektor für Sektor. Steck die Karte in den Rechner, finde mit lsblk heraus, wie sie heißt (bei mir damals /dev/sdb, heute oft /dev/mmcblk0 bei eingebauten Lesegeräten), und hänge alle Partitionen aus, bevor Du loslegst. Der Befehl zur Sicherung:

sudo dd if=/dev/sdX of=/pfad/zum/pi-backup.img bs=4M status=progress conv=fsync

status=progress zeigt Dir Fortschritt und Datenrate, das gab es 2013 noch nicht. conv=fsync sorgt dafür, dass dd erst fertig meldet, wenn wirklich alles geschrieben ist. Zum Wiederherstellen kehrst Du die Pfade bei if und of um:

sudo dd if=/pfad/zum/pi-backup.img of=/dev/sdX bs=4M status=progress conv=fsync

Bei einer 32-GByte-Karte ist auch das Abbild 32 GByte groß, egal wie viel davon belegt ist. Deshalb lohnt es sich, gleich beim Klonen zu komprimieren. Das spart einen Arbeitsschritt:

sudo dd if=/dev/sdX bs=4M status=progress | gzip > /pfad/zum/pi-backup.img.gz

Und zurück auf die Karte:

gzip -dc /pfad/zum/pi-backup.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Der Nachteil von dd bleibt die Geschwindigkeit, weil es wirklich über den kompletten Speicher geht, auch über die leeren Bereiche. Dafür ist es die narrensichere Methode: Partitionstabelle, Boot-Partition, Root-Partition, alles ist im Abbild drin.

PiShrink: Das Abbild verkleinern

Ein dd-Abbild schrumpfst Du nachträglich mit PiShrink. Das Skript verkleinert die letzte ext4-Partition auf die belegte Größe und baut einen Haken ein, der die Partition beim ersten Start wieder auf die volle Kartengröße ausdehnt. Aus einem 32-GByte-Abbild werden so ein paar GByte, und die lassen sich obendrein besser komprimieren:

sudo apt install parted gzip pigz xz-utils e2fsprogs
wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
chmod +x pishrink.sh
sudo ./pishrink.sh -z pi-backup.img

-z komprimiert das Ergebnis gleich mit gzip, -Z mit xz, -a nutzt dafür alle Prozessorkerne. Ein so verkleinertes Abbild passt auch auf eine kleinere Karte, solange die Daten hineinpassen.

Abbild zurückspielen: Raspberry Pi Imager und Co.

Ein Abbild musst Du nicht mit dd zurückschreiben. Der Raspberry Pi Imager schreibt eigene Dateien genauso wie die offiziellen Systeme: Choose OS → Use custom, dann das .img oder .img.gz auswählen und auf die Karte schreiben. Den Imager gibt es für Windows, macOS und Linux, auf Raspberry Pi OS und Ubuntu per sudo apt install rpi-imager. Alternativ nimmst Du balenaEtcher.

Was der Imager nicht kann: eine Karte auslesen und daraus ein Abbild machen. Die Entwickler haben diesen Wunsch ausdrücklich abgelehnt. Unter Windows übernimmt das Win32 Disk Imager mit seiner Read-Funktion, unter Linux und macOS dd.

Landet ein kleines Abbild auf einer großen Karte, dehnt Raspberry Pi OS die Root-Partition beim ersten Start in der Regel selbst aus. Tut es das nicht, erledigst Du das in raspi-config unter Advanced Options → Expand Filesystem. Hast Du ein Abbild mit PiShrink verkleinert, passiert das ohnehin automatisch.

partclone: Nur belegte Blöcke sichern

Die meisten werden schon mal etwas von Clonezilla gehört haben. Das ist eine Linux-Distribution, die zum Zweck des kostenlosen Klonens erstellt wurde, und sie wird bis heute gepflegt (Clonezilla live 3.3.3 erschien im Juli 2026). Die Entwickler verwenden dort ein Tool namens partclone, das ebenfalls weiter aktiv entwickelt wird. Es ist in der Regel nicht vorinstalliert, liegt aber in den Paketquellen von Debian, Ubuntu und Raspberry Pi OS:

sudo apt install partclone

Der Nachteil an partclone ist, dass Du nur Partitionen klonen kannst, keine ganzen Datenträger. Der große Vorteil: partclone klont lediglich die benutzten Sektoren und fasst den freien Platz gar nicht erst an. Das Backup ist kleiner und geht wesentlich schneller. Die Partition darf dabei nicht eingehängt sein. Eine Sicherung der zweiten Partition (das Root-Dateisystem mit ext4) sieht so aus:

sudo partclone.ext4 -c -s /dev/sdX2 | gzip -c9 > /pfad/zum/pi-backup/root-partclone.gz

Der Befehl für die erste Partition lautet etwas anders, weil es sich hier um eine FAT-Partition handelt. Das Programm heißt heute partclone.fat, der alte Name partclone.vfat funktioniert als Verweis weiter. Erwähnenswert ist noch der Parameter -c9 hinter gzip: bestmögliche Kompression, die Datei wird kleiner, das Backup dauert etwas länger.

sudo partclone.fat -c -s /dev/sdX1 | gzip -c9 > /pfad/zum/pi-backup/boot-partclone.gz

Das Wiederherstellen der Root-Partition:

zcat /pfad/zum/pi-backup/root-partclone.gz | sudo partclone.ext4 -r -o /dev/sdX2

partclone lässt sich auch ohne Kompression einsetzen. So sichert Du die zweite Partition in eine eigene Abbild-Datei:

sudo partclone.ext4 -c -s /dev/sdX2 -o /pfad/zum/pi-backup/root-partclone.pcl

Und stellst sie so wieder her:

sudo partclone.ext4 -r -s /pfad/zum/pi-backup/root-partclone.pcl -o /dev/sdX2

Ohne Kompression dauerte das bei mir damals statt fast 7 Minuten nur 58 Sekunden, der Größenunterschied war aber ordentlich:

partclone ist etwas mehr Arbeit, aber mein Abbild mit dd war immerhin über dreimal so groß wie die unkomprimierte Version von partclone. An diesem Verhältnis hat sich nichts geändert, nur dass PiShrink heute den Größennachteil von dd nachträglich ausbügelt.

Achtung: Partitionstabelle und Boot-Partition

dd ist die narrensichere Methode, weil es alle Partitionen und den Datenträger komplett klont. Bei partclone musst Du aufpassen: Es sichert nur den Inhalt der Partitionen, nicht die Partitionstabelle. Ohne die weiß die neue Karte nicht, wo die Boot-Partition anfängt. Sichere die Tabelle deshalb zusätzlich als Textdatei:

sudo sfdisk -d /dev/sdX > /pfad/zum/pi-backup/partitionen.sfdisk

Auf der neuen Karte spielst Du sie mit sudo sfdisk /dev/sdX < partitionen.sfdisk zurück, legst die Dateisysteme an und stellst dann die partclone-Abbilder her. 2013 habe ich dafür noch einen Screenshot von cfdisk gemacht. Der tut es zur Not immer noch:

Den Boot-Code im MBR, den ein PC braucht, braucht der Raspberry Pi nicht. Die Firmware liest die Partitionstabelle und sucht die FAT-Partition mit den Boot-Dateien. Bei den Modellen bis zum Raspberry Pi 3 liegt dort bootcode.bin, ab Raspberry Pi 4, 400, 500 und Compute Module 4 steckt der Bootloader in einem EEPROM auf der Platine. Die FAT-Partition mit Firmware, Kernel und config.txt brauchst Du trotzdem; seit Raspberry Pi OS Bookworm ist sie unter /boot/firmware eingehängt. Zwei Partitionen plus Tabelle, mehr ist es nicht.

Wenn Du die Abbilder auf einen anderen Datenträger klonst, kann es bei dd zu einem Fehler kommen, wenn der neue Datenträger kleiner ist als der alte. Probiere die SD-Karte trotzdem aus. dd wirft den Fehler erst am Ende, und wenn die Karte nicht komplett voll war, sind wahrscheinlich trotzdem alle Daten da. Sauberer ist es, das Abbild vorher mit PiShrink zu verkleinern. Mit partclone kannst Du auch auf kleinere Partitionen klonen, solange genug Platz für alle Daten vorhanden ist. Der entscheidende Parameter hierfür ist -C (Don’t check device size and free space).

Wenn Du damit experimentierst, ist es am Anfang nicht verkehrt, eine Sicherung mit zwei Methoden durchzuführen, etwa ein dd-Abbild im Schrank und ein rpi-clone-Klon im Lesegerät. Das erhöht die Chancen einer erfolgreichen Wiederherstellung, und einen Klon solltest Du sowieso einmal testweise booten. Ein Backup, das nie zurückgespielt wurde, ist nur eine Vermutung.

Ein Backup-Plan statt vieler SD-Karten

Du siehst, dass Du verschiedene Abbilder vorhalten und nach Bedarf schnell auf dem Raspberry Pi einsetzen kannst. Man braucht keine x SD-Karten, sondern nur einen vernünftigen Backup-Plan: ein Abbild oder Klon, bevor Du am System schraubst, und ein aktueller Klon per rpi-clone für den Pi, der als Server läuft. Die Daten selbst, etwa Fotos oder Nextcloud-Ordner, sicherst Du getrennt davon, zum Beispiel mit rsync und rclone. Dann ist ein Kartendefekt nur noch ein Ärgernis von zehn Minuten und keine Katastrophe.

Nette Pi-Konstellation

Suchst Du ein VPN für den Raspberry Pi? NordVPN* bietet einen Client, der mit Raspberry Pi OS (32-Bit / 64-Bit) und Ubuntu für Raspberry Pi (64-Bit) funktioniert.

Aktualisiert am 08.09.2026 von Henry. Fakten geprüft.

---

---