Ein zuverlässiges Backup macht den Unterschied zwischen einem kurzen Ausfall und einem echten Neuanfang. Bei einem Raspberry Pi geht es dabei selten nur um einzelne Dateien: Oft müssen Systemkonfigurationen, Dienste, Boot-Einstellungen und Projektstände zusammen gesichert werden, damit der Rechner nach einem Defekt oder einer missglückten Änderung schnell wieder läuft. Ich zeige hier, welche Sicherungsarten sich in der Praxis bewährt haben, welches Medium sinnvoll ist und wie du ein bootfähiges Abbild oder ein sauberes Dateibackup anlegst.
Ein gutes Raspberry-Pi-Backup schützt System, Daten und die Zeit, die du bereits investiert hast
- Systemklon und Dateibackup lösen unterschiedliche Probleme und sollten nicht verwechselt werden.
- Für schnelle Rückkehr nach einem Fehler ist ein bootfähiges Abbild ideal.
- Für laufende Projekte, Konfigurationen und Daten ist rsync meist flexibler als ein Vollimage.
- Eine USB-SSD ist als Zielmedium in vielen Setups robuster als eine zweite SD-Karte.
- Ein Backup zählt erst dann wirklich, wenn es sich testweise wiederherstellen lässt.
Ich trenne bei einem Raspberry Pi grundsätzlich zwischen zwei Ebenen: Wiederanlauf und Wiederherstellung. Ein Klon sorgt dafür, dass der Pi schnell wieder bootet. Ein Dateibackup sorgt dafür, dass du auch einzelne Konfigurationen, Datenbanken oder Projekte sauber zurückholen kannst. Genau diese Trennung verhindert die typischen Lücken, die man erst im Ernstfall bemerkt.
Welche Daten ein Raspberry-Pi-Backup wirklich enthalten muss
Wer nur den Home-Ordner sichert, hat oft nur die halbe Arbeit erledigt. Auf einem Pi liegen wichtige Informationen an mehreren Stellen: in den Benutzerdateien, in Systemkonfigurationen, in Dienstdaten und im Boot-Bereich. Gerade bei Raspberry Pi OS gehen leicht Anpassungen verloren, die nicht offensichtlich sind, aber für das nächste Booten entscheidend bleiben.
| Bereich | Typische Inhalte | Warum das wichtig ist |
|---|---|---|
/home |
Projekte, Skripte, Dokumente, Medien, SSH-Schlüssel | Das sind meist die eigentlichen Nutzdaten |
/etc |
Netzwerk, Dienste, Cronjobs, Samba, SSH, Konfigurationen | Hier steckt viel vom Verhalten des Systems |
| Boot-Bereich | Boot-Konfiguration, etwa Pi-spezifische Einstellungen | Fehlt das, startet ein geklonter Pi oft nicht wie erwartet |
/var/lib und Anwendungsdaten |
Datenbanken, Home-Assistant-Daten, Pi-hole, Container-Volumes | Dort liegen häufig die eigentlichen Projektdaten |
| Paket- und Softwarezustand | Installierte Pakete, eigene Dienste, Abhängigkeiten | Hilft, den Stand reproduzierbar wieder aufzubauen |
Ich sichere deshalb nie nur „Dateien“, sondern immer auch den Kontext, in dem sie funktionieren. Die offizielle Raspberry-Pi-Dokumentation empfiehlt für größere Versionssprünge ohnehin eher eine frische Installation als ein In-Place-Upgrade; genau deshalb lohnt es sich, Daten und Systemzustand getrennt zu denken. Aus dieser Trennung ergibt sich direkt die nächste Frage: Welche Sicherungsmethode ist für welchen Zweck die richtige?
Welche Sicherungsmethode in welchem Fall sinnvoll ist
Nicht jede Methode passt zu jedem Pi. Ein Bastelrechner mit gelegentlichen Experimenten braucht etwas anderes als ein Home-Assistant-Server oder ein Pi-hole, das einfach weiterlaufen soll. Ich bewerte die Optionen deshalb nach drei Kriterien: Wie schnell komme ich zurück, wie gut lässt sich die Sicherung wiederherstellen, und wie sauber kann ich Änderungen nachziehen?
| Methode | Stärken | Grenzen | Mein Einsatzfall |
|---|---|---|---|
Vollimage mit dd oder Image-Tool |
Exakter Schnappschuss des Systems | Auf laufenden Systemen riskant, meist groß und langsam | Wenn die Karte offline gesichert werden kann |
| SD Card Copier | Einfach, bootfähig, für den Desktop bequem | Vor allem für Raspberry Pi OS mit Desktop interessant | Einmalige 1:1-Kopie oder Ersatzkarte |
rpi-clone |
Bootfähiger Klon eines laufenden Systems, später inkrementell | Kommandozeile, Zielmedium muss passend vorbereitet sein | Regelmäßige Klone auf USB-SSD oder zweite Karte |
rsync |
Flexibel, klein, ideal für einzelne Daten und Konfigurationen | Allein kein bootfähiger Ersatz | Systemdaten, Projekte, Konfigurationsstände |
Für den schnellen Alltag mag ein reines Image attraktiv wirken, aber ich halte es für die unpraktischste Wahl, wenn der Pi unter Last läuft. Das Raspberry-Pi-Projekt selbst hat mit dem SD Card Copier seit Langem ein Bordmittel für die Desktop-Edition, und genau das zeigt die Richtung: Für einen unkomplizierten Klon ist ein Kopierwerkzeug meistens sinnvoller als rohe Blockkopien. Für wiederkehrende Sicherungen ist rpi-clone oft die stärkere Wahl, weil es nach dem ersten Lauf nur noch Änderungen übernimmt. Damit sind wir bei der eigentlichen Praxis angekommen: Wie legst du so ein bootfähiges Backup an, ohne dir unnötig Probleme einzubauen?
So erstellst du ein bootfähiges Backup auf einem laufenden Pi
Wenn der Pi weiterlaufen soll, muss die Sicherung mit Änderungen während des Kopierens umgehen können. Genau deshalb bevorzuge ich bei aktiven Systemen Werkzeuge, die den laufenden Zustand sauber aufnehmen, statt nur einen rohen Blockdump zu ziehen. Das spart Zeit und reduziert das Risiko, ein inkonsistentes Abbild zu erhalten.
- Zielmedium anschließen. Das kann eine USB-SSD, ein hochwertiger USB-Stick oder eine zweite SD-Karte im Kartenleser sein.
-
Quelle und Ziel prüfen. Vor jedem Kopieren kontrolliere ich mit
lsblkoder einer ähnlichen Anzeige, welches Laufwerk wirklich das Ziel ist. - SD Card Copier nutzen, wenn du eine Desktop-Umgebung hast. Das Werkzeug ist für eine schnelle, bootfähige Kopie angenehm direkt.
-
rpi-clonenutzen, wenn du regelmäßig sicherst. Der erste Lauf legt den Ziel-Datenträger an, spätere Läufe synchronisieren nur geänderte Daten. - Nach dem Kopieren sofort testbooten. Eine Sicherung, die nie gestartet wurde, ist nur eine Vermutung.
Ein typischer Ablauf mit rpi-clone sieht in der Praxis sehr schlank aus:
lsblk
sudo rpi-clone sdasda ist hier nur ein Beispiel. Entscheidend ist nicht der Befehl selbst, sondern die Gewissheit, dass du die richtige Platte ansprichst. Ich setze bei solchen Kopien immer auf Ruhe und Kontrolle statt auf Geschwindigkeit. Ein falsches Zielmedium vernichtet im Zweifel genau die Sicherung, die dich schützen sollte. Sobald die Methode steht, bleibt die Frage nach dem Medium selbst, und dort unterscheiden sich die Optionen deutlicher, als viele erwarten.
Welches Backup-Medium sich am meisten lohnt
Ich würde 2026 für die meisten Pi-Setups nicht mehr automatisch zur zweiten SD-Karte greifen. Sie ist praktisch, aber als langfristiges Backup-Medium die schwächste Option. Für häufige Sicherungen und Wiederherstellungen ist eine USB-SSD meist die beste Mischung aus Geschwindigkeit, Robustheit und Verlässlichkeit. Wer zusätzlich auf Datenschutz achtet, sollte sensible Sicherungen verschlüsseln oder zumindest physisch getrennt lagern.
| Medium | Vorteile | Nachteile | Geeignet für |
|---|---|---|---|
| SD-Karte | Günstig, direkt kompatibel, gut als Notfallreserve | Empfindlicher bei vielen Schreibvorgängen | Kleine Systeme, Ersatzkarte, schnelle Klone |
| USB-SSD | Schnell, langlebiger, gut für häufige Backups | Benötigt Gehäuse oder Adapter, etwas teurer | Regelmäßige Spiegelung und bootfähige Kopien |
| USB-Stick | Einfach mitzunehmen, oft unkompliziert | Qualität stark unterschiedlich | Transport, temporäre Sicherungen |
| NAS oder Netzlaufwerk | Außerhalb des Pi, gut für Versionierung und Offsite-Strategien | Abhängig vom Netzwerk, Restore langsamer | Dateibackups, zusätzliche Kopie, Archiv |
Als grobe Planung habe ich gute Erfahrungen damit gemacht, für Image-Backups mindestens die belegte Datenmenge plus 20 bis 30 Prozent Reserve einzuplanen. Kleine Testsysteme kommen oft mit 32 GB aus, produktive Setups mit Logs, Datenbanken oder Containern wirken auf 64 GB oder mehr deutlich entspannter. Wenn private Daten mit im Spiel sind, verschlüssle ich das Zielmedium lieber einmal zu viel als einmal zu wenig. Doch selbst das beste Medium hilft nicht, wenn der Rückweg ungetestet bleibt, und genau dort passieren die meisten Fehler.
Warum viele Backups erst beim Restore scheitern
Ein Backup kann technisch „vorhanden“ sein und trotzdem wertlos bleiben. Das passiert vor allem dann, wenn nur ein Teil des Systems gesichert wurde oder wenn nie geprüft wurde, ob das Backup tatsächlich bootet. Ich sehe in der Praxis immer wieder dieselben Fehler, und sie sind vermeidbar.
-
Nur
/homesichern. Dann fehlen oft Dienste, Netzwerkeinstellungen und Boot-Anpassungen. - Das Backup auf demselben Medium wie das Original lassen. Ein Defekt, ein Stromausfall oder ein falsches Update trifft dann beides.
- Nie testen. Ein Klon, der nicht einmal probeweise gestartet wurde, ist keine belastbare Sicherheitsreserve.
- System und Daten vermischen. Wer alles in ein einziges riesiges Image packt, macht spätere Teilwiederherstellungen unnötig schwer.
- Bei großen Versionssprüngen alt gegen neu mischen. Ich würde bei einem Wechsel auf eine neue Hauptversion von Raspberry Pi OS eher frisch installieren und nur Daten sowie Konfigurationen zurückholen.
- Keine Versionierung. Ein versehentlich synchronisiertes Fehlerbild überschreibt sonst den letzten guten Stand.
Mein Minimum ist daher einfach: eine aktuelle Sicherung, eine ältere Sicherung und ein kurzer Wiederherstellungstest auf Ersatzhardware. Wenn du das quartalsweise machst, erkennst du Probleme, bevor sie zum echten Ausfall werden. Aus dieser Praxis ergibt sich eine Routine, die nicht spektakulär ist, aber zuverlässig funktioniert.
Mit dieser Routine deckst du die meisten Pi-Szenarien ab
Für die meisten Projekte reicht ein nüchterner Aufbau völlig aus: rsync für Daten und Konfigurationen, dazu ein bootfähiger Klon für den schnellen Neustart. Wer viel experimentiert, legt vor größeren Änderungen zusätzlich einen frischen Klon an. Wer produktive Dienste betreibt, trennt die Sicherung auf mindestens zwei Ziele, etwa eine SSD und ein NAS. Genau diese Kombination ist in meinen Augen der vernünftige Mittelweg zwischen Aufwand und Schutz.
Wenn ich ein Raspberry-Pi-System heute neu absichern müsste, würde ich so vorgehen: erst die wichtigen Daten und Konfigurationen identifizieren, dann ein robustes Zielmedium wählen, anschließend einen bootfähigen Klon anlegen und zuletzt einen echten Restore-Test machen. Das klingt unspektakulär, spart aber im Ernstfall Stunden. Ein gutes Backup ist nicht das schönste Image, sondern das, das du nach einem Fehler ohne Überraschungen wieder starten kannst.
