Automatisches indi-allsky Backup auf externem Laufwerk (Fritzbox NAS) – Phase 2: Dateien

Nachdem Datenbank, Konfiguration und Migrations von indi-allsky bereits automatisiert auf ein externes Laufwerk gesichert werden, habe ich mir im nächsten Schritt die eigentlichen Dateien vorgenommen: die Night-Images, aus denen später Timelapse, Keogramm und Startrails entstehen.

Die Basis dafür bildet Phase 1 des Backups, die ich hier beschrieben habe:

Automatisches indi-allsky Backup auf externem Laufwerk (Fritzbox NAS) – Phase 1

Phase 2 ist deutlich anspruchsvoller. Während Datenbank-Backups vergleichsweise klein und deterministisch sind, reden wir bei den Bilddaten schnell über mehrere Gigabyte pro Nacht – und über Daten, die nicht alle gleich wertvoll sind.

Warum nicht einfach „alles sichern“?

Ein Allsky-System produziert jede Nacht Bilder – unabhängig davon, ob der Himmel klar, teilweise bewölkt oder komplett unbrauchbar ist. Würde man alle Dateien blind sichern, wäre selbst eine große externe Festplatte sehr schnell voll.

Deshalb war von Anfang an klar: Das Backup muss qualitätsbasiert arbeiten.
Nicht jede Nacht ist gleich wertvoll – und das lässt sich bei indi-allsky sehr gut aus der Datenbank ableiten.

Und so bin ich vorgegangen…

Automatisches indi-allsky Backup auf externem Laufwerk (Fritzbox NAS)

In diesem Beitrag beschreibe ich, wie ich meine indi-allsky Installation auf meinem Raspberry Pi vollautomatisiert auf einer externen Festplatte sichere.

Die offizielle indi-allsky-Dokumentation beschreibt sehr gut, was gesichert werden sollte – lässt aber offen, wie man daraus ein belastbares, automatisiertes Backup macht.

In meinem Setup läuft indi-allsky dauerhaft auf einem Raspberry Pi. Die Sicherung erfolgt nicht lokal, sondern auf einer externen SSD an einer Fritzbox, angebunden per SMB.

Ziel war es, die Empfehlungen aus der offiziellen Dokumentation: Backup and Recovery – indi-allsky konsequent umzusetzen und produktionsreif zu erweitern:

  • externes Ziel
  • automatische Backups
  • Integritätsprüfungen
  • zeitbasierte Retention
  • Mail-Benachrichtigung bei Fehlern

…und so bin ich vorgegangen!

Digitaler Bilderrahmen mit Allsky-Bildern: Update mit Timelapse-Videos auf dem Raspberry Pi

Nachdem ich die Basis-Version meines Raspberry-Pi-Setups als digitalen Bilderrahmen einige Wochen im Alltag genutzt habe, war klar: Das System läuft stabil – aber das Dashboard selbst lässt sich deutlich verbessern.

Die Grundlage habe ich hier beschrieben:
Raspberry Pi als digitaler Bilderrahmen im Kiosk-Modus – Hardware, Setup & Troubleshooting

Dieses Update baut exakt darauf auf und beschreibt den finalen, bereinigten Stand, der inzwischen dauerhaft und unbeaufsichtigt läuft.

Raspberry Pi 5: microSD durch NVMe-SSD ersetzen und System sauber migrieren

Ich habe mein Raspberry-Pi-System von einer microSD-Karte auf eine NVMe-SSD umgezogen. Konkret kommt jetzt eine 512-GB-NVMe über einen PCIe-HAT zum Einsatz. Ziel war es, das System robuster, schneller und langfristig stabiler zu machen.

microSD-Karten sind für viele Raspberry-Pi-Projekte ausreichend, stoßen aber bei dauerhaftem Betrieb mit vielen Schreibzugriffen schnell an ihre Grenzen. In meinem Fall laufen unter anderem indi-allsky, Bildspeicherung, Datenbankzugriffe und regelmäßige Uploads. Dafür ist eine NVMe-SSD schlicht die bessere Wahl: höhere Performance, deutlich höhere Lebensdauer und weniger Risiko für Dateisystem-Probleme.

Im Folgenden beschreibe ich Schritt für Schritt, wie ich das bestehende System im laufenden Betrieb von der microSD auf die NVMe migriert habe.

Raspberry Pi als digitaler Bilderrahmen im Kiosk-Modus – Hardware, Setup & Troubleshooting

External displayIch hatte die verrückte Idee, einen digitalen Bilderrahmen zu bauen um darauf das immer aktuellste Foto meiner Allsky-Kamera anzeigen zu lassen. Auslöser war vor allem die Erkenntnis, dass es bei indi-allsky mit Redirect Views total einfach ist, das immer aktuellste Bild ausspielen zu lassen. Und die zweite Erkenntnis: Touch-Displays sind gar nicht mal so teuer.

In diesem Beitrag dokumentiere ich ein praxiserprobtes Setup mit Raspberry Pi 4, HDMI-Touchdisplay und Chromium im echten Kiosk-Modus – inklusive typischer Stolperfallen und deren Lösungen.

Hardware-Setup

Für das Setup wurden folgende Komponenten verwendet:

  • Raspberry Pi 4 (2–8 GB RAM)
  • HDMI-Touchdisplay (10,1 Zoll, 1280×800) – gibt es z.B. beim großen chinesischen Online-Händler – Detailinfos hier
  • MicroSD-Karte (mind. 32 GB)
  • Getrennte Stromversorgung für Raspberry Pi und Display
  • USB-Touchkabel + HDMI-Kabel

Anders als vom Hersteller angegeben nutze ich weder ein Y-Kabel noch eine Durchschleiflösung für die Stromversorgung von Pi und Display sondern ein Dual-Port-Netzteil (USB-C für den Pi, USB-A/Micro-USB für das Display).