Paperless-ngx, Teil 10: Das Rundum-sorglos-Backup
Der Aufbau unseres digitalen Archivs hat Zeit gekostet, die analoge Papierversion wurde entsorgt oder in den Keller verbannt, wir sind zufrieden, dass unser System rund läuft. Höchste Zeit für eine Backup-Strategie, die für einen Rundum-Schutz sorgt: Dokumente, Dateipfade, Tags, Notizen – ja, das gesamte System soll gegen alle Arten von Notfällen abgesichert werden. Und das in einer Art und Weise, die kaum Zeit oder Mühe beansprucht.
Inhalt
4-3-2-1 – Die besondere Backup-Strategie
Bekannt ist die 3-2-1-Regel für Backups: 3 x Daten (1 Original + 2 Backup-Versionen) auf 2 unterschiedlichen Speichermedien und 1 Sicherung außer Haus. Das gilt für „normale“ Computer oder Server. Aber beim Raspberry Pi können wir einen Klon des vollständigen „PCs“ in einer Streichholzschachtel aufbewahren, das ist Nr. 4. Dazu gleich mehr.
Zunächst zu den üblichen 3-2-1 Bedingungen: Für die lokale Sicherung taugt jedes übliche Speichermedium: eine zweite SD-Karte, ein USB-Stick, eine SSD, ein NAS usw. – Was man halt gerade zur Hand hat.
Für die Außer-Haus-Speicherung werde ich hier den Weg über eine Cloud-Sicherung beschreiben. Dabei ist es höchst gleichgültig, ob man Google Drive oder die Varianten von Microsoft bzw. Apple nimmt – die Daten werden trotzdem perfekt geschützt sein. Aber als Nextcloud-Anwender werde ich das Vorgehen mit dieser Cloud beschreiben.
Verschlüsseltes Cloud-Backup mit Duplicati
Duplicati gehört zu den bekannten Backup-Programmen, kann sehr viel und ist mit einer guten Nutzeroberfläche ausgestattet. Eine ältere Version gibt es zwar im Paketmanager vom Raspberry Pi, aber man kann problemlos mit der neusten arbeiten: Einfach auf die Homepage von Duplicati gehen, dort zu „Downloads“ und das Debian-Paket runterladen. Anschließend den Paketinstaller anklicken – fertig.
Duplicati kann über das Startmenü aufgerufen werden – es öffnet sich eine Weboberfläche für das Programm (localhost:8200). Dort konfiguriert man eine neue Sicherung:
Im ersten Schritt wird die Verschlüsselung aktiviert – die Voreinstellung „AES-256“ ist ausreichend:
Nun wird das Sicherungsziel ausgewählt. Sofern man eine Nextcloud verwendet, hat man zwei Möglichkeiten: Entweder man richtet zuvor den Desktop-Sync-Client ein (ist im Paketmanager des Raspberry Pi vorhanden) und trägt dort einen lokalen Pfad für den Sync der Backups ein (z.B. „/home/pi/paperless_backup“). Bei dieser Variante wählt man in Duplicati „Lokaler Ordner oder Laufwerk“ für die Speicherung aus – der Nextcloud-Client besorgt später den Rest.
Oder man wählt „WebDAV“ aus, dann klappt es auch ohne die Installation des Nextcloud-Clients. Ich habe in meiner Nextcloud einen zusätzlicher Nutzer namens „Paperless“ angelegt, so dass dieses Konto nicht durch andere Dateien belegt wird. Den notwendigen WebDAV-Link findet man im Dateibereich der Nextcloud, linke Sidebar, unten „Einstellungen“. Den kopiert man in die Zwischenablage und setzt ihn bei Duplicati zusammen mit seinen Nextcloud-Zugangsdaten ein.
Wichtig: Nicht die Protokollbezeichnung „https://“ im Serverfeld verwenden – aber „SSL“ ankreuzen. Anschließend wählt man den Pfad von Paperless-ngx aus. In den Unterpfaden befinden sich ja nicht nur Originale- und Archiv-Dateien – auch der Ordner „export“, in dem alle Einstellungen gespeichert sind.
Einen Zeitplan kann man ebenfalls einstellen. In diesem Beispiel wird 5 Uhr morgens, täglich, gewählt. Unser Raspberry Pi ist ja durchgehend in Betrieb, so dass er solche arbeiten gut in den frühen Morgenstunden erledigen kann.
Jetzt fragt Duplicati noch, ob mehrere Sicherungs-Version aufbewahrt werden sollen. Man könnte z.B. auswählen, dass die 3 letzten Version in der Nextcloud gespeichert werden sollen. Mit der Einstellung „Intelligente Sicherungsaufbewahrung“ fährt man aber recht gut. Man kann auf diese Weise vergangene Backups auswählen, ohne dass zu viel Speicherplatz in der Nextcloud belegt wird.
Zur angegebenen Zeit startet das Backup. Dabei kommt eine Variante des inkrementellen Backups zum Zuge, es werden also nur neue/geänderte Daten übertragen (in Wirklichkeit ist die Art des Duplicati-Backups noch cleverer, aber das würde hier zu weit führen).
In der Cloud landen die Dateien verschlüsselt – sie sind also für keinen Hoster einsehbar.
Über den Menüpunkt „Wiederherstellen“ lässt sich das letzte oder ein früheres Backup zurückspielen. Wenn nur eine einzelne Datei beschädigt ist, so kann man diese gezielt auswählen:
Damit ist Schritt 1 erledigt: Egal, ob Wasserschaden, Blitzeinschlag oder spielendes Kind – eine Rekonstruktion unseres Dokumentenarchivs ist im Falle des Falles außer Haus untergebracht. Verschlüsselt, in einem professionellen Rechenzentrum, von Fachpersonal betreut. Zudem wird das Archiv von Duplicati gepackt – es genügt also ein kleiner Serverbereich, den man bei seinem Cloud-Speicher vielleicht ohnehin noch übrig hat.
Lokales Backup
Back In Time
Wenn man ohnehin Duplicati für das Backup in der Cloud nutzt, so kann man darin einfach einen zweit Job erstellen, der diese Aufgabe übernimmt. Den eingehängten Ziel-Speicher, etwa eine SSD, findet man über das Root-Verzeichnis, dort /media/nutzer/speichermedium:
Allerdings: Falls nach einem Update mal was mit Duplicati nicht korrekt verläuft, so könnten sich gleich in beide Backups Fehler einschleichen. Etwas sicherer fährt man also mit einem zweiten Backup-Tool. Es gibt da unter Linux unzählige Möglichkeiten – mir gefällt besonders gut „Back In Time“ (die Basis für das Tool bildet rsync).
Das ist im Paketmanager von Raspberry Pi OS vorhanden, lässt sich also mit einem Klick installieren. Durch die klare Oberfläche wird die Auswahl von Quelle und Ziel bei der Konfiguration kein Problem darstellen – die Darstellung ähnelt der von Dateimanagern:
Für das lokale Backup würde ich auf die Verschlüsselungsoption verzichten, da sie keine Vorteile bringt. Die Daten liegen ja ohnehin auf dem Raspberry Pi offen – ein Agent der Gegenseite würde also einfach die kleine Schachtel in seine Jackentasche stecken 😉 Der Zielspeicher muss zwar im Linux-Forma formatiert sein (also z.B. EXT4 und nicht FAT), aber Tools wie Rufus & Co. erledigen das ja mit einem Klick. Notwendig ist dies, damit auch bei diesem Backup Speicherplatz gespart wird. Und wegen der „Zeitmaschine“. Man kann in Back In Time sehr bequem in der Zeit reisen und Dateien eines früheren Backups reaktivieren.
Wie bei Duplicati ist auch die Zeitplanung eingebaut, die man mit ein paar Haken einrichten kann. Oder man nimmt die Einstellung, dass das Backup immer durchgeführt wird, wenn man das Speichermedium einhängt usw.
Borg-Backup mit Vorta
Wer mit Linux etwas vertrauter ist, dem ist sicher schon einmal der Begriff „Borg“ für Backups untergekommen. Eine Sicherungsvariante, die von vielen sehr geschätzt wird, aber in der Einrichtung nicht ganz einfach ist. Mit Vorta steht eine Oberfläche für diese Art des Backups zur Verfügung, die sich mit einem einfachen Befehl in der Kommandozeile installieren lässt:
sudo apt install vortaÜber das Raspberry Pi-Desktop-Menü lässt sich Vorta anschließend aufrufen und einrichten:
Damit könnte man auch ein Backup auf ein NAS überspielen. Aber da gibt es auch zahlreiche andere Möglichketen, über ein Netzwerk eine Sicherung herzustellen (NFS wäre hier ein Stichwort).
Backup von allem: SD-Karte mit 1 Klick klonen
SD Card Copier
Eine Besonderheit des Raspberry Pi ist, dass auf der microSD-Karte (oder einem USB-Speichermedium) das gesamte lauffähige System liegt. Eingebaut in Raspberry Pi OS ist ein Tool, mit dem sehr einfach eine Dublette erzeugt werden kann: „SD Card Copier“.
Dabei müssen Quell- und Zielmedium nicht die gleiche Größe haben (das Zielmedium muss halt groß genug sein, um alle Dateien aufzunehmen).
Also: Leere microSD-Karte z.B. mit einem USB-Adapter in den Raspberry Pi stecken und auswählen (= Auf Gerät kopieren). Quell-Laufwerk (= Von Gerät kopieren) ist jene Karte, mit der der Raspberry Pi gerade läuft. Je nach Umfang der Sicherung etwas warten (bei mi meist um die 10 Minuten). Danach hat man eine 1:1 Kopie seines Raspberry Pi-Systems, das man in die Schublade für Notfälle legen kann. Sollte später etwas nicht mehr funktionieren – einfach diese Karte einstecken und der Raspberry Pi ist sofort wieder lauffähig. Natürlich funktioniert auch Paperless-ngx umgehend, lediglich die neuen Dateien müssen hinzugefügt werden. Aber durch das regelmäßige Backup des Export-Folders ist das eine Sekundensache.
PiSafe
Es müssen nicht physische Karten sein – mit dem Tool PiSafe können auch Image-Dateien angefertigt werden, die man regelmäßig speichert und erst bei Bedarf auf ein Medium überspielt. Enthalten ist PiSafe ist der absolut empfehlenswerten Tool-Sammlung „Pi Apps“. Wieder genügt ein Klick – und die Anwendung ist installiert.
PiSafe führt automatisch eine Reihe von Anwendungen aus (dd-Befehl, pi shrink usw.). Das Ergebnis: Man erhält eine sehr kleine Image-Datei (bei mir waren auf einer 128 GB-Karte ca. 26 GB belegt – die Image-Datei hatte nur 6 GB) – samt Datum im Dateinamen.
Bonus-Tipp: Der Westentaschen-Tresor
Seit ca. 2 Jahren kann ein Raspberry Pi auch über USB-Sticks und andere Medien gebootet werden. Ich persönlich mag allerdings die kleinen Karten, da ich neben Backups auch alternative Betriebssysteme für den Raspberry Pi damit bestücke. So habe ich z.B. eine Karte für Manjaro, eine für Ubuntu usw.
Ganz nett für die Sammlung derartiger SD-Karten sind jene „Scheckkarten“, die man sogar im Geldbeutel mit sich führen kann. Wenn man ein kleines RFID-Etikett drauf klebt, so kann man sich eine Liste mit entsprechenden Vermerken anzeigen lassen. Bei mir öffnet sich die entsprechende Notiz in Obsidian. Aber da Paperless-ngx seit Version 2 auch Links zu Dokumenten zur Verfügung stellt, könnte man sogar dort eine entsprechende Tabelle aufbewahren.
Bisherige Teile der Paperless-ngx-Serie:
Teil 1: Ausführlicher Überblick
Teil 2: Suche & Tags
Teil 3: consume-Ordner – Einsatz von Scannern
Teil 4: Speicherpfade konfigurieren
Teil 5: Installation auf dem Raspberry Pi
Teil 6: Neue Funktionen in Version 2
Teil 7: Dokumente unterwegs über das eigene Modem abrufen
Teil 8: Exportfunktion nutzen
Teil 9: Update durchführen
Teil 10: Das Rundum-sorglos-Backup
Teil 11: Mail-Abruf mit vielen Extras
Teil 12: Mein Alltag mit Paperless-ngx
Teil 13: Ein Quanten-Code für das Papier-Archiv
FORUM für Fragen eröffnet
Teil 14: Automatisierte Ablage auf Speicherpfaden
Teil 15: Neue Funktion für das Verbinden und Trennen von Dokumenten
Das könnte dich ebenfalls interessieren
Container-Tabs – Facebook und Co. hinter Gittern (Firefox)
Struktur mit Ordner-Vorlagen
18 Kommentare
Sascha
Mein System habe ich soweit aufgebaut und alless läuft. Nun habe ich auch die ersten Backup Strategien übernommen und fühle mich soweit sicher gewappnet, meine kommenden Dokumente digital zu verwalten und auch alte Ordner peu à peu einzupflegen. Allerdings mache ich mir ein wenig Sorgen, dass paperless-ngx auf einer SD Karte läuft. Ich habe zwar eine HDD per USB 3.0 für das Backup dranhängen und gerade läuft SD Card Copier zum ersten Mal, aber wäre es nicht sinnvoller, weil sicherer (?) zeitnah das System auf eine SSD Karte (ebenfalls per USB) zu übertragen? Und würde das genau so einfach per SD Card Copier laufen und ich könnte dann einfach die SD Karte rausziehen und booten?
Vielen Dank und einen schönen Sonntag Abend aus dem Norden!
Sascha
Herbert
Hallo Sascha, da man von einem USB-Medium (z. B. einem USB-Stick) booten kann, sollte es eigentlich keine Probleme geben (habe ich aber noch nicht getestet). Statt „SD Card Copier“ kannst Du auch PiSafe nehmen: https://github.com/RichardMidnight/pi-safe Das koppelt automatisch Image plus Verkleinerung plus Speicherung usw. – sehr empfehlenswert.
Zur Frage der microSD-Karte: Da haben etliche Nutzer Bedenken – allerdings habe ich das Gefühl, dass oft die Billig-Varianten genutzt werden. Wenn man z.B. von SanDisk „Extreme“ oder „Extreme Pro“ nimmt, so erreicht man durch eine spezielle Technik, die auf diesen Karten eingesetzt wird, nach meiner Erfahrung sehr hohe Geschwindigkeiten ohne Stabilitätsverluste. Ich setze bevorzugt die 128-GB-Modelle ein – meine Erfahrungen sind seit rund drei Jahren sehr gut.
Rainer
Hallo Herbert, herzlichen Dank für deine ausgezeichnete Beschreibung. Ich habe Paperless-ngx auf einem HP Thin Client mit Debian Bookworm und XFCE installiert. Für das Backup mit Duplicati und Back In Time habe ich deine Anleitung verwendet und beide funktionierten auf Anhieb. Zum Backup habe ich aber noch ein paar grundsätzliche Fragen und vor allem auch zum Restore.
Ist es sinnvoll, den vollständigen Ordner paperless-ngx zu sichern und nicht nur den export-Ordner? Wie du im Teil 8 beschreibst, kann man die Daten nach einer Neuinstallation mit dem document_importer wiederherstellen.
Was passiert, wenn ich nach einer Neuinstallation den Inhalt des vollständigen Ordners wieder zurückspiele? Kann es Konflikte mit Ordnern und Daten geben, die während der Neuinstallation angelegt und erstellt wurden?
Auch das Zurückspielen von einzelne Dateien aus dem Backup halte ich für problematisch. Was passiert in diesem Fall mit den Datenbankeinträgen? Ich würde mich freuen, wenn du in einem weiteren Kapitel das Thema Restore behandeln würdest.
Im Voraus herzlichen Dank und viele Grüße aus dem Münsterland,
Rainer
Herbert
Hallo Rainer, die Anregung, etwas zum Restore zu schreiben, nehme ich gerne auf. Auch bei mir läuft Paperless-ngx auf der neuen MX Linux-Version mit XFCE, die speziell für den Raspberry Pi entwickelt wurde. Ausgesprochen schnell und gut 🙂
Zu Deinen Fragen:
1. Ruhig den ganzen Paperless-ngx-Ordner sichern, in dem „archive“, „originale“ und „export“ liegen. So bleibst Du unabhängig von Paperless-ngx, sofern Du Dir die Dateipfade so angelegt hast, wie ich es beschrieben habe.
2. Allerdings für Restore-Vorhaben nur den export-Ordner in den (neuen) Paperless-ngx-Pfad hängen, nicht die Ordner „archive“ und „originale“. Anschließend Import-Befehl – dann sind die neuen „archive“ und „originale“ korrekt rekonstruiert durch den Import-Befehl.
3. Einzelne Dateien für ich nicht auf den Pfad Paperless-ngx zurück-sichern. Falls wirklich mal mit einem Dokument etwas nicht stimmt: a) In Paperless-ngx löschen, b) clean-Befehl in Paperless-ngx ausführen, c) Dokument aus Backup-„originale“ nehmen und auf den consume-Pfad legen.
Florian
Hallo Herbert,
ich finde die Anleitung super, ich baue gerade für Freunde jeweils einen Raspberry auf und setze die Tips um.
Eines wäre für mich wichtig, da der Raspberry PI 400 nicht am Bildschirm angeschlossen wird , sondern als „Mini“ Server in der Abstellkammer steht, frage ich ich mich, ob eine Fernwartung möglich wäre um z.B. die Duplicat oder Borg zu verwalten. Kannst du mir eun Remote Desktop Programm emfpehlen ?
Grüße
Florian
Herbert
Ich manage auch alles via Remote – „RealVNC“ ist da aus meiner Sicht die Nr. 1 für Raspberry Pi 4 und 5.
Thomas
Hallo,
danke für die wirklich sehr hilfreichen Beschreibungen. Eine Anmerkung habe ich aber doch: Duplicati startet nicht automatisch beim Neustart des Raspbery Pi. Man muss Duplicati erst neu über das Startmenu starten.
Schön wäre ein Automatismus nach dem Neustart des Raspberrys. Vielleicht kannst Du die Anleitung entsprechend erweitern.
Herbert
Danke für den Hinweis! Nehme ich gerne auf – werde bei Gelegenheit ergänzen, wie man Programme in die Autostart-Gruppe einpflegt.
Rainer
Hallo Herbert,
nach einer erfolgreichen Datensicherung mit dem Sicherungsziel Microsoft OneDrive habe ich heute versucht, die Backup-Daten mit Hilfe von WebDAV auf meinem Nextcloud-Konto abzuspeichern. Die NC hat die Version 28.0.5.
Dazu habe ich zuerst ein Update von Duplicati auf die Version 2.0.8.1 durchgeführt und auf der NC den Ordner „Paperless-Sicherung“ erstellt. Dann habe ich in Duplicati ein neues Backup hinzugefügt und die Einträge für das Sicherungsziel WebDAV gemäß deiner Anleitung vorgenommen, d.h. auch Häkchen bei „SSL benutzen“ gesetzt und „https://“ bei der Server-URL gelöscht. Nach „Verbindung prüfen“ erhalte ich die Fehlermeldung „Failed to connect: Error: SecureChannelFailure (Authentication failed, see inner exception.)“ Hast du diesen Fehler schon einmal beobachtet?
Viele Grüße
Rainer
Yorj
Hallo Herbert,
erst einmal vielen Dank für diene tolle Schritt für Schritt Anleitung und die vielen Tipps und Anregungen für die Einrichtung von paperless-ngx. Ich konnte mir mit der Anleitung ein sehr gut laufendes DMS aufbauen und bin damit sehr zufrieden. Nachdem der Großteil der Einrichtungen abgeschlossen ist und die ersten Dokumente eingepflegt wurden wollte ich mir ein reglmäßiges Backup etstellen und dieses mit Duplicati auch in der Cloud automatisch sichern. Hier stoße ich bei der Installation von Duplicati allerdings auf massive Probleme. Ich habe die aktuelle Version (2.0.8.1-1) heruntergeladen und mit dem Paketinstaller installiert. Es wird die Sanduhr angezeigt und irgenwann ist wieder der Mauspfeil da, sonst passiert nichts. Duplicati ist aber nicht im Menü verfpgbar und auch über den Browser bekomme ich mit „localhost:8200“ nur eine Fehlermeldung, dass die Seite nicht erreichbar sei.
Ich habe das ganze auch mit der von dir in der Anleitung genutzten Verions 2.0.7.1-1 versucht, mit dem selben Ergebnis. Auch ein Neustart meines Raspi hat nichts gebracht.
Kannst du mir sage was ich falsch mache?
Ich habe einen Raspi 5 mit 8 GB und dem aktuellen 64 bit Raspberry Pi OS bookworm installiert. Der Pi5 lässt auch keine andere Version zu.
Es scheint hier ein generelles Problem mit bookworm und Duplicati zu geben. Du schreibst aber oben, dass bei dir auch bookworm läuft. Hast du vielleicht einen Tipp, was ich machen kann, damit Duplicati bei mir läuft?
Vielen Dank im Voraus.
York
Herbert
Eigentlich sollte es klappe (ich nutze inzwischen MX Linux auf meinem Raspberry Pi). Probier‘ mal die aktuelle Debian-Version, die Du auf der Homepage findest: https://duplicati.com/download
York
Hallo Herbert,
danke für die schnelle Antwort. Ich habe es sowohl mit der aktuellen Datei, als auch der Version versucht, die du genutzt hast. Es passiert immer das selbe. Der Pi arbeitet und es wird die Sanduhr angezeigt. Nach einiger Zeit verschwindet die Sanduhr. Sonst passiert nichts. Duplicati erscheint weder im Menü, noch kann ich es im Broser direkt über den Link aufrufen. „DIe Webseite ist nicht erreichbar“.
Ich hab inzwischen auch versucht Duplicati manuell zu installieren, aber auch das schlägt fehl.
OK:9 https://download.mono-project.com/repo/debian stable-raspbianbuster InRelease
Ign:4 https://download.mono-project.com/repo/debian raspbianbookworm InRelease
Fehl:10 https://download.mono-project.com/repo/debian raspbianbookworm Release
404 The specified blob does not exist. [IP: 2620:1ec:bdf::67 443]
Paketlisten werden gelesen… Fertig
N: Das Laden der konfigurierten Datei »main/binary-arm64/Packages« wird übersprungen, da das Depot »https://download.mono-project.com/repo/debian stable-raspbianbuster InRelease« die Architektur »arm64« nicht unterstützt.
E: Das Depot »http://download.mono-project.com/repo/debian raspbianbookworm Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
Herbert
Habe es gerade zur Sicherheit mit der aktuellen Duplicati-Version auf einem puren Raspberry Pi OS ausprobiert – funktioniert.
Führe mal folgende Schritte aus:
1. Evtl. ist bei Dir noch nicht Mono installiert, daher im Terminal eingeben: „sudo apt install mono-complete“
2. Du hast ja schon die aktuelle Debian-Version von der Homepage geladen, zu Deinem Download-Ordner gehen und „sudo dpkg -i duplicati_2.0.8.1-1_all.deb“ eingeben (sofern das bei Dir der gleiche Dateiname für die deb-Datei ist – sonst die Zeile anpassen).
3. Falls jetzt eine Fehlermeldung kommt, werden es fehlende Abhängigkeiten sein. Das behebst Du mit „sudo apt -f install“.
Mit diesen 3 Schritten sollte alles erledigt sein und der Menüpunkt „Duplicati“ erscheinen. Der startet die Webansicht von Duplicati in Deinem Browser.
York
Erst mal vielen Dank für deine Hilfe…
Es hängt schon beim Versuch mono zu installieren:
sudo apt install mono-complete
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
mono-complete : Hängt ab von: mono-runtime (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-runtime-sgen (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-utils (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-devel (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-mcs (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-csharp-shell (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-4.0-gac (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: mono-4.0-service (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: monodoc-base (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: monodoc-manual (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: libmono-cil-dev (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
Hängt ab von: ca-certificates-mono (= 6.8.0.105+dfsg-3.3) soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
York
Ich habe jetzt auch noch einmal versuch mono mit der Anleitung auf der mono Seite zu installieren…
sudo apt install dirmngr ca-certificates gnupg
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
dirmngr ist schon die neueste Version (2.2.40-1.1).
ca-certificates ist schon die neueste Version (20230311).
gnupg ist schon die neueste Version (2.2.40-1.1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
———–
sudo gpg –homedir /tmp –no-default-keyring –keyring /usr/share/keyrings/mono-official-archive-keyring.gpg –keyserver hkp://keyserver.ubuntu.com:80 –recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
gpg: Schlüssel A6A19B38D3D831EF: „Xamarin Public Jenkins (auto-signing) “ nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1
————————
echo „deb [signed-by=/usr/share/keyrings/mono-official-archive-keyring.gpg] https://download.mono-project.com/repo/debian stable-raspbianbookworm main“ | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
deb [signed-by=/usr/share/keyrings/mono-official-archive-keyring.gpg] https://download.mono-project.com/repo/debian stable-raspbianbookworm main
—————-
sudo apt update
OK:2 http://deb.debian.org/debian bookworm InRelease
OK:3 http://deb.debian.org/debian-security bookworm-security InRelease
OK:4 https://download.docker.com/linux/debian bookworm InRelease
OK:5 http://deb.debian.org/debian bookworm-updates InRelease
OK:6 http://archive.raspberrypi.com/debian bookworm InRelease
Ign:7 https://download.mono-project.com/repo/debian stable-raspbianbookworm InRelease
Ign:1 https://download.mono-project.com/repo/debian raspbianbookworm InRelease
Fehl:9 https://download.mono-project.com/repo/debian stable-raspbianbookworm Release
404 The specified blob does not exist. [IP: 2620:1ec:bdf::67 443]
Fehl:8 https://download.mono-project.com/repo/debian raspbianbookworm Release
404 The specified blob does not exist. [IP: 2620:1ec:bdf::67 443]
Paketlisten werden gelesen… Fertig
E: Das Depot »https://download.mono-project.com/repo/debian stable-raspbianbookworm Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
E: Das Depot »http://download.mono-project.com/repo/debian raspbianbookworm Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
Herbert
Wenn es immer noch zu Fehlern kommt, dann werde ich leider nicht helfen können. Wie gesagt, wenn man genauso vorgeht, wie ich es beschrieben habe, klappt es problemlos bei mir auf 2 unterschiedlichen Raspberry Pi Geräten. Und wie gesagt: wichtig ist, dass man nicht light oder 32bit einsetzt, mindestens einen Raspberry Pi 4 mit 3GB verwendet usw. Du kannst es ja testweise mit einer „leeren“ microSD versuchen – aber wenn alle Bedingungen erfüllt sind, weiß ich da leider keinen Rat mehr.
EinUser
Ich hatte auch das Problem. Duplicati war installiert und schmiert ab.
Bei mir war es eine zu langsame Speicherkarte (Raspberry Diagnostic Fail)
Mit einer neuen läuft es ohne Probleme.
Installation über Terminal via:
sudo apt install ./
Das installiert die abhängigen Pakete mit
Grüße
York
Vielen Dank für die Hilfe… ich habe mittlerweile das Problem gelöst…
Hier die Erklärung, falls noch einmal jemand anders über das selbe Problem stolpern sollte.
Iich habe gestern eine neue SD-Karte genommen (baugleich zur ersten – SanDisk extrem pro). Da ich dieses mal Duplicati direkt nach der Ersteinrichtung des Pis installiert habe, hatte ich den Pi noch am TV angeschlossen und noch nicht wieder an seinen eigentlichen Platz unterm Dach gebracht, wo ich sonst nur mittels Remotezugriff darauf zugreife. Dieses mal hat alles ohne Probleme funktioniert. 🙂 – Dann hab ich die erste SD-Karte wieder eingesteckt und auch dort hat alles funktioniert… – Dann habe ich es noch einmal deinstalliert und wollte es über die Remoteverbindung neu installieren und es ging wieder nicht. Das Popup für die Bestätigung tauchte einfach nicht auf. Ein Blick vom PC-Bildschirm auf den TV brachte dann die Lösung. Da war nämlich das Popup für die Bestätigung.
Das Problem war also die RDP-Verbindung, die anscheinend bestimmte Fenster nicht auf dem Remote anzeigt, sondern immer auf dem Desktop des Raspi… Mit einer VNC-Verbindung sehe ich immer den gleichen Desktop (vom Raspi) und keinen eigenen wie bei RDP.
Trotzdem vielen Dank für eure Hilfeversuche. – Jetzt läuft alles nach dem Importieren auf der neuen Karte und dem frisch installierten Raspi.
Vielleicht noch ein Tipp zur Beschreibung beim Importieren. Ich habe die ZIP in das „export“ Verzeichnis kopiert und wollte meine Einstellungen wie beschrieben importieren, dann bekam ich immer eine Fehlermeldung. Erst nach dem Entpacken der beiden JSON-Dateien hat das Importieren aus der ZIP ohne Probleme funktioniert.