Raspberry Pi Backup

Passende Hardware im Überblick

Boards – jedes davon will gesichert werden:
Raspberry Pi 5 mit 8GB RAM – die Empfehlung (Link)*
Raspberry Pi 5 mit 16GB RAM für den Dauerbetrieb (Link)*
Raspberry Pi 5 mit 4GB RAM (Link)*
Raspberry Pi 4 Starter-Set – der klassische Server (Link)*

Karten und Kartenleser – das Werkzeug für das Abbild:
SanDisk Extreme A2 128GB – Zweitkarte zum Klonen (Link)*
SanDisk 32GB microSD – wenn es günstig sein soll (Link)*
UGREEN USB-3-Kartenleser – schnell genug für ganze Abbilder (Link)*
Acer USB-3-Kartenleser (Link)*
UGREEN 2-in-1-Leser für SD und microSD (Link)*

Ziel-Laufwerke für die Sicherung:
SanDisk Extreme Portable SSD 1TB – robust und schnell (Link)*
SanDisk Extreme Portable SSD 2TB für viele Generationen (Link)*
Intenso TX800 SSD – der günstige Ablageplatz (Link)*
Intenso M.2 NVMe SSD 500GB (Link)*
Crucial P310 NVMe SSD 500GB (Link)*
Geekworm X1001 M.2-HAT – SSD direkt am Pi 5 (Link)*

Damit die Sicherung nicht mitten im Schreiben abbricht:
Geekworm X1200 USV für den Pi 5 (Link)*
Geekworm X703 USV für den Pi 4 (Link)*
Offizielles 27-W-Netzteil für stabile Spannung (Link)*

Kurz gesagt: Wie sichert man einen Raspberry Pi richtig?

Die Kurzfassung zum Raspberry Pi Backup:

• Komplettes Abbild: Karte oder SSD am PC einlesen – unter Linux und macOS mit dd, unter Windows mit Win32DiskImager oder dem Raspberry Pi Imager. Das Ergebnis ist ein bootfähiges 1:1-Abbild.
• Abbild verkleinern: PiShrink schneidet den leeren Rest weg. Aus 64 GB werden so oft 6 GB, und das Abbild passt später auch auf eine kleinere Karte.
• Im Betrieb sichern: rsync kopiert nur geänderte Dateien auf ein NAS – täglich, ohne den Pi anzuhalten.
• Klon auf Reserve: rpi-clone schreibt das laufende System auf eine zweite Karte oder SSD. Fällt das Original aus, wird nur umgesteckt.
• Datenbanken gehören gedumpt: Eine im Betrieb kopierte Datenbankdatei ist oft unbrauchbar. mysqldump, pg_dump oder sqlite3 .backup liefern konsistente Stände.
• Der entscheidende Schritt: Einmal zurückspielen und den Pi damit starten. Eine Sicherung, die nie zurückgespielt wurde, ist nur eine Vermutung.

Was ein Raspberry Pi Backup wirklich enthalten muss

Ein Raspberry Pi Backup ist selten ein technisches, sondern fast immer ein gedankliches Problem: Die meisten sichern das Falsche. Ein frisch installiertes Betriebssystem ist in zwanzig Minuten wieder da – unersetzlich sind die Wochen an Konfiguration, die darauf gewachsen sind. Genau die stecken in unscheinbaren Ordnern.

Wertvoll ist zuerst /etc mit Netzwerk-, Dienst- und Autostart-Einstellungen, dann /home mit Skripten, SSH-Schlüsseln und Cronjobs, außerdem /opt und /var/lib für nachinstallierte Dienste. Wer mit Docker arbeitet, braucht die compose-Dateien und die gemappten Volume-Ordner – die Container selbst nicht, die lädt ein einziger Befehl neu herunter.

Eine eigene Behandlung verlangen Datenbanken. Eine MariaDB oder eine SQLite-Datei im laufenden Betrieb einfach mitzukopieren, erzeugt in vielen Fällen einen halb geschriebenen Stand, der beim Zurückspielen nicht mehr öffnet. Richtig ist ein Dump: mysqldump -u root -p --all-databases > /mnt/nas/db.sql oder bei SQLite sqlite3 daten.db ".backup /mnt/nas/daten.db". Dienste mit eigenem Sicherungsmechanismus – etwa das Home-Assistant-Backup – nutzt man besser über deren eigene Funktion und legt nur das fertige Archiv beiseite.

Und dann gibt es das, was in kein Abbild passt: das Wissen, warum etwas so eingerichtet wurde. Eine schlichte Textdatei mit Paketen, Ports und Zugangswegen kostet fünf Minuten und ist im Ernstfall mehr wert als das dritte Abbild derselben Woche.

Raspberry Pi Backup als Image erstellen – Schritt für Schritt

Das vollständige Abbild ist die gründlichste Variante: Bootpartition, System und Daten in einem Stück, nach dem Zurückschreiben sofort startklar. Der Preis dafür: Der Pi muss dabei ausgeschaltet sein.

1. Sauber herunterfahren: sudo shutdown -h now, dann den Strom trennen. Eine Karte, die im Betrieb abgezogen wird, liefert im besten Fall ein defektes Abbild.
2. Medium anschließen: Karte in den Kartenleser, SSD ans USB-Gehäuse. Ein USB-3-Leser verkürzt den Vorgang deutlich – über USB 2 dauert eine 64-GB-Karte schnell eine Stunde.
3. Gerät ermitteln: Unter Linux lsblk, unter macOS diskutil list. Notiere den Bezeichner, etwa /dev/sdb oder /dev/disk4. Diese Angabe ist der gefährlichste Punkt der ganzen Anleitung.
4. Abbild ziehen (Linux): sudo dd if=/dev/sdb of=~/pi-backup.img bs=4M status=progress. Unter macOS zuerst diskutil unmountDisk /dev/disk4, dann dasselbe mit if=/dev/rdisk4 – das r davor arbeitet spürbar schneller.
5. Windows: Win32DiskImager öffnen, unter „Read" einen Dateinamen wählen und das Abbild auslesen. Alternativ bietet der Raspberry Pi Imager in aktuellen Versionen das Sichern eines Laufwerks direkt an.
6. Abbild verkleinern: Auf einem Linux-Rechner sudo pishrink.sh -z pi-backup.img ausführen. PiShrink schrumpft die Partition auf den belegten Platz und packt das Ergebnis. Beim ersten Start wächst das Dateisystem automatisch wieder auf die volle Kartengröße.
7. Ablegen und beschriften: Dateiname mit Datum, dazu eine Zeile, was auf diesem Stand lief. pi-backup-2026-03-14-piHole-nextcloud.img.gz beantwortet in einem Jahr mehr Fragen als jede Ordnerstruktur.
8. Prüfen: Die entpackte Datei sollte ungefähr der Kartengröße entsprechen. Ein Abbild von wenigen Megabyte bedeutet, dass dd die falsche Partition erwischt hat.

Backup im laufenden Betrieb: rsync auf ein NAS

Ein Server, der Türklingel, Heizung und Werbeblocker versorgt, lässt sich nicht jede Nacht ausschalten. Für den Dauerbetrieb ist deshalb rsync das Mittel der Wahl: Es überträgt nur Geändertes, behält Rechte und Besitzer und läuft ohne Unterbrechung.

Zuerst wird das Ziel eingebunden – eine Samba-Freigabe, ein Ordner auf der FritzBox oder ein Verzeichnis auf dem NAS. Danach genügt für die wichtigen Ordner:

sudo rsync -aAXv --delete /home/ /mnt/nas/pi/home/
sudo rsync -aAXv --delete /etc/ /mnt/nas/pi/etc/

Wer das gesamte System spiegeln möchte, schließt die virtuellen Verzeichnisse aus: --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/tmp --exclude=/run --exclude=/mnt. Das Ergebnis ist kein bootfähiges Abbild, aber ein vollständiger Dateibestand, aus dem sich jede einzelne Konfiguration zurückholen lässt.

Eine Warnung zu --delete: Der Schalter hält Ziel und Quelle deckungsgleich – und löscht damit auch im Backup, was auf dem Pi verschwunden ist. Gegen versehentliches Löschen hilft er also nicht. Wer das absichern will, kombiniert rsync mit --backup --backup-dir= und einem Datumsordner oder legt die Versionierung dem NAS auf. Eine reine Synchronisation wie Syncthing ersetzt das Backup nicht, weil sie Fehler zuverlässig mitkopiert.

rpi-clone und der Vergleich der Verfahren

Zwischen Abbild und Dateikopie steht rpi-clone: Das Skript schreibt das laufende System auf ein zweites, angeschlossenes Medium und macht es bootfähig. Nach git clone https://github.com/billw2/rpi-clone und dem Kopieren des Skripts nach /usr/local/sbin genügt sudo rpi-clone sda. Der erste Durchgang dauert je nach Datenmenge einige Minuten, jeder weitere gleicht nur noch Änderungen ab.

Der Reiz liegt im Ernstfall: Stirbt die Karte, wird umgesteckt und neu gestartet. Das ist die schnellste Wiederherstellung überhaupt – und der übliche erste Schritt, wenn ein Pi mit Kartenfehlern nicht mehr bootet.

In der Praxis ergänzen sich die Verfahren, statt zu konkurrieren: ein Abbild vor jedem größeren Eingriff, rsync jede Nacht, ein Klon für die Dienste, deren Ausfall im Haushalt sofort auffällt.

Raspberry Pi Backup automatisieren – Cron und die 3-2-1-Regel

Jede Sicherung, die an ein „mache ich am Wochenende" gebunden ist, endet irgendwann. Deshalb gehört der Ablauf in ein kleines Skript und dieses in einen Cronjob. Ein Eintrag über sudo crontab -e in der Form 0 3 * * * /usr/local/bin/pi-backup.sh startet die Sicherung jede Nacht um drei Uhr.

Ein brauchbares Skript macht vier Dinge in dieser Reihenfolge: Datenbanken dumpen, empfindliche Dienste kurz anhalten, rsync starten, alte Stände aufräumen. Wichtig ist die Rückmeldung – ohne Protokoll bemerkt niemand, dass der Job seit sechs Wochen an einem vollen Laufwerk scheitert. Eine Zeile ins Log und eine Benachrichtigung bei Fehlern, etwa über eine Überwachung wie Uptime Kuma, lösen das dauerhaft.

Für die Aufbewahrung hat sich die 3-2-1-Regel durchgesetzt: drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine außer Haus. Auf den Pi übersetzt: das laufende System, eine Kopie auf dem NAS oder einer externen SSD und ein monatliches Abbild, das bei Verwandten, im Büro oder in einer Cloud liegt. Wasserschaden, Diebstahl und Blitzschlag treffen sonst Original und Sicherung gleichzeitig.

Rücksicherung testen – der meistvergessene Schritt

Ein Backup ist erst dann eines, wenn es einmal zurückgespielt wurde. Berichte aus der Community zeigen ein immer gleiches Muster: Die Sicherung lief monatelang zuverlässig, und im Ernstfall fehlte ausgerechnet die Datenbank, das Abbild war halb geschrieben oder das Archiv ließ sich nicht entpacken.

Der Test kostet eine halbe Stunde und braucht nur eine zweite Speicherkarte. Abbild mit dem Imager oder mit sudo dd if=pi-backup.img of=/dev/sdb bs=4M status=progress conv=fsync zurückschreiben, Karte in den Pi, starten. Kommt das System hoch, laufen die Dienste, sind die Daten aktuell? Erst diese drei Häkchen machen aus einer Datei ein Backup. Wie das Klonen und Zurückschreiben einer Karte im Detail abläuft, zeigt die Anleitung zum SD-Karte klonen; Backup und Restore der SD-Karte sind zusätzlich als Videokurs Schritt für Schritt erklärt – ein kostenloses Einstiegsvideo gibt es dazu ebenfalls.

Wer keine Ersatzkarte opfern will, prüft wenigstens stichprobenartig: eine Datei zurückkopieren, einen Dump in eine leere Datenbank einlesen, das Archiv einmal vollständig entpacken. Das ersetzt den echten Test nicht, deckt aber die häufigsten stillen Fehler auf.

Fehler und Stolpersteine beim Sichern

• Falsches Ziel bei dd: Ein vertauschtes if und of überschreibt die Festplatte des Rechners. Vor dem Abschicken die Zeile zweimal lesen – dd fragt nicht nach.
• Abbild passt nicht auf die neue Karte: Zwei Karten mit „64 GB" haben selten dieselbe Sektorzahl. Deshalb entweder gleich mit PiShrink verkleinern oder auf eine größere Karte zurückschreiben.
• Datenbank im Betrieb kopiert: Der häufigste Grund für ein Backup, das sich später nicht öffnen lässt. Dumpen statt kopieren, oder den Dienst für die Dauer der Sicherung anhalten.
• Backup auf derselben Karte: Eine Sicherung im Ordner /home/pi/backup stirbt mit der Karte gemeinsam. Das Ziel muss ein anderes Gerät sein.
• Volles Ziellaufwerk: Ohne Aufräumen füllt sich das NAS mit Ständen, bis der Job stillschweigend abbricht. Alte Sicherungen automatisch löschen und den freien Speicher überwachen.
• Stromausfall während des Schreibens: Ein abgebrochener Schreibvorgang hinterlässt ein unbrauchbares Abbild und beschädigt im schlimmsten Fall das Dateisystem – ein Argument für eine USV am Dauerläufer.
• Schlüssel und Passwörter vergessen: Ein Abbild enthält sie, ein rsync-Backup nur, wenn versteckte Ordner wie ~/.ssh und ~/.config mitgesichert werden.

Häufige Fragen zum Backup des Raspberry Pi

Wie oft sollte ich meinen Raspberry Pi sichern?
Ein Abbild vor jedem größeren Eingriff und danach eine tägliche Dateisicherung deckt fast alle Fälle ab. Reine Bastelsysteme kommen mit einem Abbild pro Monat aus, ein Server mit Kamera- oder Dokumentendaten eher nicht.

Kann ich den laufenden Pi mit dd sichern?
Technisch ja, sinnvoll nein. Während des Lesens ändern sich Dateien, das Abbild wird uneinheitlich und startet unter Umständen nicht. Für die Sicherung im Betrieb sind rsync oder rpi-clone gedacht.

Wie groß wird das Abbild einer 64-GB-Karte?
Zunächst genau 64 GB, denn dd liest auch den leeren Bereich mit. Komprimiert schrumpft die Datei deutlich, mit PiShrink bleibt am Ende oft nur der tatsächlich belegte Platz übrig.

Sichere ich eine SSD genauso wie eine SD-Karte?
Ja, das Verfahren ist identisch – nur der Gerätename ändert sich. Wer den Pi ohnehin von einer SSD startet, profitiert zusätzlich von der höheren Lesegeschwindigkeit beim Erstellen des Abbilds.

Was mache ich mit Docker-Containern?
Die Container selbst müssen nicht gesichert werden, sie werden neu geladen. Entscheidend sind die compose-Dateien und die Volume-Ordner; Datenbanken darin bekommen zusätzlich einen eigenen Dump.

Reicht ein Cloud-Speicher als einzige Sicherung?
Als Auslagerung ist er ideal, als einziges Ziel riskant: Ein gelöschter oder verschlüsselter Ordner wird bei einer reinen Synchronisation sofort mit hochgeladen. Mindestens eine Kopie sollte offline und versioniert liegen.

Meine SD-Karte lässt sich nicht mehr lesen – ist alles weg?
Nicht zwangsläufig. Oft ist nur das Dateisystem beschädigt und lässt sich reparieren. Wichtig ist, zuerst ein Abbild der defekten Karte zu ziehen und alle Rettungsversuche an dieser Kopie durchzuführen.

Fazit

Ein gutes Raspberry Pi Backup besteht nicht aus einem Werkzeug, sondern aus einer Gewohnheit. Unsere klare Empfehlung: Ein vollständiges Abbild vor jedem größeren Umbau, eine nächtliche rsync-Sicherung auf ein anderes Gerät und zweimal im Jahr ein echter Rücksicherungstest. Wer einen Dienst betreibt, dessen Ausfall im Haushalt sofort auffällt, legt zusätzlich mit rpi-clone eine startbereite Zweitkarte ins Regal – die billigste Versicherung, die es für einen Raspberry Pi gibt. Und die unbequeme Wahrheit zum Schluss: Nicht das fehlende Backup kostet die Daten, sondern das nie getestete.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)