Beachte dabei, dass SeedVault-Backups ausschließlich zwischen CalyxOS-Geräten oder GrapheneOS-Geräten kompatibel sind. Ein plattformübergreifender Einsatz (z. B. CalyxOS zu GrapheneOS) wird nicht unterstützt und kann zu Fehlern führen.

Mit SeedVault und einem USB-Stick könnt ihr eure Daten jederzeit schützen und wiederherstellen – egal ob ihr das Gerät wechselt, es zurücksetzt oder einfach nur eine zusätzliche Sicherheitskopie möchtet.

Was sichert das Backup

Das Backup sichert die kompletten Systemeinstellungen, Apps, Konten, WLAN und deren Passwörter, eure lokalen Kalender und Kontakte. Einstellungen der Apps können auch wiederhergestellt werden, solange es die Apps zulassen. Später dazu mehr.

Vorbereitungen

Ihr benötigt einen USB Stick, entweder mit einem USB-C Anschluss oder einen normalen USB Stick mit dem mitgeliefertem USB to USB-C Adapter. Ausserdem sollte der USB Stick eine mindestgrösse von 16 bis 32GB haben, je nachdem wie viel Apps ihr installiert habt. Hängt den Stick an eurer Smartphone mit CalyxOS oder GrapheneOS

USB-Stick formatieren:
Das System erkennt den USB Stick, damit dieser nutzbar wird, muss er durch den systemeigenen Dienst zuerst formatiert werden. Stellt sicher, dass auf dem Stick keine sensiblen oder wichtigen Daten sind, da diese durch die Formatierung gelöscht werden.

Klickt einfach Problem mit USB Gerät, und danach startet auch schon der Formatierungsassistent.

SeedVault aktivieren
SeedVault ist auf CalyxOS und GrapheneOS vorinstalliert. Aktiviert SeedVault über die Geräteeinstellungen:

• CalyxOS: Einstellungen > System > Sicherungen
• GrapheneOS: Einstellungen > System > Sicherungen

Jetzt müsst ihr euch die 12 Wörter aufschreiben, welche euch Seedvault präsentiert, und diese danach bestätigen. Stellt sicher dass ihr die 12 Wörter nicht verliert, ohne sie, könnt ihr das Backup nie wieder verwenden! Danach wählt ihr den USB Stick als Sicherungsort aus. Das wäre das USB Symbol mit dem Namen Android.

Backup einrichten und erstellen

Die Einrichtung von Seedvault ist einfach, hier eine kurze Erklärung zu den Einstellungen:

Meine Apps sichern

Sichert eure Apps auf dem Smartphone. Achtung! Viele Apps lassen sich selber aufgrund Einschränkungen der Progammierer nicht sichern. Klickt auf Sicherungsstatus und wählt aus, welche Apps ihr sichern wollt. Ganz unten findet ihr die Apps die sich nicht sichern lassen. Dass ist leider Sache der Entwickler, ob sie ihre Apps zur Sicherung zulassen oder nicht. Die meissten Open Source Apps lassen sich aber ohne Probleme sichern.

Unten könnt ihr weitere Einstellungen vornehmen, zum Beispiel die automatische Wiederherstellung der Einstellungen, und die Einstellung, dass die App inklusive ihrer kompletten Einstellungen gesichert werden kann.

Meine Dateien sichern

Achtung: diese Funktion ist noch experimentell. Seedvault verspricht nicht ein 100prozentiges Backup eurer persönlichen Daten und Dokumente. Schiebt solche Sachen lieber direkt über ein USB Kabel direkt auf euren PC oder Laptop. Probieren kostet nichts, habt ihr sowieso alles gesichert, könnt ihr die Funktion gerne ausprobieren.

Sicherung Starten

Habt ihr alles eingestellt, könnt ihr jetzt oben rechts auf die 3 Punkte, und "Jetzt Sichern" auswählen. Seedvault sichert jetzt eurer Smartphone auf euren Nextcloud Server über den WebDAV Zugang. Die Daten liegen verschlüsselt und unlesbar auf eurem Nextcloud Server.

Sicherungsstatus überprüfen

Klickt auf Sicherungsstatus, und schaut, welche Apps sich sichern lassen haben, und welche nicht

Smartphone wiederherstellen

Ihr könnt euer Phones im laufenden Betrieb von einem Backup wiederherstellen, oder eben direkt bei der Neueinrichtung des Smartphones. Schauen wir uns beide Methoden an:

Restore auf laufendem Gerät

Geht einfach auf Seedvault, und klickt oben rechts auf die 3 Punkte. Wählt hier Sicherung wiederherstellen aus, und wählt das Backup, aus dem ihr wiederherstellen möchten

Restore auf neues Gerät

Der Einrichtungsassistent wird wie üblich durchgemacht, bis zum Punkt Restore app & data. Hier wählt hier nun Restore aus. Auf dem nächsten Bildschirm wählt ihr nun den USB Stick aus, den ihr natürlich jetzt anschliessen müsst.

Jetzt müsst ihr im nächsten Bildschirm die 12 Wörter eingeben, die ihr euch aufgeschrieben hattet.

Zuerst werden die Apps neu installiert, danach wird das Sytem wieder eingerichtet und falls möglich Apps wieder so eingerichtet, wie sie vorher waren. Welche Apps nicht wieder eingerichtet werden konnten, bekommt ihr anschliessend zu sehen.

Anschliessend wählt ihr Reuse Backup damit das Backup auch notfalls auf dem alten Phone wiederverwenden könnt. Habt ihr die Option Meine Daten sichern aktiviert, kommt jetzt noch die Wiederherstellung der Daten. Habt ihr eure Daten nicht gesichert, könnt ihr unten Wiederherstellen von Daten überspringen auswählen.

Ist die Wiederherstellung durch, geht der Einrichtungassistent weiter, und ihr findet euch auf eurem Phone wieder, wie ihr es von vorher kanntet.

Fehlerbehebung

• USB-Stick wird nicht erkannt:
  • Stellt Sie sicher, dass der Stick im richtigen Dateisystem formatiert ist. Entweder automatisch über den Android Assistenten, oder manuell: der Stick muss in ISO9660 formatiert werden.
  • Verwendet einen den mitgelieferten USB-C-Adapter.
• Wiederherstellung schlägt fehl:
  • Überprüft, ob die richtige Passphrase eingegeben wurde.
  • Prüft die Backup-Daten auf Beschädigungen. Nehmt einen anderen Stick, und macht ein neues Backup vom alten Phone. Häufig genutzt Sticks können altern, und Fehler produzieren

Dieses Vorgehen stellt sicher, dass eure Daten sicher gesichert und wiederhergestellt werden können, ohne die Kompatibilität der Systeme zu gefährden.

Fazit

Die Nutzung von Custom ROMs wie CalyxOS und GrapheneOS bietet euch ein hohes Maß an Datenschutz und Kontrolle. Doch dieser Gewinn an Sicherheit bringt auch Verantwortung mit sich: Ihr müsst euch aktiv um die Sicherung eurer Daten kümmern. Im Gegensatz zu herkömmlichen Betriebssystemen fehlen auf Custom ROMs die von Herstellern bereitgestellten Cloud-Backups und automatisierten Sicherungslösungen.

Mit SeedVault habt ihr jedoch ein leistungsstarkes Werkzeug zur Verfügung, um eure Daten lokal zu sichern und bei Bedarf wiederherzustellen. Indem ihr einen USB-Stick als Speicherziel verwendet, behaltet ihr die vollständige Kontrolle über eure Backups und schützt eure sensiblen Daten vor dem Zugriff durch Dritte.

Um Datenverluste zu vermeiden, ist es wichtig, eine zuverlässige Backup-Strategie zu entwickeln. Führt regelmäßig Backups durch, bewahrt eure Wiederherstellungs-Passphrase sicher auf und prüft hin und wieder, ob eure Backups intakt sind. Denn ohne Backup sind eure Daten im Falle eines Geräteausfalls oder Resets unwiederbringlich verloren.

Mit einer guten Backup-Strategie könnt ihr den Komfort und die Sicherheit von Custom ROMs genießen, ohne Kompromisse bei der Datensicherheit einzugehen. Eure Daten, eure Verantwortung – sorgt dafür, dass ihr jederzeit die Kontrolle behaltet.

Schaut hier vorbei, wie das ganze über eine eigene Cloud Lösung aussehen kann.

The post Android CustomROM lokal sichern und wiederherstellen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist nochmals ein SCB Backup

Ein SCB oder auch Static Channel Backup genannt, ist ein Backup eurer Kanaldaten, sie ist quasi die Lebensversicherung falls alles schief geht. Mit der SCB Datei namens channel.backup, könnt ihr bei einem Totalausfall der Node, all eure Kanäle wieder herstellen. Dafür benötigt ihr nur eure Seedphrase, und die SCB Datei selber, nichts weiter. Jedoch ist das Wort Backup in der Beschreibung Static Channel Backup etwas unglücklich gewählt, da sich die Kanäle nicht vollständig wiederherstellen lassen. Die Datei enthält nur die allernötigsten Information, wie die Pubkeys des Peers, die Kanalgrösse und das Eröffnungsdatum. Eine triggern eines SCB Recoveries, bedeutet dass die Kanaldaten geladen werden, und die Peers, mit denen ihr verbunden wart, erhalten ein Signal, dass ihr einen Ausfall hattet, mit den Informationen des Peers, wird der Kanal anschliessend zwangsgeschlossen, und ihr erhaltet eure Funds zurück.

Vorteile einer doppelten Sicherung

Im Backup und Restore Leitfaden habt ihr bereits erfahren, wie ihr die SCB Datei auf einen USB-Stick lokal sichern könnt. Das ist schonmal gut, da bei einem Festplattenausfall das Backup sicher ist. Leider schützt dies jedoch nicht für Einflüssen wie Bränden, Diebstahl oder wenn der Hund die ganze Node gefressen hat. Eine externe Sicherung schafft hier eine zusätzliche Schicht der Sicherheit.

Das Backup in der Nextcloud

Der Raspiblitz bietet eine Funktion, die euch die SCB Datei zusätzlich in einer Nextcloud eurer Wahl sichern lässt. Ihr müsst keine Angst haben, dass mit der SCB Unfug angestellt werden kann, da der Inhalt der Datei mit eurer Seedphrase verschlüsselt ist. Die Datei kann also nur, in Kombination mit eurer Seedphrase entschlüsselt werden. Deshalb sind SCB Dateien in einer Cloud kein Problem. Viele Lightning Wallets, sichern die SCB Datei auf den Servern der Betreiber, damit die Kanäle im Worst-Case Szenario wieder hergestellt werden können. Die Phoenix Wallet, tut dies zum Beispiel auch.

Den Backup Job der Nextcloud erstellen

Ihr benötigt einen Nextcloud Provider eurer Wahl. Wir stellen unseren Lesern 5GB Gratis Nextcloud Speicher zur Verfügung, ihr könnt also auch gern unsere Dienstleistung dafür verwenden. Registriert euch auf unserer Webseite, und erhaltet in eurem Konto Zugriff zur Nextcloud. Die Logindaten sind die Daten, die ihr zur Registrierung bei uns verwendet habt.

Stellt eine SSH Verbindung zur eurem Raspiblitz her. Öffnet das Konsolenmenu mit menu und geht in die SETTINGS:

Steuert auf SCB/Emergency Backup on Nextcloud, und markiert das Tool mit der Leertaste, und geht danach unten auf OK:

Anschliessend öffnet sich ein weiteres Fenster. Gebt die URL eurer Nextcloud Instanz ein, auf dem die SCB Datei gesichert werden soll:

https://cloud.yourdevice.ch wäre die URL unserer Nextcloud-Instanz. Bestätigt mit OK. Anschliessend werdet ihr in 2 weiteren Fenstern nach dem Username, und dem Passwort gefragt, gebt beide Daten ein, und bestätigt mit OK. Nach der Passworteingabe bekommt ihr ein Output, ob das Backup geklappt hat:

Ihr seht, dass die channel.backup erfolgreich hochgeladen worden ist.

Überprüfen des Backups auf eurer Nextcloud

Loggt euch auf eure Nextcloud Instanz ein, und geht in den Dateienexplorer in dem ihr auf der Arbeitsleiste oben auf Dateien geht. Ein neuer Ordner mit dem Namen rapsi wurde erstellt. Darin befindet sich die channel.backup:

Eure channel.backup befindet sich nun auf eurer gewählten Nextcloud Instanz. Die Datei bleibt wenige Kilobyte gross, und wächst auch nicht sonderlich an, wenn ihr immer die ungefähr gleiche Anzahl an Kanälen habt. Schliesst ihr einen Kanal, oder eröffnet ihr einen neuen, läd der Raspberry die Datei direkt wieder in die Nextcloud ohne euer zutun.

Fazit

Mit dem SCB Backup via Nextcloud fügt ihr eine zusätzliche Schicht an Sicherheit für eure Node hinzu. Das Remote Backup stellt eine sinnvolle Ergänzung zur lokalen Sicherung zuhause da. Wie sagt man so schön? Doppelt genäht, halt besser!

Schaut gerne hier vorbei, für den kompletten Backup & Restore Leitfaden für Fullnodes:

Schaut gerne für weitere Informationen in den offiziellen Raspiblitz-Docs vorbei.

The post Raspiblitz SCB Backup auf einer Nextcloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Betreiber mit einer Lightning Node kommen ab einer bestimmten Anzahl an Kanälen zwangsläufig zur Frage, wie man sich am besten , beziehungsweise die Node und die Kanäle darauf, bestmöglichst absichert, und die Kanäle nach einem Ausfall wieder herstellen kann. Das Thema ist etwas komplex, aber wir schauen uns heute an, wie wir eine Lightning Node am besten absichern können, und wie wir Kanäle bei einem Totalausfall wiederherstellen können. Hier gibt es nämlich ein paar Dinge, die sehr wichtig sind, und auch ein Paar Dinge, die man auf keinen Fall machen darf, wie ich es selber schmerzlichst lernen musste. Damit euch keine Fehler passieren, besprechen wir in diesem Artikel die wichtigsten Schritte.

Wir schauen uns die besten Strategie für die Systeme Raspiblitz, Umbrel und BTCPay Docker an. Ziel ist es eine möglichst sichere Umgebung für unsere Fullnode herzustellen, um in Falle eines Platten- oder Systemausfalls schnell wieder Online zu sein und gegebenfalls alle Kanäle wiederherzustellen. Wichtig zu verstehen ist, das aktuell noch keine reinen Datenbackups aktuell nicht möglich sind. Ihr könnt also nicht eure komplette Platte klonen oder backupen, und einen Server wieder herstellen falls es zu einem Ausfall kommt.

Hintergründe und wichtiges zuerst bei Single Disk Deployments

Es gibt einige Verwirrung und Mythen darüber, wie man Off Chain Funds der eigenen Nodes am besten sichert. Ein Fehler hierbei stellt immer noch das größte Risiko dar, diese Gelder zu verlieren, obwohl alles getan wird, um diese Risiken zu minimieren. Es gibt nur ein Szenario, bei dem man das Guthaben sichert, und auf einer neuen Node wieder komplett wieder herstellen kann, inklusive allen Kanälen, und zwar dann, wenn der Server noch nicht abgeschmiert ist. In den meissten Fälle ist es aber eher umgekehrt: Der Server beziehungsweise die Node ist tot, und ihr steht da wie vom Blitz getroffen.

Welche Daten dürfen in regelmässigen backups gesichert werden

Die wichtigste Datei, die immer gesichert werden muss, ist die Datei <lnddir>/data/chain/bitcoin/mainnet/channel.backup. Diese Datei enthält die Statischen Kanal-Backups (SCBs). Sie wird nur aktualisiert, wenn die Node gestartet wird und wenn ein Kanal geöffnet oder geschlossen wird. Alle anderen Dateien auf der Node sind mehr oder weniger egal.

Die meisten Lightning-Wallet-Apps wie die WalletofSatoshi oder Phoenix laden diese Datei automatisch in die Cloud hoch.

Wie wir diese Datei sichern, und bei einem Ausfall der Node verwenden, um unsere Kanäle wiederherzustellen, schaue wir uns weiter unten dann genau an.

Welche Dateien sollte man nicht in regelmässigen Backups sichern

Das ist eine etwas trickreiche Frage, denn das Anfertigen des Backups ist nicht das Problem. Das Wiederherstellen/Verwenden einer alten Version der channel.db zu finden unter <lnddir>/data/graph/mainnet/ ist sehr riskant und sollte niemals gemacht werden!

Das erfordert etwas Erklärung:

Die Art und Weise, wie LN-Kanäle derzeit eingerichtet sind (bis eltoo/SQL) implementiert wird), ist, dass beide Parteien immer einem aktuellen Saldo zustimmen. Um sicherzustellen, dass keiner der beiden Peers in einem Kanal jemals versucht, einen alten Zustand dieses Saldos zu veröffentlichen, geben sie beide ihre Schlüssel an den anderen Peer weiter. Dies gibt ihm die Möglichkeit, alle Gelder (nicht nur ihren vereinbarten Anteil) aus einem Kanal zu nehmen, wenn ein falscher oder veralteter des Channelstates veröffentlicht wird. Daher bedeutet das Vorhandensein eines alten Kanalzustands im Grunde, dass man den Saldo an die andere Partei verlieren kann.

Da Zahlungen in LND mehrmals pro Sekunde getätigt werden können, ist es sehr schwierig, jedes Mal ein Backup der Kanaldatenbank zu machen, wenn sie aktualisiert wird. Und selbst wenn es technisch möglich ist, kann das Vertrauen, dass ein bestimmter Zustand sicher der aktuellste ist, nie absolut sein. Deshalb sollte der Fokus darauf liegen, sicherzustellen, dass die Kanaldatenbank (also die channel.db) nicht beschädigt wird, die Zombie-Kanäle zu schließen und die SCBs sicher aufzubewahren.

Ausnahmefall noch laufende Node

Kommen wir zur Ausnahme, wann eine Node doch von einem kompletten Backup wiederhergestellt werden darf: Im Ausnahmefall, und nur wirklich in diesem speziellen Fall darf man den kompletten /.lnd Ordner (in der sich die channel.db befindet) sichern, und zwar genau dann, wenn die Node noch nicht den Geist aufgegeben hat. Das komplett Backup darf also nur erzeugt werden, wenn die Node direkt nachher offline genommen wird. Raspiblitz bietet dazu die Funktion LNDRESCUE, oder die komplette Migration an. Die Scripte erstellen Backups welche beim aufsetzen einer neuen Node später verwendet werden, um alle Guthaben inklusive aller Kanäle, wieder herzustellen.

LNDRESCUE sichert nur die Lightning Node, während das Migrationsbackup vom Rapspiblitz beispielsweise eure komplette Node sichert, inklusive installierter Anwendungen und Einstellungen der Node.

Die Node wird direkt nach dem erstellen des Backups vom System selber offline genommen und heruntergefahren. BTCPay bietet ein ähnliche funktion, Umbrels OS bietet dagegen keine vollständige Sicherung von LND an. Bereitet euch also immer auf euer jeweiliges System gut vor!

Die mit Abstand beste Sicherung eurer Node

Die einfachste Methode, eure Lightning Node, beziehungsweise eure Kanäle zu sichern, ist ein einfaches RAID1 Setup. Damit sichert ihr euch gegen ein Plattenausfall ab, und könnt bei einem Plattenausfall die Node ganz normal weiterlaufen lassen, bis ihr einen Ersatz für die ausgefallene Platte habt. Das bietet sich aber leider nicht auf dem Pi4 an, da das Netzteil zu schwach ist, 2 SSDs über das Standard Netzteil zu betreiben. Habt ihr Umbrel, den RaspiBlitz oder BTCPay Docker aber auf einem Linux Server System auf dem ein Hypervisor wie Proxmox läuft, empfiehlt es sich hier unbedingt eine zweite Platte zu nutzen. Dabei empfiehlt es sich, das komplette Betriebssystem ebenfalls auf dem RAID Verbund zu haben, damit das System auch gesichert wird.

Ist es bei einem Single Disk Setup zu einem Crash eurer Node gekommen, schauen wir uns jetzt die wichtigsten Methoden an, um unsere Onchain sowie auch Kanalguthaben, falls vorhanden, wiederherzustellen. Fangen wir doch gleich mit dem Ausnahmefällen an, und zwar dann, wenn die Node noch nicht gecrasht ist.

Wiederherstellung aus Backups

Raspiblitz Backup & Restore mit LNDRESCUE

Der Raspiblitz kommt mit einer äusserst nützlichen komplett Backup & Restore namens LNDRESCUE. Dabei wird eine komplette Sicherung des kompletten .lnd Ordners durchgeführt. Heisst also, ihr könnt diese Funktion nutzen, wenn die Node noch nicht komplett abgestürzt ist, eure Festplatte bald voll ist, oder andere Dinge passiert sind die eine Neuinstallation bzw. ein Transfer voraussetzen. LNDRESCUE fährt auch eure Node nach dem Backup automatisch herunter nachdem ihr das Backup heruntergeladen habt. Dabei kann beinahe fast nichts schiefgehen

Wichtig ist, dass möglichst zur selben Raspi Version migriert wird, und es keine grossen Versionsunterschiede zwischen dem alten, und dem neuen gibt. Falls auf dem alten System noch eine 1.90 läuft, und ihr das neuste Image flasht, wie zum Beispiel 1.11, dann stehlt sicher, dass die alte Node vorher auch noch geupdated wird!

Backup Starten

Geht in das CLI Menü des Raspiblitzes mit menu und geht in die Repair Options, danach Backup / Repair LND und wählt danach Backup your LND data (Rescue-File) aus:

Der Raspi startet danach eine umfassende Sicherung der Lightning Node und stellt euch am Schluss einen Befehl zur Verfügung, der euch die Datei von einem Windows- oder Linux Rechner herunterladen lässt. Autocompact Channels könnt ihr aktivieren, um die Grösse etwas zu reduzieren. Danach ladet ihr euch mit den entsprechenden Links die Backups herunter:

Ladet die Datei herunter, bestätigt danach mit Enter, da die Node anschliessend heruntergefahren wird.

LNDRescue Backup Wiederherstellen

Nachdem ihr eine frisch installierte Node habt, könnt ihr nun die alte Node mit LNDRESCUE komplett wiederherstellen. Heisst auch den LND Seed, die Kanäle und eure komplette Transaktionshystorie. Damit ihr schnellstmöglich wieder online seid, empfielt es sich wie bereits erwähnt die Blockchain vom alten Pi zu übernehmen.

Startet den Pi mit einem frischen Image auf einem synchnronisertem, oder nicht synchronisiertem Hardwaresetup. Die LNDRESCUE Datei habt ihr optimalerweise bereits auf einem USB Stick gespeichert. Diesen benötigen wir für den LNDRESCUE Restore:

Wählt hier Restore from a rescue file aus. Im nächsten Fenster könnt ihr das Backup eurer frischen Raspiblitz Installation getrost überspringen. Folgt den Anweisungen der Konsole, und gebt den Pfad zu eurem LNDRESCUE Backup an. Das Backup wird eingespielt, die Node anschliessend neugestartet. Ihr könnt, falls ihr bereits synchronisiert seid, danach direkt eure Kanäle wieder verwenden. Habt ihr keine Kopie der Blockchain, dann müsst ihr warten, bis sich der neue Blitz synchronisiert hat, danach gehen die Kanäle wieder online.

Seid ihr zu lange offline, da ihr kein Blockchain Backup habt, kann es sein dass Kanäle aufgrund von pending htlc's geschlossen werden. Es empfiehlt sich also in diesem Fall den Raspiblitz übers Clearnet zu synchronisieren.

Raspiblitz komplete Migration auf ein neues Gerät

Wie bereits erwähnt, haben wir dazu ein eigenes Tutorial geschrieben. Dies könnt ihr nutzen, falls eure Node noch funktioniert, und ihr sie auf ein komplett neues Gerät übertragen wollt:

BTCPay Server Backup & Restore Funktion benutzen

Der BTCPay Server in der eigenständigen Docker Variante kommt mit einen eigenen Backup and Restore Script welches ihr im Home Verzeichnis von vom BTCPay Server also unter btcpayserver-docker/btcpay-backup.sh findet. Wollte ihr eure Blockchain Daten sichern, müsst ihr das separate tun z.B rsync oder direkt auf eine Sicherungsplatte.

Skript Sicherung durchführen

Loggt euch als root user ein gebt folgendenden Befehl ein:

cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
./btcpay-backup.sh

Das Skript wird folgende Schritte durchführen:

1. Sicherstellen, dass der Datenbank-Container läuft.
2. Ein Backup (Dump) der Datenbank erstellen.
3. Den BTCPay Server stoppen.
4. Die Docker-Volumes und das Datenbank-Backup archivieren.
5. Die Blockchain-Blöcke und Chainstate-Verzeichnisse ausschließen.
6. Optional: Das Archiv verschlüsseln.
7. Den BTCPay Server neu starten.
8. Aufräumen: Temporäre Dateien wie das Datenbank-Backup entfernen.

Falls alles klappt, seht Ihr folgendes: ✅ Backup done => /var/lib/docker/volumes/backup_datadir/_data/backup.tar.gz

Die Datei backup.tar.gz könnt ihr auf einem USB Stick oder auf einem anderen Medium speichern um später wieder herzustellen falls der Server die komische Anzeichen macht oder ihr auch beispielsweise einfach das System migrieren möchtet. Ihr könnt auch das Backup mit rsync z.B auf ein anderes Netzwerkgerät syncen und sichern. Fahrt den Server nach Sicherung der Datei auf ein Medium, oder auf einen Netzwerkspeicher herunter.

Skript Wiederherstellung

Ähnlich zum Skript btcpay-backup.sh aber umgekehrt: der btcpay-restore.sh Skript muss mit der Pfadangabe ausgeführt werden. also z.B

./btcpay-restore.sh /mnt/usb/backup.tar.gz

Bei einem erfolgreichem Restore bekommt Ihr: ✅ Restore done

Bedenkt dabei, dass bei einem Restore die Kanäle ebenfalls wiederhergestellt werden, und deshalb der Server direkt nach dem erstellen des Backups unbedingt heruntergefahren werden muss!

On Chain Guthaben wiederherstellen

Dies ist der einfachste und unproblematischste Schritt auf allen 3 System. Um eure Onchain-Guthaben zu sichern, braucht ihr nur den Seed bzw. die 24 Wörter für eure Bitcoin-Core Wallet oder eure Lightning On-Chain Wallet. Sollte ein System ausfallen, müsst ihr nichts anderes tun, als die Seedphrase eingeben und ihr habt eurer Guthaben zurück. Das betrifft nochmals gesagt, nur Guthaben, die nicht in Lightning Kanälen sind!

Umbrel Node

Beim Aufsetzen einer neuen Node kann beim ersten Zugriff auf die Lightning Node eine neue Wallet erstellt werden, oder eine Wallet aus einer Seedphrase wiederhergestellt werden. Um euer Onchain Guthaben wieder herzustellen, müsst ihr eure Seedphrase eingeben, die ihr beim erstellen eurer Lightning Wallet erstmalig aufgeschrieben habt.

Wählt also RECOVER YOUR PREVIOUS NODE aus, und gebt danach eure 24 Wörter ein. Damit habt ihr die Onchain Funds eurer Node wiederhergestellt. Hattet ihr vorher diverse Lightningkanäle, springt zur Umbrel Kanal Wiederherstellung um die Kanäle wieder her zu stellen.

BTCPay Server Docker

BTCPay Docker verfügt über mehrere Wallets, eine Shop Wallet, welches eine reine Onchain Wallet ist, und die Lightning Wallet auf der Lightning Node. Beide müssen separate wiederhergestellt werden.

Die Bitcoin Shop Wallet wiederherstellen

Um die Bitcoinn Shop Wallet wiederherzustellen, klickt einfach auf den Bitcoin Button links in der Menüspalte und klickt danach auf connect an exisiting Wallet

Auf der nächsten Seite habt Ihr die Möglichkeit, die Art der Wiederherstellung auszuwählen:

Habt ihr keine Wallet File, müsst ihr eure Wallet Adresse manuell eingeben. Macht das am besten auf einem frischen System bei dem ihr wisst, dass ihr womöglich keine bösartige Software oder Viren drauf habt. Ihr könnt die Guthaben natürlich auch auf einer Software Wallet wie Sparrow wiederherstellen. Diese könnt ihr dann auf ein frisch erstellte Wallet auf dem BTCPay Server senden.

LND Wallet von BTCPay Docker wiederherstellen

Die oben vorgestellte Backup Methode vom BTCPay Server stellt auch eure LND Wallet wieder her, solltet ihr also ein Backup erstellt haben, könnt ihr damit eure Wallet wiederherstellen. Falls ihr kein Backup habt, und nur eure 24 Wörter für die LND Wallet, folgt dem folgendem Leitfaden:

Das Wiederherstellen der Lightning Wallet beim reinem BTC-Pay Server ist etwas umständlich. Die Wiederherstellung der LND Wallet geschieht auf der Kommandozeile.

Der anfängliche Ausgangspunkt, um die Wiederherstellung von On-Chain-Geldern über die Kommandozeile auszulösen, ist der Befehl lncli create. Dieser funktioniert auf dem BTCPay Server etwas anders. Zuerst müsst ihr den Stack komplett herunterfahren indem ihr auf der Kommandozeile folgenden Befehl ausführt:

btcpay-down.sh

Danach müsst ihr den Unlockscript von BTCPay kurz deaktivieren, indem ihr folgendermassen vorgeht:

Sucht zuerst den docker-initunlocklnd.sh Script mit dem folgendem Befehl:

find /var/lib/docker/overlay2/ -name "docker-initunlocklnd.sh" 2>/dev/null

Kopiert euch dem Pfad der den Ordner merged beeinhaltet:

Ändert den namen des docker-initunlocklnd.sh Scripts kurzfristig ab:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak

Löscht den kompletten Inhalt des LND Ordners auf dem BTCPay Server:

rm -r /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/*

Startet den BTCPay Server mit:

btcpay-up.sh

Führt den folgenden Befehl aus:

docker exec -it btcpayserver_lnd_bitcoin lncli --tlscertpath /root/.lnd/tls.cert.tmp create

Jetzt kommt ihr in den interaktiven Modus um die Wallet wiederherzustellen. Als Nächstes kann man ein neues Wallet-Passwort eingeben, um alle neu abgeleiteten Schlüssel als Ergebnis des Wiederherstellungsprozesses zu verschlüsseln. Diesen Schritt könnt ihr mit Enter überspringen.

Input wallet password:
Confirm wallet password:

ACHTUNG, das Walletpasswort auf dem BTCPAY Server muss hellorockstar sein! Verwendet hier also hellorockstar als Wallet Passwort!

Sobald ein neues Wallet-Passwort erstellt wurde, werdet ihr aufgefordert, die vorhandenen Chiffrierschlüssel (Cipher Seed) einzugeben:

Input your 24-word mnemonic separated by spaces: ability noise lift document certain month shoot perfect matrix mango excess turkey river pitch fluid rack drill text buddy pool soul fatal ship jelly

Wenn beim Erstellen des Seeds ein Passwort für den Chiffrierschlüssel verwendet wurde, MUSS es jetzt eingegeben werden, das ist auf dem BTCPAY Server beim Standardsetup aber nicht der Fall, also ENTER:

Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase):

Schließlich habt ihr die Möglichkeit, ein Wiederherstellungsfenster zu wählen:

Input an optional address look-ahead used to scan for used keys (default 2500):2500

Das Wiederherstellungsfenster ist ein Maß, das der On-Chain-Scanner verwendet, um zu bestimmen, wann alle "benutzten" Adressen gefunden wurden. Wenn das Wiederherstellungsfenster zu niedrig ist, wird LND keine Gelder in Adressen finden, die nach dem Punkt erzeugt wurden, an dem zwei aufeinanderfolgende Adressen generiert, aber nie verwendet wurden. Wurde eine LND On-Chain-Wallet umfangreich genutzt, möchtet ihr möglicherweise den Standardwert erhöhen.

Sollten alle bereitgestellten Informationen gültig sein, wird euch der Seed erneut präsentiert:

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

---------------BEGIN LND CIPHER SEED---------------
 1. ability   2. noise   3. lift     4. document
 5. certain   6. month   7. shoot    8. perfect
 9. matrix   10. mango  11. excess  12. turkey
13. river    14. pitch  15. fluid   16. rack
17. drill    18. text   19. buddy   20. pool
21. soul     22. fatal  23. ship    24. jelly
---------------END LND CIPHER SEED-----------------

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

lnd successfully initialized!

Ist die Wiederherstellung durch, muss der docker-initunlocklnd.sh Script wieder unbenannt werden:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh

Startet den BTCPay Server neu mit:

btcpay-restart.sh

Danach habt ihr eure Onchain Funds der LND Wallet erfolgreich auf dem BTCPay Server wiederhergestellt. Wie hier die Kanäle wiederherstellt erfahrt ihr weiter unten.

Raspiblitz Fullnode

Der Raspiblitz hat nur eine LND Wallet mit Onchain Funds. Deshalb gehts gleich weiter, wie die LND Wallet wieder hergestellt werden kann. Vorausetzung dafür ist ein frisch installiertes Blitzimage, und ein synchronisierter Bitcoincore Client. Die Node muss also vollständig synchronisiert sein, damit die Funds wieder auftauchen.

LND Onchain Wallet wiederherstellen

Achtung: diese Option ist nur auszuwählen, falls ihr keine Kanäle hattet! Weiter unten findet ihr die Anleitung um Kanäle wiederherzustellen. Das Raspiblitzmenu bietet im Menu eine extra Option an, um nur die Onchain Funds der LND Wallet wiederherzustellen. Loggt euch per SSH auf dem wiederhergestellten RaspiBlitz ein und begebt euch mit dem Befehl menu ins CLI Menü des Blitzes, dort wählt ihr dann Repair Options und danach Repair/Backup LND:

Im nächsten Fenster wählt Ihr dann Restore from a seed (onchain funds only)

Im nächsten Fenster fragt euch der Blitz ob ihr LND vorher sichern wollt, da ihr neu aufgesetzt habt, müsst ihr nichts sichern, könnt also einfach mit <skip> fortfahren. Anschliessend startet der Blitz die entsprechende Konfiguration. Ihr könnt dann in den folgenden Schritten euren alten LND Azeed eingeben. Folgt einfach den Anweisungen.

Offchain Guthaben oder Lightning Kanäle sichern

Wir kommen nun zu dem Teil des Tutorials, der euch zeigt, wie ihr eure Kanäle mit der wichtigen, euch nun bereits bekannten SCB Datei channel.backup, sichert.

Die SCB-Datei in LND (Lightning Network Daemon) steht für "Static Channel Backup". Sie ist quasi die Lebensversicherung bei einem Totalausfall des Lightning Knotens. Die grösste Konzentration liegt darauf, dass diese Datei unter allen Umständen regelmässig gesichert werden muss.

Hier wichtige Details zur SCB-Datei:

1. Zweck der SCB-Datei: Die SCB-Datei ist dazu gedacht, Informationen über eure Lightning-Kanäle zu speichern, allerdings in einer statischen Form. Das bedeutet, sie speichert die grundlegenden Infos zu den Kanälen, wie die Kanal-IDs und die Knoten, mit denen ihr verbunden seid.
2. Nutzung im Notfall: Die Hauptfunktion der SCB-Datei ist die Wiederherstellung eurer Kanäle im Falle eines Totalausfalls eures Knotens, wie z.B. bei einem Hardwarefehler oder Datenverlust. Wenn ihr also einen neue LND Node aufsetzt, könnt ihr die SCB-Datei verwenden, um eure Kanäle wiederherzustellen.
3. Limitationen: Es ist wichtig zu verstehen, dass die SCB-Datei nicht dazu dient, Kanäle "am Leben zu erhalten" oder den aktuellen Zustand eurer Kanäle zu sichern. Sie hilft nur bei der Wiederherstellung der Existenz der Kanäle, nicht aber bei der Wiederherstellung des Kanalzustandes oder der Transaktionshistorie. Nach der Verwendung der SCB Datei, werden also alle ehemaligen Kanäle zwangsgeschlossen, und ihr bekommt eure Lightning Guthaben nach eineriger Zeit zurück. Das heißt, sie ist eine Art Sicherheitsnetz, aber keine umfassende Backup-Lösung.
4. Vorsichtsmaßnahmen: Es ist entscheidend, dass ihr die SCB-Datei sicher und getrennt von eurem Knoten aufbewahrt. Sollte jemand unbefugt Zugriff darauf erhalten, könnte dies ein Sicherheitsrisiko darstellen. Zusammen mit dem Seed kann eurer gesammtes Lightning Guthaben abgegriffen werden.

Zusammenfassend ist die SCB-Datei in LND also das wichtigste Werkzeug für die Notfallwiederherstellung eurer Lightning-Kanäle bei einem Ausfall eurer Node. Sie ist jedoch kein Allheilmittel und kann nicht den laufenden Betrieb oder den aktuellen Zustand Eurer Kanäle sichern. Es ist also wichtig, zusätzlich zu den SCB-Backups auch andere Vorsichtsmaßnahmen zu treffen, um die Sicherheit eurer Lightning-Kanäle zu gewährleisten.

Umbrel SCB Datei sichern

die SCB Datei findet ihr auf der Umbrel Lightning Node oben rechts unter den 3 Strichen:

Die Datei könnt ihr direkt downloaden und an einem Ort eurer Wahl speichern. Eine Automatische Sicherung gibt es nicht, wie die Einstellung Automatic backups suggeriert! Zumindest finde ich nirgends eine Option aus einem Online Backup von Umbrel wiederherzustellen.

BTCPay Server Docker SCB Datei sichern

Auf dem BTCPay Server gibt es keine automatische SCB Backup Funktion, deshab machen wir uns einen eigenen Script, der die channel.backup regelmässig bei Änderungen sichert, ähnlich bzw gleich der SCB Backup Funktion des Blitzes.

LND backup script für die channel.backup mit inotify

Installiert euch zuerst das Tool inotify auf dem Host.

sudo apt install inotify-tools

Skript erstellen

Erstellt einen Script der die channel.backup Datei überwacht mit nano /pfad/copy-channel-backup-on-change.sh mit folgendem Inhalt:

#!/bin/bash

# Pfade und Einstellungen
SOURCE_FILE="/var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup"
BACKUP_PATH="/backuppfad/channel.backup"
DELAY=10  # Verzögerung in Sekunden nach Erkennung von Änderungen

while true; do
    # Warte auf eine Änderung (modify) an der Datei
    inotifywait -e modify $SOURCE_FILE
    
    # Warte nach der Erkennung einer Änderung
    echo "$(date): Modification detected. Waiting for $DELAY seconds before copying..."
    sleep $DELAY

    # Kopiere die Datei zum Backup-Pfad
    cp $SOURCE_FILE $BACKUP_PATH

    echo "$(date): File copied to $BACKUP_PATH"
done

Bitte passt den BACKUP_PATH an einen enstsprechenden Pfad an (z.B an einen gemounteten USB Stick oder einen Netzwerkspeicher)

Macht die Datei ausführbar mit:

chmod +x /pfad/copy-channel-backup-on-change.sh

als Service hinzufügen

Erstellt eine neue Service Datei mit sudo nano /etc/systemd/system/backup-channels.service mit folgenden Inhalt:

[Service] 
ExecStart=/pfad/copy-channel-backup-on-change.sh 
Restart=always 
RestartSec=1 
StandardOutput=syslog 
StandardError=syslog 
SyslogIdentifier=backup-channels 
User=ubuntu 
Group=ubuntu 
[Install] 
WantedBy=multi-user.target

Den Dienst startet ihr mit:

sudo systemctl start backup-channels

Überwachen könnt ihr in mit:

journalctl -fu backup-channels

Beim booten des Servers den Service automatisch mit starten:

sudo systemctl enable backup-channels

rsync backup mit crontab

Eine einfache Variante ist auch das sichern dern SCB Datei mit einem einfach rsync cronjob. Dafür braucht ihr keine Scripte und keinen extra Service, ist aber nicht ganz so sauber wie die inotify methode.

Erstellt einen crontab mit sudo crontab -e mit folgendem Inhalt:

15 * * * * rsync -avz /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup /mnt/usbstick/

Damit wird die SCB Datei alle 15 Minuten auf den Stick gesichert. Ihr könnt natürlich auch das besagte NFS Share benutzen oder einen externen ftp/sftp Host verwenden.

Raspiblitz SCB Datei sichern

Lokale Sicherung

Für den Raspiblitz gibt es eine automtische Backup Funktion der SCB Datei (channel.backup) unter Funktion im Raspiblitz Menu. Dies findet ihr unter Node Settings & Options:

Hier könnt ihr die SCB über auf ein USB Speicher speichern. Habt ihr eine Nextcloud, wäre dies natürlich auch eine Option.

Ihr könnt einen UBS Stick an der Node lassen, oder auf einen nfs Share sichern, zb. einem Netzwerkspeicher. Wie sowas funktioniert, erfahrt ihr z.B hier. Der Raspi oder der ist dann einfach der NFS Client. Am einfachsten wäre aber für den Heimgebrauch die USB Stick Methode die an einen entsprechenden Ort gemountet wird.

Ihr müsste dafür ein USB Stick an euren Raspiblitz anstecken, welcher als Speicherort für das Backup dient. Nach der Ausführung des Dienstes SCB/Emergency Backup führt der Blitz die Sicherung regelmässig bei der Änderung der SCB Datei durch.

Fügt den Stick nach Ausführung des SCB/Emergency Backup tools noch unbedingt in die Datei fstab mit ein, damit der Stick automatisch beim erneuten starten der Node, an den richtigen Ort gemounted wird. Schaut mit lsblk, nach dem ausführen des Services bitte nach, wo der Stick gemounted wurde ist. Der Stick muss in der Datei fstab unter /mnt/backup gemounted werden. Benutzt dazu am besten die UUID. Wie das funktioniert, erfahrt ihr am Ende des nächsten Abschnittes.

Der nächste Abschnitt aktiviert die Auto Backup Funktion über die Kommandozeile, und fügt den Stick mit in die Datei /etc/fstab mit hinzu:

Manuelle Konfiguration Auto-SCB Backup

Für die manuelle Konfiguration des Autobackup der SCB Datei via USB Stick, geht ihr am besten so vor:

Stick am PI einstecken

Am Blitz via SSH anmelden und mit CTRL+C auf die Shell wechseln.
Prüfen, ob er einen verwendbaren Stick erkannt hat:

sudo ./config.scripts/blitz.backupdevice.sh status

ungefähre Ausgabe wäre

blitz.backupdevice.sh
backupdevice=0
backupCandidate[0]='sdb 7 GB JetFlash'
backupCandidates=1

Backup aktivieren:

sudo ./config.scripts/blitz.backupdevice.sh on

Im erscheinenden Dialog FORMAT wählen

Prüfen, ob der Stick unter /mnt/backup eingehengt wurden ist:

sudo ./config.scripts/blitz.backupdevice.sh mount

UUID Ausfindig machen und in die Datei /etc/fstab hinzufügen

UUID des Sticks anzeigen lassen (Achtung! Das ist mein Stick - sieht bei euch anders aus)

Entweder ganz einfach via

blkid

oder den Status des Services nochmals abrufen nachdem ihr das Backup manuel aktiviert habt:

sudo ./config.scripts/blitz.backupdevice.sh status

Ausgabe wäre:

blitz.backupdevice.sh
backupdevice=1
UUID='1B08-0CE4'
isMounted=1

UUID kopieren und /etc/fstab editieren:

sudo nano /etc/fstab

In der Datei am Ende diese Zeile einfügen (hier wieder eure UUID eintragen):

UUID='1B08-0CE4' /mnt/backup vfat defaults 0 2

Datei speichern mit strg+o ,Y und ENTER. Beenden mit strg+x

Jetzt wird der Stick nach einem reboot automatisch gemountet und ein Backup der channel.backup erstellt sobald diese sich bei einer Channel State modifzierung verändert.

Remote Sicherung

In einer Nextcloud

Via Nextcloud könntet ihr eure SCB Datei auch remote sichern, schaut dazu in diesem gesonderten Beitrag vorbei:

Backups via Netzwerkanbindungen direkt z.b. mit NFS

Schaut mal hier vorbei, wie ihre z.B einen Ordner aus eurer Synology direkt auf einem Linux System mounten könnt.

Wiederherstellung Lightning Kanäle mit SCB

Diese Methode kommt zur Anwendung, wenn eure Node durch einen Plattenausfall verloren ist, oder aus anderen Gründen nicht mehr wiederherzustellen ist. Ihr benötigt dafür die channel.backup und eure LND Seed.

Seit Version v0.6-beta besitzt lnd ein Feature namens Statische Kanal-Backups (SCBs). Diese sind statisch, da sie nur einmal benötigt werden: beim Erstellen des Kanals. Ein Backup bleibt gültig, bis der Kanal geschlossen wird. Es enthält alle notwendigen Informationen, um die Datenverlustschutz-Funktion (DLP) im Protokoll zu aktivieren, was letztlich zur Wiederherstellung der Gelder des Kanals auf der Blockchain führt. Dies ist ein ausfallsicherer Backup-Mechanismus.

Dieser Weg gilt als sicher, weil darauf geachtet wurde, dass es keine Fallstricke gibt, wie es beispielsweise beim regelmäßigen Kopieren der channel.db Datei der Fall sein könnte. Solche Methoden können riskant sein, da man nie sicher weiß, ob man den neuesten Stand eines Kanals hat. Stattdessen bieten SCBs eine einfache, sichere Methode, um Nutzern die Wiederherstellung der Gelder in ihren Kanälen, im Falle eines teilweisen oder vollständigen Datenverlusts, zu ermöglichen. Die Backups selbst sind mit einem Schlüssel verschlüsselt, der aus dem Seed der Wallet abgeleitet ist. Dadurch können andere beim klau der channel.back Datei nicht einfach Eure Kanäle auf anderen Nodes wiederherstellen.

Voraussetzungen für einen erfolgreichen SCB

Der Peer muss online sein, ist der Peer nicht online, bewirkt der Befehl nichts, da dieser voraussetzt, dass der Peer mit dem wir Kanäle hatten, online ist und auf unseren Restore-Anfrage reagiert. Ausserdem müsst ihr eure channel.backup bereits auf das jeweilige Systen geladen haben. Die kann z.B. vom regelmässig gesicherten channel.backup USB-Stick kommen, oder ihr habt diese aus eurem Netzwerkspeicher bereits zurück auf das System transferiert.

Was passiert bei einem SCB Restore

In dem gegebenen Prozess zur Wiederherstellung von Kanälen wird der Server eine Reihe von "Kanal-Kerndaten" in die Datenbank einfügen. Diese enthalten nur die Informationen, die notwendig sind, um das Datenverlustschutz-Protokoll (DLP) zu starten, und nichts weiter. Als Ergebnis werden sie in der Datenbank als "wiederhergestellte" Kanäle markiert (ChanStatusLocalDataLoss|ChanStatusRestored), und es wird nicht zugelassen, sie für andere Prozesse zu verwenden.

Sobald die Kanal-Kern Daten wiederhergestellt sind, versucht das Chanbackup-Paket, einen LinkNode einzufügen, der alle früheren Adressen enthält, mit der unsere Node den Peer erreichen kann.

LND startet dann wie üblich und versucht, Verbindungen zu allen Peers herzustellen, mit denen wir offene Kanäle hatten. Läuft LND bereits, wird ein neuer, beständiger Verbindungsversuch initiiert.

Sobald wir eine Verbindung zu einem Peer herstellen, startet das DLP-Protokoll. Der entfernte Peer wird feststellen, dass wir Daten verloren haben, und dann sofort seinen Kanal zwangsschließen. Bevor er dies tut, sendet er jedoch die Nachricht für den Kanal-Wiederherstellungshandshake, welchen wir benötigen, um Schlüssel abzuleiten um zu beweisen das wir die originalen Besitzer sind.

Sobald die Verpflichtungstransaktion bestätigt ist, leitet unsere Node, basierend auf den Informationen im SCB, alle benötigten Schlüssel neu ab um die Guthaben dann zu bergen.

SCB Wiederherstellung mit Raspiblitz

Seid euch im klaren dass das Recovern mit SCBs einer der letzte Massnahme darstellt, um seine Kanäle bzw die Funds darin wieder zu bekommen. Beim Recovering Prozess werden alle Kanäle seitens der Peers geschlossen via forceclose. Alle Schritte gehen von einem frisch installierten RaspiBlitz Image aus, und dass die Node vollständig eingerichtet und synchronisiert ist.

Um die die Kanäle wiederherzustellen, müsst ihr in den LND Repair Options vom Blitz folgende Option verwenden:

Ein Backup müsst ihr im nächsten Fenster nicht erstellen, da ihr ja frischt installiert seid. In den folgenden Fenstern gebt Ihr Eure LND Seed an, und gebt dem Blitz an, wo Ihr Eure channel.backup gespeichert habt.

Nach der Eingabe des Seeds der LND Wallet, und dem lokalisieren der channel.backup wird der Raspiblitz den SCB Restore einleiten. Das kann je nach Anzahl Kanäle einige Zeit dauern. Die Kanäle tauchen dann wieder in der Übersicht z.B in RTL auf, stehen dann aber in der Pending Close Warteschlange. Die Closing TXs seht ihr auf eurer Node nicht aufgrund der Notfallwiederherstellung die damit einhergeht, da der Peer, und nicht ihr, einen Force Close auslösst. Die Guthaben tauchen erst auf, nachdem der Force Close bestätigt worden ist, und die blocks_until_maturity vorüber sind, und die Funds erfolgreich gesweept wurden sind.

SCB Wiederherstellung BTCPay Docker

Um Kanäle wiederherzustellen, also genauer gesagt die Force Closures für alle Channels einzuleiten, müssen wir zuerst die alte ursprüngliche LND Onchainwallet wiederherstellen, und den Wiederherstellungsbefehl erfolgreich manuell ausführen. Wie ihr die LND Wallet wiederherstellt, habt ihr bereits hier erfahren. Springt nochmals zurück, falls ihr das noch nicht getan habt.

Auf dem BTC-Pay Server müssen wir die Wiederherstellung manuel via lncli ausführen. Dafür benötigen wir den Script, der die Befehle in den LND Docker Container schickt. Die Skripte befinden sich all im btcpay-docker Ordner.

Um einen SCB Restore auszuführen benötigen wir also den Befehl bitcoin-lncli.sh restorchanbackup und die SCB Datei auf dem Server.

Wir führen also folgenden Befehl aus:

bitcoin-lncli.sh restorechanbackup --multi_file=/pfad/channel.backup

Das kann je nach Anzahl Kanäle eine weile Dauern. Bittet beachtet nochmals, dass ihr Weile warten müsst. Überprüft mit den Hinweisen hier, ob die Closing Transaktion vom Peer ins Netzwerk gesendet worden ist.

SCB Wiederherstellung Umbrel

Umbrel verfügt nicht über eine komplette Backup & Restore wie der RaspiBlitz oder BTCPay Docker. Das heisst es können nur die Kanäle via SCB gesichert und wiederhergestellt werden.

Die Wiederherstellung der Kanäle auf der Umbrel Node ist relativ einfach. Vorausetzung ist ebenso, dass die Node mit dem originalen Seed eurer alten Node wiederhergestellt worden ist. Gebt eure Seed ein nachdem ihr die Neue Lightning Node online habt, und wählt dann oben rechts die 3 Punkte. Wählt dann Recover Channels aus:

Die Node wird dann mit den Seeds und dem Channelbackup die Kanäle wiederherstellen. Dabei führt sie einfach nur lncli restorechanbackup aus. Nachdem die Umbrel Node die Kanäle wiederhergestellt hat, werden die Kanäle auftauchen, aber automatisch geschlossen, falls eure Peers den rescue Befehl eurer Node erhalten.

SCB Restore ausgeführt aber keine Schliessung in Sicht?

Als erstes sei zu erwähnen, dass bei erfolgreichem SCB keine Rückerstattungen angezeigt werden, bis die Closing Transaktion bestätigt worden ist. Laut Aussagen der LND Entwicklern ist das normal bei einem Recovery.

Die nächste Problematik: möglicherweise ist die die Transaktion nicht in den Mempool gewandert, wahrscheinlich, weil die commit-fee der Node des Peers zu niedrig angesetzt waren und sie in High-Fee Zeiten vom Mempool gepurged werden. In einem High-Fee Environment schickt LND nur channel closes in den mempool, wenn die Fee grösser als die aktuelle Purging Rate ist. In diesem Fall muss der Peer kontaktiert werden, welcher die Transaktion anstossen muss. Trettet am besten mit dem Peer in Kontakt und sucht zusammen nach einer Lösung und ob der Peer den Kanal nochmals schliessen kann. Der Peer muss dies als Force-Close tun, und nicht als Cooperative-Close!

Eine ein weiteres Problem das wir weiter oben bereits angesprochen haben, ist das der SCB Restore nicht funktioniert, wenn der Peer nicht Online ist. Der SCB Restore lösst ein Notsignal aus, dass die Peers dazu veranlasst einen Force Close auszulösen. Falls der Peer offline ist, und im dümmsten Fall nicht mehr Online kommt ist das SCB Recovery wirkungslos.

Wie finde ich die Closing Transaktionen im mempool

Öffnet zuerst mal mit lncli pendingchannels oder auf dem btcpay Server mit bitcoin-lncli.sh pendingchannels die aktuelle Kanalübersicht und sucht euch den Kanal raus, den ihr untersuchen wollt. Hier sucht hier nach den Kanälen mit ChanStatusLocalDataLoss|ChanStatusRestored und dem gesuchten Guthaben. Wir benötigen den channel_point

Diesen Kanal geben wir auf https://mempool.space ein und suchen uns die Closing-Transaktion heraus. Dafür gehen wir auf die opening TX, und suchen danach nach einer unbestätigten Transaktion:

Nach einem Klick auf den Channel-Open sehen wir die darin enthaltene Adressen und Transaktionen und dort sollten wir die Closing Transaktion gleich zu oberst finden: Diese ist eine Multi-Sig Transaktion da wir via SCB Restore signiert haben, und der Peer mit seinen private Keys ausgelösst durch unsere Anfrage.

Bei sehr hohen Onchainfees kann es sehr lange dauern, bis die Transaktion durchgeht. Entweder man wartet bis die Transaktion durch ist, oder man hilft etwas nach. Wie das geht, erfahrt ihr jetzt:

Force Closing Transaktion nach SCB Restore mit zu niedrigen Fees anstossen

Dafür gibt es ein Set an Tools von den Lightning Entwicklern namens Chantools. Die Chantools von Lightning Labs sind ein Set an Werkzeugen für die Verwaltung und Wartung von Lightning Network Nodes. Sie bieten verschiedene Funktionen, die für Nutzer von Lightning Nodes nützlich sind. Die Tools können auf einem anderen Rechner laufen und müssen nicht auf der betroffenen Node installiert werden.

Die Installation ist vor allem für Anfänger wirklich etwas komplex aber machbar. Um chantools nutzen zu können, kompilieren wir uns das Tool am besten schnell selbst. Ihr benötigt dafür einen Linux Computer und eine aktuelle Linux Distribution basieren auf Debian/Ubuntu. Chantools lässt sich auch auf dem Blitz installieren, von einigen Usern habe ich jedoch erfahren, dass dies nicht immer fehlerfrei funktioniert.

Gebt den Befehl chantools auf dem Blitz in die Konsole ein, bekommt ihr eine Befehlsübersicht. Wenn nicht, kompilieren wir uns chantools auf einem anderen Linux Rechner, oder einer virtuellen Maschine eurer Wahl selber.

Chantools installieren

Um selber zu kompilieren müssen wir zuerst die Prammiersprache Go und den Compiler Make installieren. Das geht mit folgenden Befehlen:

sudo apt install golang-go
sudo apt install make

Führt danach noch folgenden Befehl in der Komandozeile aus:

export PATH=$PATH:/usr/local/go/bin

Ladet euch die chantools mit dem git Befehl herunter:

git clone https://github.com/lightninglabs/chantools.git

wechselt in den Ordner chantools den ihr heruntergeladen habt mit cd chantools, danach kompiliert ihr das Programm mit dem einfachen Befehl make install

Schiebt die ausführbare chantools Datei dann mit:

mv ~/go/bin/chantools /usr/local/bin/

an die richtige Stelle um den chantools Befehl direkt an jedem Ort der Konsole ausführen zu können.

Danach habt ihr die Chantools auf eurem Rechner installiert und könnt den Befehl direkt verwenden.

Chantools ausführen

Die Bedienung bzw der Befehl ist etwas komplex, und wir benötigen vorher einiges an Information und zwar:

chantools pullanchor \
  --sponsorinput txid:vout \  --> ein UTXO aus Eurer LND Wallet welcher bereits bestätigt worden ist
  --anchoraddr bc1q….. \      --> die 330sats grösse Adresse aus dem Channel Closing siehe unten
  --changeaddr bc1q….. \      --> eine neue Adresse aus Eurer LND Wallet (p2wkh) z.B via RTL generieren
  --feerate 30                --> die Feerate die neu effektiv angesetzt werden soll

Möglicherweise gibt es 2 Anchor Outputs mit der grösse von jeweils 330Sats, notiert euch falls ja, beide Adressen

Kommen wir zum Ausführen des Befehls. Alle Befehle müssen in den Befehl mit den Flaggen gesetzt werden. z.B so

chantools pullanchor --sponsorinput 052a4b3fc363e1a045baa010cd5bf99024cce1d40a9a78741460934fc580aced:0 --anchoraddr bc1q9xn9wthafk4
sgp3hnuuf79twe7mpm43uzukt09t9v0m8cs8hs3fsj80zwa --changeaddr bc1qpeha3xv0m6k4u72p5sdv3e2vxsunhjzrgyp3qv --feerate 100

Anmerkung zur Feerate da es sich hier um einen CPFP Anstoss handelt, gelten nicht die eingestellten Fees. Das Thema ist etwas komplex, merkt euch aber dass bei einer eingestellten Fee von 100, zirka 55% also etwas mehr als die Hälfte als effektive Feerate für die neue Transaktion ausgeführt wird. Dies kann je nach grösse der Transaktion aber varieren.

Das Programm wird euch nach eurer LND Seedphrase fragen. Gebt die Seedphrase ein, und falls ihr keine Passphrase habt, drückt bei der Passphrase Abfrage einfach auf Enter. Das Tool erstellt euch nun einen PSBT-Output für eure Node, auf welcher ihr dem Befehl dann absetzen müsst.

Falls die Generierung der PSBT fehl schlägt, benutzt die andere Anchor Adresse mit 330Sats. Keine Angst, es passiert nichts, da Chantools merkt, wenn die andere Anchor Adresse nicht der eigenen LND Seed Wallet zugehörig ist.

Kopiert Euch die lange Zeichenfolge (PSBT), und loggt euch per SSH auf eurem Pi, dem BTCPay Server oder auf der Umbrel ein. Unter Umbrel müsst ihr, um lncli Befehle absetzen zu können, in den Docker Container wechseln (docker exec -it docker_id bash). Im Umbrel Appstore gibt es auch eine App mit der ihr direkt LND Befehle absetzen könnt:

Befolgt den Befehlen von chantools: gebt zuerst die PSBT aus dem chantools Programm ein

lncli wallet psbt finalize <psbt>

und dann:

lncli wallet publishtx <final_tx>

Ein, die final _tx ist die Transaktionsnummer die euch der Befehl wallet psbt finalize erstellt. Mit Enter setzt ihr das ganze ab, nun wird die Transaktionsgebühr aus dem UTXO, den ihr angegeben habt, erhöht.

Ihr erhaltet danach eine neue TX. Diese könnt ihr im z.B auf mempool.space eingeben und beobachten. Wird die Transaktion bestätigt, bekommt ihr eure Guthaben ohne weiters zutun zurück.

SCB durchgeführt aber der Peer ist nicht mehr online

Dies ist die allerletze Methode und sollte wirklich nur dann ausgeführt werden, wenn der Peer lange nicht mehr online war. Kommt der Peer Online, während wir versuchen die Transaktion mit einem alten State zu forceclosen, bekommt der Peer alle unsere Guthaben.

Dafür benötigen wir aber die channel.db aus dem abgestürzten System. Habt ihr diese nicht, funktioniert diese Methode hier nicht. Ausserdem benötigen wir wieder die chantools, welche wir uns auf einem System unserer Wahl installieren können.

Alten Channel State veröffentlichen falls Peer dauerhaft offline ist

Dafür müssen wir mit den chantools arbeiten, installiert, diese wie oben beschrieben, Falls noch nicht getan. Ausserdem benötigen wir die Datei channels.db, aus der gecrashten Node. Falls diese nicht mehr wiederherzustellen ist, könnt ihr diesen Abschnitt hier übersringen.

Kopie der Kanal-DB erstellen: Um sicherzustellen, dass wir auf die Kanal-DB zugreifen können, erstellen wir eine Kopie im sicheren Modus. Führt einfach folgenden Befehl aus:

chantools compactdb --sourcedb /pfad/zur/channel.db --destdb ./results/compacted.db

Wir gehen davon aus, dass die kompaktierte Kopie der Kanal-DB sich in ./results/compacted.db befindet für die folgenden Befehle.

chantools summary: Zuerst muss chantools den Zustand jedes Kanals in der Blockchain ermitteln. Dafür wird eine Blockchain-API (standardmäßig blockstream.info) abgefragt. Das Ergebnis wird in einer Datei namens ./results/summary-yyyy-mm-dd.json geschrieben. Diese Ergebnisdatei wird für den nächsten Befehl benötigt.

chantools --fromchanneldb ./results/compacted.db summary

chantools rescueclosed: Es ist möglich, dass die entfernten Peers einige der verbleibenden Kanäle bereits erzwungenermaßen geschlossen haben. Was wir jetzt tun, ist, die privaten Schlüssel zu finden, um unseren Anteil dieser Kanäle zu übernehmen. Dafür benötigen wir ein gemeinsames Geheimnis, das commit_point genannt wird und sich jedes Mal ändert, wenn ein Kanal aktualisiert wird. Wir haben die neueste bekannte Version dieses Punktes in der Kanal-DB. Der folgende Befehl versucht, alle privaten Schlüssel für Kanäle zu finden, die von der anderen Partei geschlossen wurden. Der Befehl muss wissen, auf welchen Kanälen er operiert, daher müssen wir die durch den vorherigen Befehl erstellte summary-yyy-mm-dd.json angeben:

chantools --fromsummary ./results/<summary-file-name>.json rescueclosed --channeldb ./results/compacted.db

Dies wird eine neue Datei namens ./results/rescueclosed-yyyy-mm-dd.json erstellen, die alle gefundenen privaten Schlüssel enthält und auch für den nächsten Befehl benötigt wird. Verwendet z.B. bitcoind oder das Electrum Wallet, um alle privaten Schlüssel zu übernehmen.

chantools forceclose: Dieser Befehl wird nun alle Kanäle schließen, von denen chantools annimmt, dass sie noch offen sind und deren Peers nicht mehr online sind. Dies wird erreicht, indem der zuletzt bekannte Kanalzustand aus der channel.db-Datei veröffentlicht wird. Bitte lies den vollständigen Warnungstext des forceclose-Befehls unten, da dieser Befehl eure Gelder gefährden kann, wenn der Zustand in der Kanal-DB nicht der aktuellste ist. Dieser Befehl sollte nur für Kanäle ausgeführt werden, bei denen der entfernte Peer lange mehr online war.

chantools --fromsummary ./results/<rescueclosed-file-vom-letzten-schritt>.json forceclose --channeldb ./results/compacted.db --publish

Dies wird eine neue Datei namens ./results/forceclose-yyyy-mm-dd.json erstellen, die für den nächsten Befehl benötigt wird.

Warte auf Timelocks: Der vorherige Befehl hat die verbleibenden offenen Kanäle geschlossen, indem er den Zustand deines Knotens des Kanals veröffentlicht hat. Durch das Design des Lightning-Netzwerks müsst ihr jetzt warten, bis die euch gehörenden Kanalgelder nicht mehr zeitlich gesperrt sind. Abhängig von der Größe des Kanals müsst ihr irgendwo zwischen 144 und 2000 Bestätigungen der Zwangsschließungstransaktionen abwarten. Führt den nächsten Schritt erst aus, nachdem der Kanal mit der höchsten csv_verzögerung so viele Bestätigungen seiner Schließungstransaktion erreicht hat. Ihr könnt dies überprüfen, indem ihr jede zwangsweise geschlossene Kanaltransaktion auf einem Block-Explorer (wie blockstream.info oder mempool.space zum Beispiel) nachschlagt. Öffnet die resultierende JSON-Datei des letzten Befehls (./results/forceclose-yyyy-mm-dd.json) und sucht jede TXID in "force_close" -> "txid" auf dem Explorer. Wenn die Anzahl der Bestätigungen gleich oder größer ist als der in "force_close" -> "csv_delay" für jeden der Kanäle angezeigte Wert, könnt ihr fortfahren.

chantools sweeptimelock: Sobald alle Zwangsschließungstransaktionen die Anzahl der Transaktionen erreicht haben, wie im JSON als csv_timeout gefordert, können diese zeitlich gesperrten Gelder nun übernommen werden. Verwendet den folgenden Befehl, um alle Kanalgelder an eine Adresse eurer Wallet zu übertragen:

chantools --fromsummary ./results/<forceclose-file-vom-letzten-schritt>.json sweeptimelock --publish --sweepaddr <bech32-addresse-aus-eurer-lnd-wallet>

Danach könnt ihr eure Wallets überprüfen, ob die Guthaben gutgeschrieben worden sind.

Backup & Restore auf ein anderes System

Ein sonderer Fall besprechen wir noch hier, hier könnt bei einem Node Crash, und falls schon lange gewünscht von Umbrel auf ein anderes System switchen, auf dem LND direkt läuft. Die Anleitung findet dazu hier:

https://github.com/indomitorum/Baremetal-Migration-LND

Was tun wenn gar kein Backup vorliegt und praktisch keine Daten vorhanden sind

Peer kontaktieren

Sollten absolut gar keine Backups vorliegen haben, ist noch nicht alles verloren. Versucht den Kanal-Peer zu erreichen auf irgendeine Art die euch einfällt. Dafür könnt ihr z.B https://lightningnetwork.plus/ nutzen, und dort die Node aufsuchen, und ihre eine Nachricht schicken, oder ihr nutzt die Seite auf dem sich Peers mit dem selben Problem anschreiben können: https://node-recovery.com/

Schaut unter Zombie Channel Recovery Matcher (alpha) nach und gebt eure Daten an, hat der Peer das selbe Problem, dass der Close nicht durchkommt und er auch Sats auf seiner Seite hat, wird er sicht mit etwas Glück auch hier registrieren. Falls ein Match instande kommt, werden die Daten beider Parteien durch den Maintainer der Seite zusammen geführt. Die Datenbank sucht nach Peers die beide ein Force Close hatten.

Peer erfolgreich kontaktiert, FC per remote ausgelösst

Ihr konntet euren Peer erreichen, und dieser hat den Force Close per remote durchgeführt. Da ihr keinen SCB Restore durchgeführt habt, weiss eure Nodes nichts mehr von irgendwelchen Kanälen und kann deswegen auch die Funds aus dem Force Close nicht sweepen. Wir müssen die Sats deshalb manuell sweepen, und auf eine Wallet Adresse unserer Lightning Node überweisen. Die Gelder in Force Close Transaktionen landen nämlich nicht automatisch auf der eigenen Wallet, nachdem der FC bestätigt worden ist.

Wir benötigt hier deshalb nochmals die chantools, und zwar die Funktion sweepremoteclosed:

Wir benötigen dafür unsere 24 Wörter der Lightning Node, und eine Adresse, auf denen die Funds landen sollen. Hier der Befehl mit seinen Optionen:

chantools sweepremoteclosed [flags]

Examples

chantools sweepremoteclosed \
	--recoverywindow 300 \
	--feerate 20 \
	--sweepaddr bc1q..... \
  	--publish

Options

      --apiurl string           API URL to use (must be esplora compatible) (default "https://blockstream.info/api")
      --bip39                   read a classic BIP39 seed and passphrase from the terminal instead of asking for lnd seed format or providing the --rootkey flag
      --feerate uint32          fee rate to use for the sweep transaction in sat/vByte (default 30)
  -h, --help                    help for sweepremoteclosed
      --publish                 publish sweep TX to the chain API instead of just printing the TX
      --recoverywindow uint32   number of keys to scan per derivation path (default 200)
      --rootkey string          BIP32 HD root key of the wallet to use for sweeping the wallet; leave empty to prompt for lnd 24 word aezeed
      --sweepaddr string        address to recover the funds to; specify 'fromseed' to derive a new address from the seed automatically
      --walletdb string         read the seed/master root key to use fro sweeping the wallet from an lnd wallet.db file instead of asking for a seed or providing the --rootkey flag

Der Daten welche wir brauchen: feerate, die sweepaddr (kann eine Adresse aus der Lightning Wallet sein, aber auch eine Adresse von einer anderen Wallet sein )und einen apiurl string der uns nicht Rate limitiert. Die Feerate ergibt sich aus den aktuellen mempool.space Transaktionsgebühren, wählt hier eine geeignet hohe Gebühr aus. Die sweepaddr ist die Adresse, auf der die Funds landen sollen. Generiert euch hier euch Bech32 Adresse zum Beispiel via RTL und schreibt euch diese auf. Die apiurl ist eher optional, aber wir nehmen hier eine andere, da die Standard API, die chantools verwendet, häufiger mal probleme macht. Machen wir uns an den Befehl:

chantools sweepremoteclosed --recoverywindow 300 --feerate 8 --sweepaddr bc1_adresse --apiurl=https://electrs.gugger.guru --publish

Hier bekommt die Meldung dass ihr eueren Azeed eingeben müsst:

2024-08-17 12:25:24.784 [INF] CHAN: chantools version v0.12.0 commit 
Input your 24-word mnemonic separated by spaces: ...
Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase): 

Danach erklärt euch dass chantools Adressen gefunden hat, auf die ihr Zugriff habt, verwendet den Privatekey durch den angegeben Azeed um die Adressen zu sweepen und sendet sie an die von euch angegeben Adresse:

024-08-18 13:38:53.604 [INF] CHAN: Found 1 unspent outputs for address bc1qkvtux0xxxxxxxxxxxxxxxxxxs0ejm6z520sz4xkqe
2024-08-18 13:39:18.405 [INF] CHAN: Fee 443 sats of 4996530 total amount (estimated weight 443)
2024-08-18 13:39:18.426 [INF] CHAN: Published TX 53523ffc74fe7854298283a0f103f959742fc175efe478d0e100330b9609169c

Die Published TX könnt ihr nun in einen Mempool werfen, und warten bis sie bestätigt wird. Sobald die TX durch ist, sind die Sats wieder auf eurer Wallet.

Fake SCB restore durchführen

Eine weitere Möglichkeit, seine Funds zu retten, wenn der Peer noch Online ist, ist sich selber ein SCB File zusammen zu bauen. Dies besprechen wir in einem separaten Artikel. Verasst wird dieser von einem Kollegen in einem Gastbeitrag.

Abschluss

Ihr kennt nun die wichtigsten Mittel und Wege eure Lightning Node abzusichern und im Katastrophenfall wiederherzustellen. Mir war es wichtig, dass es im Netz einen Artikel gibt, in dem quasi alle Informationen enthalten sind, und Nutzer, in einer prekären Lage sich die Informationen nicht quer auf x verschiedenen Seiten zusammen suchen müssen. Im Anhang findet ihr nochmals alle Quellen, Links und Github Seiten, aus denen die Informationen stammen. Viel Erfolg!

Quellen

https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md

https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md

https://docs.lightning.engineering/lightning-network-tools/lnd/disaster-recovery

https://node-recovery.com/

https://github.com/lightninglabs/chantools

https://gist.github.com/alexbosworth/2c5e185aedbdac45a03655b709e255a3

Dank an Zett für die Bereitstellung einiger Hinweise und Bilder auf dem RaspiBlitz!

The post Der Backup & Restore Leitfaden für Lightning Fullnodes appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wie funktioniert Timeshift

Timeshift erstellt inkrementelle Snapshots des Dateisystems, die bei Bedarf vollständig oder teilweise wiederhergestellt werden können. Diese Snapshots erfassen den Zustand des Systems zu einem bestimmten Zeitpunkt und können auf einem externen Laufwerk oder auf einer anderen Partition gespeichert werden. Die Verwendung von Timeshift kann ein Lebensretter sein, wenn man vorhat, risikoreiche Änderungen am System vorzunehmen oder einfach nur eine zuverlässige Möglichkeit zur Datensicherung benötigt.

Vorbereitungen

Für Snapshots die aufbewahrt werden sollen, sollte eine externe Festplatte gewählt werden die mindestens doppelt so gross ist, wie die aktuelle Systemgrösse. Dazu könnt ihr auf eure Systempartition in einem Dateienexplorer wie Discover klicken, und unter Eigenschaften schnell herausfinden, wie gross diese ist. Möchtet ihr die Wiederherstellung nutzen, um vor Systemveränderungen eine Sicherung zu erstellen, reicht auch eine zweite Partition auf dem Gerät aus, um dort die Kopien kurzfristig aufzubewahren. Eine Partition mit genügend Speicherplatz sollte bereits erstellt und vorhanden sein.

Der externe Datenträger muss als ext4 formatiert sein.

Installation von Timeshift

Installiert euch das Tool über die Software Centren eurer Distros wie im Beispiel zu sehen:

oder einfach schnell und bequem in der Konsole mit dem Befehl:

sudo apt install timeshift

Anleitung zur Verwendung von Timeshift

Beim ersten Start werdet ihr von einem Einrichtungsassistenten begrüßt, der euch hilft, das Programm zu konfigurieren.

Auswahl des Snapshot-Typs

Wählt zwischen Rsync (für Dateisysteme ohne Snapshot-Fähigkeit) und BTRFS (wenn ihr ein BTRFS-Dateisystem verwendet). Das haben in der Regel allerdings die wenigstens Distros als Standard Dateiensystem. Ihr könnt bedenkenlos Rsync nehmen.

Speicherort wählen

Wählt das Laufwerk aus, auf dem die Snapshots gespeichert werden sollen. Es wird empfohlen, ein externes Laufwerk zu verwenden, um die Sicherheit der Snapshots zu gewährleisten.

Ihr könnt aber auch eine Partition erstellen die nur als Speicherort für die Backups dient. Das ist sinnvoll wenn ihr TimeShift vor Systemänderungen oder Treiberinstallationen verwenden möchtet.

Zeitplanung für Automatisierungen

Konfiguriert, wie häufig Snapshots erstellt werden sollen – z.B. stündlich, täglich oder wöchentlich. Bei regelmässigen automatischen Snapshots, muss sich das Laufwerk, falls extern, natürlich immer am Gerät befinden.

Stellt die Anzahl der zu behaltenden Snapshots ein. Setzt keine Haken, falls keine automatischen Sicherungen gewünscht werden. Behalten bedeutet, wieviele Kopien von den jeweiligen Zeitintervallen zurückbehalten werden, bis sie gelöscht werden. Die Standardeinstellungen kann man in den meissten Fällen so lassen.

Daten bzw Benutzer mit einschliessen oder ausschliessen

Im nächsten Fenster geht es um die Sicherung der Daten. Wählt euren Home-Ordner mit aus, falls ihr eine Sicherung inklusive des Home Ordners möchtet. Im Home Ordner sind auch alle Dokumente, Bilder, Vieos und Einstellungen eurer Programme, sichert diesen mit falsch gewünscht.

Ihr könnt auch verschiedene Snapshots erstellen, einmal mit dem Home Ordner inkludiert, einmal ohne. Ihr könnt dies dann hinter die entsprechenden Wiederherstellungspunkte vermerken. Achtet darauf, dass euer BackupPlan überlegt ist, und Sinn ergibt.

Filter

Die Verwendung der Filter erfordert ein gewisses Verständnis für deren Logik. Stellt euch vor, ihr habt in den Einstellungen die Option für das Verzeichnis /Dokumente/Musik/ aktiviert. Dies bedeutet, dass Timeshift nur Dateien in diesem Pfad sichert. Nun möchtet zusätzlich das Verzeichnis /Dokumente/Musik/Pop/ sichern, aber das darin enthaltene Unterverzeichnis /Klassik/ soll ausgeschlossen werden. Ein Beispiel für die entsprechenden Filterregeln:

+ /Dokumente/Musik/
- /Dokumente/Musik/Pop/Klassik/
+ /Dokumente/Musik/Pop/***

Von der Logik her würde man den Ausschluss von /Klassik/ am Ende der Liste erwarten. Dies funktioniert jedoch nicht, da Filter zwar auf nachfolgende Regeln anwendbar sind, aber nicht rückwirkend wirken. Würde der Ausschluss von /Klassik/ am Ende stehen, würde es dennoch gesichert, da der Filter /Dokumente/Musik/Pop/*** dieses Verzeichnis bereits einschließt. Ein Rückwirkender Ausschluss ist nicht möglich.

Die 3 Sterne bedeutet dass alle Unterordner und darin enthaltenen Dateien mitgesichert werden. Benutzt die Sterne um alle in einem Ordner befindliche Dateien mitzusichern.

Seid ihr mit dem Assistenten durch, könnt ihr anschliessend alles nochmals in den Einstellungen überprüfen und gegebenfalls abändern.

Snapshot erstellen

Das erstellen der Snapshots ist sehr einfach, klickt dafür einfach auf Erstellen, um manuell einen Snapshot zu erzeugen. Automatische Snapshots werden entsprechend eurer Zeitplanung durchgeführt. Bitte beachtet, dass die Erstellung eines Snapshots einige Zeit in Anspruch nehmen kann.

Wiederherstellung des Systems

Wählt den Snapshot aus, den ihr wiederherstellt möchtet, und klicke auf Wiederherstellen. Im ersten Feld seht ihr eine Übersicht, wo und wie euer System wiederherstellt wird. Achtet einfach darauf, dass die Wiederherstellung auf eure ursprüngliche Systempartition stattfindet:

Befolgt die Anweisungen, um die Wiederherstellung abzuschließen. Habt ihr euer System komplett zerschossen, dann könnt ihr das exakt gleiche Betriebssystem neu installieren, und anschliessend Timeshift neuinstallieren und aus einem Backup von eurer externen Festplatte wiederherstellen.

Klickt dafür auf Durchsuchen und klickt das erste Fenster weg, danach öffnet sich der Explorer und wählt den Timeshift Ordner falls das frisch installierte System euren Sicherungensort nicht sofort wiedererkennt. Es ist zu empfehlen, die Snapshots bzw. den Ordner timeshift von eurer externen Platte direkt wieder in euren Home Ordner, auf dem zu wiederherstellenden System, zu packen.

Backup Strategien

Am besten erstellt ihr euch 2 Sicherungsjobs: einen ohne Home Ordner, und eine Komplettsicherung inkl. Homeordner. Die Sicherung ohne Homeordner läuft dann regelmässig, zum Beispiel auf das eigene System, oder auf eine NAS im Netzwerk. Wenn etwas schief gegangen ist, nach kleineren Tüfteleien oder Programmupdates, und ihr bringt es einfach nicht wieder zum laufen, nutzt ihr die Sicherung ohne Homeordner.

Der 2te Sicherungsjob mit Homeordner läuft NICHT automatisch. Diesen stosst ihr nur an, wenn ihr vor grösseren Änderungen steht, wie zum Beispiel einem Distributionsupgrade steht, zum Beispiel von Ubuntu 22.04 auf Ubuntu 24.04. Dieses Backup darf später nicht wieder verwendet werden, den ansonsten überschreibt es auch euren Homeordner, inklusive all eurer neu erstellten, oder veränderten Dokumente!

Fazit

Mit dieser Anleitung solltet ihr in der Lage sein, Timeshift effektiv für Backups eures Linux-Systems zu nutzen. Es ist ein wertvolles Werkzeug, das euch dabei helfen kann, viele Arten von Systemproblemen zu vermeiden oder zu beheben, ohne dass Daten verloren gehen. Wenn ihr mehr über die Thematik Backups wissen wollt, schaut mal hier vorbei. Für Sicherungen von OpenSuse Systemen empfehlen wir hingegen das Tool Snapper.

The post Systemwiederherstellung unter Linux mit TimeShift appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Für das Backup benötigt Ihr eine ausreichen grossen Datenträger oder eine NAS die Verbindung zur Node hat. Wichtig ist, dass wir nicht einfach die Blockchain kopieren, sondern rsync dafür verwenden. Dies stellt sicher das alle Berechtigungen und Besitzertüme beim kopieren genau so bleiben wie sie sind. Stellt also sicher dass auf auf der der Node und auf dem Zielgerät rsync installiert ist. Für Windows Computer gibt es dafür das Tool Delta Copy.

Stellt sicher dass auf Eurem Linux Zielrechner wie ein Linux Computer ein SSH-Server installiert ist, und dieser via SSH erreichbar ist. Auf dem Windowsrechner machen wir es später jedoch ohne SSH weil dass nicht immer funktioniert.

Der Befehl zur Installation eines SSH-Servers wäre:

sudo apt install openssh-server

Eine Konfiguration ist nicht weiter notwendig. Stellt einfach sicher das Port 22 auf Eurem Linux Client offen ist.

Erstellt auf den Zielgeräten einen Ordner der für das aufbewahren benutzt werden soll. Auf der einer Synology kann das z.B ein neuer gemeinsamer Ordner sein. Stellt sicher das Rsync auf der Eurer NAS bzw auf Eurer Synology aktiviert ist.

Beim Windows Client müsst Ihr ebenfalls einen Ordner für den Empfang eingerichtet und freigegeben werden. Hier müssen wir Delta Copy wie in diesem Beitrag hier eingerichtet haben. Die Rsync Einrichtung auf einem Linux Client ist hier nicht nötig!

Ob Rsync auf Eurem Linux Geräten, bzw der Node installiert ist, könnt Ihr mit rsync --version überprüfen. Falls nichts vorhanden, installiert es einfach mit:

apt install rsync

Umbrel Fullnode Blockchain sichern

Loggt Euch zuerst via SSH auf der Umbrel ein. Checkt nochmals ob rsync installiert ist. Wenn ja kann es bereits gleich losgehen.

Auf NAS sichern

Der Ordner auf der NAS muss exisiteren, und eine SSH Verbindung zum Ziel muss eingerichtet sein. Auf der Umbrel ist der Pfad zur Blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/
Dort sind die 3 Ordner blockchain, chainstate und indexes gespeichert. Diese 3 Ordner müssen wir sichern.
Auf der Synology NAS wäre der Ziel Ordner unter /volume1/backups/blockchain/umbrel/ zu finden. Die Befehle wäre also:

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/chainstate  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

und

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/indexes benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

Ihr könnt das ganze zuerst mal testen indem Ihr eine kleine Datei wie die debug.log auf den Zielrechner schiebt.

Auf einer externen Platte auf einem Linux Client sichern

Der Befehl ist der gleiche, der Zielort muss leicht angepasst werden. Schaut in der Konsole wie z.B ein externer Datenträger eingebunden worden ist mit dem Befehl lsblk

Ihr seht dass der USB Stick als sda1 zu finden ist, und unter /media/mario/stickbezeichnung gemounted wurden ist. Nehmen wir an auf dem USB Stick wäre noch der Ordner umbrel auf dem Ihr die Daten sichern wollt, dann währe der Pfad zum Ordner /media/mario/stickbezeichnung/umbrel/

Dementsprechend passt Ihr den Befehl an mit dem Benutzernamen und der IP Adresse des Linux Rechners:

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/ordnername mario@192.168.1.84:/media/mario/7E2D368C6FFFE5CF/umbrel/

Nun müsst Ihr wieder Ordnername mit den 3 Ordner blockchain, indexes und chainstate ersetzen und könnt die Ordner direkt auf eine externe Festplatte sichern.

Auf einer externen Platte mit Windows Betriebssystem sichern

Windows SSH Server ist nicht wirklich zuverlässig, deshalb erledigen wir dass mit einen Rsync Server den wir direkt ansprechen. Wir müssen wie in den Vorbereitungen bereits angesprochen DeltaCopy installieren. Wir erstellen auf DeltaCopy Server ein neues Modul mit dem namen blockchain, und setzen den Pfad auf den externen Datenträger

Dazu müsst Ihr einfach nur Add New Directory auswählen und mit Browse den Pfad angeben. Stellt sicher das der Rsync Server läuft und die Ampel auf grün zeigt. Ausserdem muss auf Eurem Windowsrechner der Rsync TCP Port 873 offen sein.

Danach sprecht Ihr das Ziel nicht mit einem Pfad an, sondern mit dem Modulnamen, in unserem Falle blockchain.

rsync -avz --info=progress2 --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/ordnername 192.168.1.75::blockchain

RaspiBlitz Fullnode Blockchain sichern

Die Befehle sind alle gleich, ausser dass die Blockchain woanders zu finden ist. Der Pfad für die Blockchain auf dem Raspi ist: /mnt/hdd/bitcoin/

Die Ordner heissen hier: blocks, chainstate und indexes.

Die Befehle sind also nur bzgl des Quellpfades anzupassen, z.B für die Sicherung auf die NAS:

rsync -avz --info=progress2 --append-verify /mnt/hdd/bitcoin/blocks  benutzername@172.16.0.54:/volume1/backups/blockchain/raspi/

Bitte Zielordner dann halt ensprechend mit raspi oder so abändern.

Wiederherstellen der Blockchain auf Fullnodes

Habt Ihr Eure Fullnode verkonfiguriert, oder habt eine neue, könnt Ihr nun die Blockchains auf die jeweiligen Geräte ziehen.

Wichtig dabei ist, dass die Geräte nicht syncen währen der Übertragung. Der bitcoind.service muss also kurz angehalten werden.

Unterm Raspi ist das relativ einfach. Ihr richtet das Gerät ein bzw installiert RaspiBlitz, und lasst ihn kurz in Ruhe damit alle nötigen Ordner erstellt werden können. Danach stopt ihr die synchronisation mit:

sudo systemctl stop bitcoind.service

Sobald Ihr alle Daten wieder rüber habt. Könnt Ihr den Service mit

sudo systemctl start bitcoind.service 

wieder starten.

Auf dem Umbrel müsst Ihr kurz den Docker-Container stoppen. Der Container heisst normalerweise lncm/bitcoind:v25.1

Checkt kurz mit docker ps wie der container bei Euch heisst. Ihr erkennt in an der Bitcoin Core Versionsnummer, hier in meinem Falle 25.1

Stoppt den Container mit:

docker stop bitcoin_bitcoind_1

und startet Ihn wieder mit:

docker start bitcoin_bitcoind_1

Sobald die Übertragung aller Ordner fertig ist.

Die Daten von der NAS oder vom Linux Backup ziehen

Ihr müsst Euch nun vom jeweiligen Gerät arbeiten. Also entweder auf der Umbrel oder auf dem Blitz. Der Rsync Befehl ist nun umgekehrt:

rsync -avz --info=progress2 --append-verify benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain

oder für den Raspi:

rsync -avz --info=progress2 --append-verify benutzername@172.16.0.54:/volume1/backups/blockchain/raspi/blocks /mnt/hdd/bitcoin/blocks

Daten von Windows Rsync Modul ziehen

Beim Windows Rsync Server müssen wir uns einfach auf das Modul beiziehen. Gebt Modulname und Pfad zum Ordner an, also Beispielsweise für die Umbrel:

rsync -avz --info=progress2 --append-verify 192.168.1.75::modulname/umbrel/blockchain /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain

Auf dem Raspi ist der Pfad und der Ordnername blocks entsprechend anzupassen.

Danach könnt Ihr die Services wieder starten und kurz abwarten bis die Node die Daten gecheckt hat. Auf dem Umbrel geht das meisst ganz fix. Der Raspi benötigt allgemein etwas länger. Falls es Probleme auf dem Raspi gibt, checkt die logs mit:

sudo tail -f /mnt/hdd/bitcoin/debug.log

Hat der Raspi die Blockchain korrekt geladen, dürfen keine Blockchain Fehler auftreten und die Syncro muss normal weiter gehen:

Die Sicherungen automatisieren

Wenn Ihr wollt, könnt Ihr das ganze auch automatisieren. Führt Ihr rsync via SSH aus, dann müsst Ihr natürlich ein Passwort eingeben. Das funktioniert natürlich nicht wenn das alles automatisch ablaufen soll. Deshalb kann sich der Quellrechner via SSH-ID beim Zielrechner authentifzieren. Das geht mit ssh-copy-id

Loggt auf auf Eurer Node ein. Führt den folgenden Befehl aus:

ssh-copy-id benutzername@IPdesBackupsServers

und gebt Euer Passwort des Zielrechners ein. Danach liegt der öffentliche Schlüssel der Fullnode auf dem Zielrechner, und dieser muss sich von nun an nicht mehr mit einem Passwort authentifzieren, sondern tut das über SSH Schlüsselpaare. Damit ist die voraussetzung geschaffen um automatische Rsync Befehle über SSH zu ermöglichen.

Cronjob erstellen

Mit crontab -e erstellen wir einen neuen Cronjob. Richtet Ihr das erste mal ein, fragt Euch Crontab mit welchen Editor Ihr arbeiten wollt. Nehmt am besten immer Nano, also die Nummer eins.

Danach tragt Ihr am Ende der Datei folgendes ein:

0 1 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/blockchain  benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

0 6 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/indexes benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

0 8 1 * * rsync -avz --append-verify /root/umbrel/app-data/bitcoin/data/bitcoin/chainstate benutzername@172.16.0.54:/volume1/backups/blockchain/umbrel/

Damit wird Beispielsweise immer am ersten des Monats um 01:00 der rsync Befehl ausgeführt. Gestartet wird mit dem Ordner blockchain, diesem geben wir 5 Std Zeit, danach indexes und 2 Stunden später chainstate. Passt den Befehl auf Eure Fullnode Betriebssystem und Euren Speicherort entsprechend an.

Damit sollte die Blockchain regelmässig gespeichert werden. Mehr als einmal im Monat ist in der regel nicht notwendig, dass könnt Ihr aber nach Euren Bedürfnissen anpassen.

Weitere wichtige Hinweise

Falls Daten bzw Ordner nicht übertragen werden, checkt Eure Firewall-Einstellungen und achtet darauf dass die jeweiligen Ports geöffnet sind.

Wichtig ist, dass das SSH Fenster, auf dem Ihr die Übertragungen startet, nicht geschlossen werden. Die Blockchain Sicherhung oder Übertragung kann bei ca 700GB je nach Netzwerkgeschwindigkeit mehrere Stunden gehen. In dieser Zeit darf der Rechner, mit dem Ihr Euch verbindet auf die Nodes verbindert, nicht schlafen geht! Schaltet also den Suspend bzw Schlafmodus des Rechners ab! Bricht die SSH Verbindung ab, bricht auch die Übertragung ab!

The post Bitcoin Blockchain mit Rsync sichern auf Umbrel & Raspi appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Methode um unseren Home Ordner auf einer NAS zu sichern, haben wir bereits mal hier kennen gelernt. Hier ging es aber eher um ein Backup des Home Ordners inkl. aller Dokumente. Wollt ihr einfach Systemeinstellungen und die Programme sichern, haben wir hier eine etwas angepasste Variante. Das bietet sich z.B bei und nach der Neuinstallation des Systems an.

Voraussetzungen

Die Vorausetzungen für das Backup sind eigentlich sehr einfach, ihr benötigt:

• Ein USB Stick oder eine externe Festplatte mit genügend Speicherkapazität
• Das BackUp Tool Borg mit der Benutzeroberfläche Vorta
• Das neue System sollte den selben Unterbau haben, hattet ihr ein Ubuntu System, dann sollte es anschliessend auch wieder Ubuntu sein.
• Ein aktuelles System mit allen Updates.

Datenträger vorbereiten

Formatiert euch den Datenträger mit ext4 oder ntfs und vergebt dem Gerät einen eindeutigen Namen. Wie das genau funktioniert, erfahrt ihr hier. Legt euch auf dem USB-Stick oder auf der externen Festplatte einen Ordner mit dem Namen Backup an. Hier sind wir bereits fertig, weitere Vorbereitungen müssen nicht getroffen werden.

Programme sichern

Wir sichern nicht direkt die Programme da dies unter Linux unnötig ist, und die reinen Installationen keine Konfiguration der Programme enthält. Was wir sichern, ist eine Liste aller installierten Programme und separat die Konfigurationen unserer Programme, damit anschliessend alle Apps und Programme so eingerichtet sind, wie sie vorher waren. Alle Konfigurationen und Einstellungen werden unter Linux standardmässig im Home Order gespeichert.

Wir erstellen zuerst eine Liste aller Programme, speichern diesen in eine Text Datei, welche wir verwenden können, um danach auf dem frisch installierten Gerät alle Programme in dieser Liste automatisch wieder zu installieren. Es werden alle Programme gesichert, die ihr aktuell auf dem System installiert habt.

Wir updaten alle Programme und erstellen gleich eine Liste mit dem Befehl:

sudo apt update && sudo apt upgrade -y && dpkg --get-selections > /home/Benutzername/Dokumente/paketliste.txt

Ersetzt Benutzername mit eurem Benutzernamen! Diese Datei sichern wir uns z.B auf dem USB Stick.

Installation von Borg bzw Vorta

Die Insallation ist sehr einfach. Öffnet das Terminal und gebt folgenden Befehl ein:

sudo apt install vorta

Anwendungseinstellungen mit Borg / Vorta sichern

Öffnet das Programm Vorta. Im ersten Reiter Repository wählen wir ein Sicherungsziel. Legt hier mittels dem Plus Symbol und Neues Repository ein neues Sicherungsziel an. Dies ist bei uns der eingerichtete Datenträger. Der befindet sich immer in System-Ordner media.

Vergebt ein Passwort und wählt Hinzufügen. Für eine unverschlüsselte Sicherung könnt ihr auch im Tab Erweitert ein unverschlüsseltes Backup erstellen --> Verschlüsselung --> Unverschlüsselt

Zu sichernde Verzeichnisse

Die meisten Programme speichern ihre Einstellungen im Home-Verzeichnis des Nutzers, normalerweise in versteckten Ordnern (die mit einem Punkt . beginnen). Ihr könnt das gesamte Home-Verzeichnis sichern, um sicherzustellen, dass keine wichtigen Dateien verloren gehen, oder auch nur die wichtigsten Ordner in den die Einstellungen enthalten sind:

• ~/.config/: Hier befinden sich die meisten Konfigurationsdateien für Anwendungen, die die XDG-Standardverzeichnisse verwenden.
• ~/.local/share/: Dieser Ordner enthält Daten und Konfigurationen, die lokal gespeichert werden, einschließlich einiger Programmeinstellungen und Anwendungsdaten.
• ~/.cache/: Enthält zwischengespeicherte Daten. Dieser Ordner ist nicht unbedingt notwendig, aber es kann sinnvoll sein, ihn zu sichern, wenn ihr bestimmte Programme vollständig wiederherstellen möchtet.
• Versteckte Dateien und Ordner: Viele Programme legen ihre Einstellungen direkt im Home-Verzeichnis in versteckten Dateien (z.B. .bashrc, .vimrc) oder Ordnern (z.B. .mozilla, .thunderbird) ab.
• /etc/: Enthält Konfigurationsdateien für das System und viele Programme. Wenn ihr spezifische Programme sichern möchtet, kannst du gezielt die entsprechenden Unterverzeichnisse sichern.
• /var/: In manchen Fällen speichern Programme Daten in /var, zum Beispiel Datenbanken oder Webserver.

Geht in den nächsten Reiter Quellen, und fügt mit dem Plus Symbol wie im Beispiel zu sehen eure Quellen hinzu. Der Screenshot gilt nur als Beispiel. Auf eurer Konfiguration sind natülich je nach Wunsch weitere Ordner enthalten.

Den Ordner /etc könnt Ihr einfach aus der Liste auswählen. Die Ordner .config oder auch zum Beispiel .thunderbird oder .mozilla müsst ihr in der Liste unten im Pfad selber hinzufügen da er in der Listenansicht versteckt ist. Fügt hier die Ordner der Programme hinzu die gesichert werden sollen. Checkt dazu im Terminal mit ls -la welche Programme eigene versteckte Ordner angelegt haben:

Wollt ihr weitere Quellen hinzufügen. z.B eure Dokumente, könnt ihr dass natürlich hier auch tun, und einfach die gewünschten Ordner hinzufügen.

Um die Sicherung zu starten, wählt unten dann einfach Datensicherung starten aus und das Tool sichert alle Daten auf euren Datenträger.

Wiederherstellung eurer Programme

Auf dem frisch installierten System könnt ihr nun den USB Stick anhängen, und mit folgenden Befehl all eure Programme wieder hinzufügen und installieren. Kopiert dafür vorher die Paketlisten-Text Datei vom USB-Stick in den Dokumenten Ordner auf eurem Linux System, und führt folgenden Befehl im Terminal aus:

sudo dpkg --set-selections < /home/Benutzername/Dokumente/paketliste.txt && sudo apt-get dselect-upgrade

Damit wird euer System wieder mit allen Programmen ausgestattet, die vorher auf dem alten System vorhanden waren.

Wiederherstellung der Konfigurationen

Installiert euch zunächst erstmal wieder as Backup Tool Borg / Vorta, danach öffnet ihr das Programm. Jetzt fügt ihr mit dem Plus Symbol ein bestehendes Repository hinzu. Wählt den Ordner auf dem USB Stick aus in unserem Falle den Ordner backup

Das Repo wird mit dem Button Add hinzugefügt.

Als nächstes gehen wir in den Reiter Archive und machen uns an die eigentliche Wiederherstellung der Konfigurationen.

Dazu wählen wir unser Archiv aus, und benutzen die Entpacken Funktion. Wir können danach auswählen, wohin die enthaltenen Dateien entpackt werden. Wir wählen dazu direkt die Ordner, in dem die Daten auch vorher gesichert worden sind.

Im nächsten Feld wählen wir z.B den Ordner /etc und entpacken diesen auch gleich direkt in den Ordner /etc auf dem System:

Wählt OK und der Ordner vom Datenträger wird in den vorgesehenen Ordner entpackt. Macht das selbe mit dem Home Ordner. Im Home Ordner sind sämtliche Ordner enthalten, die ihr zusätzlich angegeben habt, wie zum Beispiel .config, .mozilla und etc.

Danach wäre die Sicherung auch bereits schon vollständig wiederhergestellt. Startet das System zur Sicherheit kurz neu. Eure Programme sollten nun die Einstellungen haben, die sie vorher auf eurem alten System auch hatten.

Jetzt können wir auf unserem neuen System weiterarbeiten, wie als wäre garnichts gewesen und das nur mit kostenfreien Open-Source basierten Tools und einigen Befehlen auf der Kommandozeile.

Ich hoffe ich habe euch mit dem Artikel "Linux Programme und Einstellungen sichern und wiederherstellen" etwas weiterhelfen können. Habt ihr Fragen oder Anliegen? Schreibt sie in die Kommentare!

The post Linux Programme & Einstellungen sichern und wiederherstellen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Deshalb ist es meiner Meinung nach unerlässlich seine NAS auch selber in regelmässigen Abständen zu sichern. Das kann auf USB Sticks erfolgen, wobei bei grossen Datenvolumen auch da schnell der Speicherplatz ausgeht. Am besten wäre ein BackUp auf einen weiteren PC im Netzwerk, welchen man mit einer zusätzlichen Festplatte ausgerüstet werden kann. Auf dem Gebrauchtmarkt gibt es 8 TB Festplatten aktueller Generationen bereits ab 150CHF. Ältere Festplatten tun es auch, solange sie keine SMART Fehler liefern und einwandfrei funktionieren. Es muss keine teure NAS Festplatte sein, da die Platte nur als Datengrab dienen muss, auch deshalb keine hohe Anforderungen gerecht werden muss. Wer eine alte 2 bis 4 TB Festplatte nutzlos zuhause rumliegen hat, kann diese benutzen um Eure Daten auf eurer NAS zusätzlich zu sichern.

Wie man am besten so ein Backup einrichtet zeige ich Euch in diesem Artikel. Sichern könnt Ihre Eure NAS auf einem Windows, sowie auf einen Linux Rechner. Wir benutzen die Opensource Variante Rsync

Vorbereitungen für das NAS BackUp

Windows Rsync Server einrichten

Um Eure NAS auf einen Windows Rechner zu sichern müssen wir ein Tool installieren, und die Firewall entsprechend einrichten. Ladet Euch das Tool DeltaCopy hier herrunter und installiert es. Nehmt auf der Seite rechts in dem Kasten die Variante "With Installer"

Erstellt Euch auf eurer BackUp Platte einen Ordner mit einem Namen eurer Wahl. Öffnet dann das Tool Delta Copy Server, und geht in den Reiter Virtual Directories. Rechts wählt Ihr "Browse" und navigiert in den erstellten Ordner in welchem das BackUp geladen werden soll. Geht nun Zurück zum Server Status und startet den Server mit "Start Server" Leuchtet die Ampel Grün, sind wir hier schonmal fertig.

Als nächstes müssen wir in die Firewalleinstellungen von Windows. Gebt dazu einfach unten im Suchsymbol "Firewall" ein und wählt das Suchergebnis "Windows Defender Firewall"
Klickt auf "Erweiterte Einstellungen", dann im neuen Fenster auf eingehende Regel, und anschliessend in der rechten Box auf "Neue Regel"

Wählt als Regeltyp die Option "Port", drückt auf Weiter und wählt das Protokol "TCP" und gebt unter "bestimmte lokale Ports" den Port "873" an. Drückt auf weiter und wählt als nächstes "Verbindung zulassen". Im nächsten Fenster könnt ihr die Profile Domäne, Privat und Öffentlich aktiviert lassen. Drückt auf weiter und gebt der Regel einen Namen und falls erwünscht eine Beschreibung. Anschliessend bestätigt Ihr mit "Fertigstellen"
Mit der Einrichtung unter Windows sind wir erstmal fertig.

Linux Rsync Server einrichten

Öffnet Euren Terminal und installiert den Rsync Server mit

sudo apt-get install rsync

Nun müssen wir den Rsync Server noch kurz konfigurieren und eine Konfigurationsdatei anlegen. Erstellt dazu mit dem Befehl

sudo nano /etc/rsyncd.conf 

eine neue Konfiguartionsdatei und konfiguriert sie wie im Screenshot.

Ersetzt dabei beim Pfad "synobackup" mit dem Ordnernamen Eurer Wahl. Ihr könnt auch "my_path" in einen Modulnamen Eurer Wahl ändern z.B in [Syno_Backup]

motd file = /etc/rsyncd.motd 
log file = /var/log/rsyncd.log 
pid file = /var/run/rsyncd.pid 
lock file = /var/run/rsync.lock 

[my_path] 
  path = /opt/mysynobackup 
  comment = My Rsync Server 
  read only = no 
  list = yes 
  secrets file = /etc/rsyncd.secret

Startet als Nächstes den Rsync Server Daemon mit

sudo rysnc --daemon

Startet rsync mit dem Befehl

sudo systemctl enable rsync

Erstellt den BackUp Ordner mit dem Befehl

sudo mkdir /opt/synobackup

Erstellt die passenden Rechte mit

sudo chmod -R 755 /opt/synobackup

Versichert Euch mit dem Befehl das Rsync richtig läuft:

sudo systemctl status rsync

Rsync muss in grüner Farbe als "running" ausgewissen werden.

Wenn nicht, geht mit

sudo nano /etc/default/rsync

in diese Datei und versichert Euch das RESYNC_ENABLE auf true steht. Startet den Rechner neu sollte es immer noch nicht klappen.

BackUp Aufgabe auf Synology NAS erstellen

Geht in Eurer Synology in den Packetmanager und installiert Euch das Tool Hyperbackup. Hyperbackup ist einer der besten Anwendungen um seine Daten zu sichern und und bietet viele Konfigurationsmöglichkeiten und vor allem auch viele Optionen zur Sicherung auf externen Zielen.

Öffnet die App Hyperbackup und klickt oben links auf das Plus Symbol im blauen Kasten. Wählt nun als BackUp die "Datensicherungsaufgabe" und wählt als Dateiserver "rsync" aus. Im nächsten Feld Gebt Ihr die Daten Eures Rsync Rechners ein inkl Login Daten und Passwort. Wählt dazu als Rsync Server den "Rsync Kompatiblen Server" aus. Für interen BackUps braucht Ihr keine Verschlüsslung.

Das Backup Modul ist das Modul das wir auf Rsync Linux Server erstellt haben, oder der Name des BackUps auf dem Deltacopy Server auf Windows. Verzeichnis ist der Name des kompletten backup root folders der von hyperbackup erstellt wird. Diesen könnt Ihr nennen wie Ihr wollt. Habt Ihr beide Windows und Linux richtig konfiguriert wird das Backup Modul Euch automatisch angezeigt.

BackUp Einstellungen

Im nächsten Fenstern könnt Ihr auswählen was und welche Ordner genau gesichert werden sollen. Soll alles gesichert werden, wählt die entsprechenden Volumen direkt aus. Im nächsten Schritt geht es um die Apps auf der Synology NAS welche gesichert werden sollen. Es werden Apps und deren Einstellungen gesichert. Wählt alle aus für ein komplettes BackUp

Im nächsten Fenster geht es um die Aufgabenplannung. Eine Komprimierung des BackUps ist sinnvoll und kann ausgewählt werden. Wählt die Aufgabenplannung nach Eurem Gusto. Verschlüsslung deaktiviert belassen da wir keine Verschlüsslung konfiguriert haben. Intern im Netzwerk ist das auch nicht unbedingt notwendig. Bedenkt dass Eurer Rsync Rechner zu den Aufgabenplannung Online sein muss, sonst gibts nichts zu speichern.

Als nächstes kommt die Sicherungsrotation. Dies ist einer der grossen Highlights von Hyperbackup. Hier könnt Ihr quasi wählen, wieviel Versionen Eurer Sicherungen aufbewahrt werden sollen. Dabei ist zu beachten dass Sicherungsversionen die grösse des Backups nicht automatisch mit jeder weiteren Anzahl linear erhöht. Hyperbackup merkt sich, vereinfacht gesagt nur, was sich zwischen den Versionen verändert hat, und schreibt diese Veränderungen in das Backup. Alles was gleich bleibt wird nicht extra jedesmal neu gesichert. Ihr könnt trotzdem zwischen diesen Sicherungen später auswählen, und könnt die Synology zu jedem beliebigen Zeitpunkt gemachter BackUps wiederherstellen ohne dass sich die Grösse des BackUps stettig vergrössert.

Wählt dazu am besten die "Smart Recycle" und nehmt eine beliebige Anzahl zwischen 64 und 256 Versionen. Hyperbackup behält intelligent eine jeweilige Anzahl an Versionen zurück, und löscht dann am Ende die letzten in der Reihe der BackUps. Genaueres findet Ihr in der Beschreibung zu Smart Recycle auf dem Info Button.

Habt Ihr alles einrichtet, erscheint die Aufgabe nun in der Hyperbackup App rechts im Feld und gibt Euch Informationen zu Eurer Konfiguration. Wollt Ihr Euer System nun wiederherstellen, könnt Ihr oben Links in der Mitte auf Wiederherstellung, Daten, und danach hilft Euch der Wiederherstellungassistent durch die Wiederherstellung Eurer Synololgy NAS. Dabei könnt Ihr auswählen, was, wann und wie wiederhergestellt werden soll, ob Systemkonfiguration, nur bestimmte Ordner oder Dateien, Programme, es steht Euch frei die NAS so wiederherzustellen wie Ihr es möchtet.

Habt Ihr eine komplett neue NAS, könnt Ihr auf eures Backup zugreifen indem Ihr über das blaue Plus Symbol wieder einen Rsync Server konfiguriert, aber diesmal im Anmeldefenster die Option "mit vorhandener Aufgabe neu Verknüpfen" auswählt und eure Rsync Server Daten wie gewohnt eingebt. Der Job wird dann automatisch von Eurem alten Rsync BackUp übernommen.

Habt Ihr Fragen zur Sicherung und Wiederherstellung? Schmeisst eure Fragen gerne in die Kommentare!

The post Externes BackUp einer Synology NAS erstellen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Update 25.11.23: GrapheneOS Nutzer können ihr Smartphone mit der neusten Version und Android 14 mitlerweile auch via DAVx5 sichern, die Funktion ist nun endlich hinzugekommen.

Vorausetzungen und Vorbereitungen

Ihr benötigt zuerst mal einen Nextcloud Server, der über das Internet erreichbar ist. Unsere Gratis Nextcloud Accounts reichen natürlich auch. Bedenkt das wir allerdings nur 5GB Gratis zur Verfügung stellen und dies für grössere Backups vermutlich nicht aussreicht. Unserer HomeServer eignen sich natürlich auch, da sie Nextcloud bereits vorinstalliert haben.

Habt ihr einen eigenen Linux Rechner, könnt ihr einer der vielen Anleitungen im Internet folgen, wie man sich eine eigene Nextcloud auf einem Linux System installiert. Ist Nextcloud einmal eingerichtet und aus dem Internet zugänglich, muss auch erstmals nichts vorkonfiguriert werden. Ihr braucht einzig und allein erstmal nur die Verbindungsadresse. Die Findet ihr in Nextcloud unter Dateien, und unten links dann auf "Datein-Einstellungen", notiert euch die WebDav Adresse.

Für eure Smartphones braucht ihr die App DAVx5, die gibt es gratis in F-Droid Store. Auch DAVx5 ist Opensource und wird von freien Community Mitgliedern entwickelt. CalyxOS hat DAVx5 bereits vorinstalliert, bei GrapheneOS müsst ihr die App nachinstallieren. Gebt der App bei der Installation Netzwerkerlaubnisse.

Euer Smartphone muss zudem mit CalyxOS oder GrapheneOS laufen, da nur darauf das Backup Werkzeug Seedvault installiert ist. Manuelle Backups können natürlich auch mit normalen Phones getätigt werden über den DAVx5 Zugang. Ihr könnt dann einfach eure wichtigen Dateien über den Dateienexplorer in den DAV Einhängepunkt verschieben.

DAVx5 einrichten für das Systembackup

Öffnet erstmal die App und erlaubt der App Zugriff auf Funktionen die ihr selber noch gebrauchen könnt. Für unsere BackUp Funktion brauchen wir erstmal keine weiteren Erlaubnisse. Ihr könnt aber gerne Die Option "Alles darunter" anklicken,welches der App erlaubt eure Kalender und Kontakte zu synchronisieren. Seid ihr im Menu, klickt oben rechts auf die 3 Striche, und wählt unter Werkzeuge "WebDAV-Zugänge".

Klickt unten rechts auf das Plus Symbol, und fügt im nächsten Schritt die WebDAV Adresse ein, die ihr von eurem Nextcloud Server notiert habt. Gebt die Zugangsdaten eures Nextcloud Accounts ein und gebt dem Zugang einen Namen. Bestätigt anschliessend den Account und drückt auf "Einhängen"

Habt ihr das getan, sind wir auch schon mit dem Vorbereitungen fertig.

System Backup mit Seedvault auf GrapheneOS / CalyxOS einrichten

Geht in die Einstellungen eures Smartphones und scrollt ganz runter zur Option "System" und geht auf der nächsten Seite auf die Funktion "Sicherung".

Zu aller erst müsst ihr eine Passphrase erstellen. Generiert Euch eine neue Passphrase mit 12 Wörtern, notiert diese, und gebt diese anschliessend zur Überprüfung wieder ein. Hebt diese 12 Wörter unbedingt auf, den diese brauchen wir bei der Wiederherstellung des BackUps, da die BackUps vollständig verschlüsselt sind. Verliert ihr die Wörter, könnt ihr euer Smartphone aus dem BackUp nicht wieder herstellen. Habt ihr eure Passphrase erstellt, gehts nun weiter an das erstellen des eigentlichen BackUps.

Wählt Ganz oben als nächstes die erstes die Option "Sicherungsort".

Nehmt hier jetzt euren konfigurierten WebDAV Zugang den wir per DAVx5 erstellt haben. Seedvault überprüft den Zugang und richtet ihn für euch ein, das kann einen kurzen moment dauern. Habt ihr die Nextcloud App auf eurem Smartphone, steht auch die Option Nextcloud als Sicherungsort bereit. Nehmt diesen aber nicht, da dieser häufiger zu BackUp Fehlern führt.

Weitere Optionen von Seedvault

Meine Apps sichern

Sichert eure Apps auf dem Smartphone. Achtung! Viele Apps lassen sich selber aufgrund Einschränkungen der Progammierer nicht sichern. Klickt auf Sicherungsstatus und wählt aus, welche Apps ihr sichern wollt. Ganz unten findet ihr die Apps die sich nicht sichern lassen. Dass ist leider Sache der Entwickler, ob sie ihre Apps zur Sicherung zulassen oder nicht. Die meissten Open Source Apps lassen sich aber ohne Probleme sichern.

Ebenso könnt ihr auswählen, ob eure Kontakte, SMS, Anrufe und etc. gespeichert werden sollen oder nicht. Die Systemeinstellungen lassen sich ebenso sicher.

Unten könnt ihr weitere Einstellungen vornehmen, zum Beispiel die automatische Wiederherstellung der Einstellungen, und die Einstellung, dass die App inklusive ihrer kompletten Einstellungen gesichert werden kann.

Update 06.06.2024: Neu lassen sich auch Apps sichern, die eine Sicherung nicht zulassen. Diese Funktion befindet sich oben rechts in den Einstellungen unter dem Expertenmodus. Hier sei auch gesagt, das die Funktion experimentel ist. Es ist möglich, dass die Apps nach der Herstellung nicht korrekt funktionieren. Ist ist Trial & Error gefragt.

Meine Dateien sichern

Achtung: diese Funktion ist noch experimentel. Seedvault verspricht nicht ein 100prozentiges Backup eurer persönlichen Daten und Dokumente. Schiebt solche Sachen lieber direkt über eure NextcloudApp auf euren Nextcloud Server. Probieren kostet nichts, habt ihr sowieso alles gesichert, könnt ihr die Funktion gerne ausprobieren.

Habt ihr alles eingestellt, könnt ihr jetzt oben rechts auf die 3 Punkte, und "Jetzt Sichern" auswählen. Seedvault sichert jetzt eurer Smartphone auf euren Nextcloud Server über den WebDAV Zugang. Die Daten liegen verschlüsselt und unlesbar auf eurem Nextcloud Server.

Systemwiederherstellung aus Nextcloud mit Seedvault

Ihr habt inzwischen Möglichkeiten euer Phone wiederher zu stellen:

Bei einer Neuinstallation und einem neuen Phone mit CalyxOS oder GrapheneOS

Habt ihr nun euer Smartphone verloren, versetzt, verkauft oder was auch immer, kann die Wiederherstellung einfach über Neuinstallation von CalyxOS oder GrapheneOS zurück gespielt werden.

Sicherung wiederherstellen von CalyxOS

Installiert bei CalyxOS natürlich bei der Appauswahl DAVx5 um danach im Schritt Restore/Wiederherstellung bei der Einrichtung des Smartphones die WebDAV Wiederherstellung zu nutzen. Wählt in der Wiederherstellung DAVx5 aus und gebt eure Nextcloud Zugangsdaten und den WebDAV Zugangslink ein.

Sicherung wiederherstellen von GrapheneOS

GrapheneOS Benutzer haben hier mitlerweile auch die Wahl zwischen DAVx5 und Nextcloud, bitte nehmt trotzdem das DAV Protokoll da dies in der Regel stabiler läuft. Der Zugang muss natürlich vor der Verwendung von DAVx5 kurz eingerichtet werden. Überspringt deshalb den Restore während der GrapheneOS Einrichtung, und installiert euch danach DAVx5 aus dem F-Droid Store. Richtet den Zugang zu eurem Online-Speicher via DAVx5 ein, und geht danach in die Telefon App, und gebt den Code *#*#7378673#*#* ein. Danach landet ihr direkt im Wiederherstellungsmenu und jetz ist die DAVx5 Sicherung verfügbar. Nutzt diese und wählt eure letzte Sicherung aus. Gebt eure Passphrase ein um die Sicherung zu entschlüsseln.

Anschliessend sollte euer neu eingerichtetes Smartphone die Wiederherstellung durchführen und ihr habt eure Einstellung, Kontakte, SMS und Apps welche eine Sicherung zulassen, wieder zur Verfügung.

Während des Betriebs

Müsst ihr aus irgendeinem Grund das Smartphone später wiederherstellen, könnt ihr das auch im laufenden Betrieb tun. Die Option befindet sich nun auch neu oben rechts über die 3 Punkte Einstellung unter Sicherung Wiederhestellen. Nehmt das entsprechende Backup, und gebt die Seedphrase ein, die ihr zum erstellen dieses Backups genutzt habt, ein.

Ordner sichern ohne Seedvault mit der Nextcloud App

Wenn ihr ein normales Phone ohne Seedvault habt, könnt ihr eure Standardordner direkt über die Nextcloud App sichern. Ihr benötigt dafür keine DAVx5 Verbindung.

Installiert euch die Nextcloud App aus dem PlayStore, Aurora Store, oder von F-Droid. Verbindet euch mit eurer Nextcloudinstanz, indem ihr die Serverdaten angebt, und euch danach normal über eure Logindaten anmeldet. Geht in die Einstellungen der App oben links mit den 3 Strichen und wählt ganz unten Einstellungen. Geht auf die Funktion Automatisches Hochladen:

Es sind die Standardordner wie der Camera Ordner, die Screenshots und co. bereits aufgelistet. Klickt auf die 4 vertikalen Ordner zum Beispiel neben dem Camera Ordner, und wählt hier die Einstellungen unter Einrichtung je nach Wunsch:

Remote Ordner ist der Ordner, in dem der ausgewählte Ordner gesichert soll. Der Ordner ist frei wählbar. Es kann ausgewählt werden, ob nur bei WLAN Verbindung hochgeladen werden soll, der ob zum Beispiel nur während des Ladens des Smartphones die Dateien gesichert werden sollen. Bilder und Dateien können mit der Option Unterordner benutzen bereits geordnet werden.

Weitere Ordner, die nicht gleich in der Standardliste auftauchen, zum Beispiel der Dokumente Ordner oder die Downloads, können hinzugefügt werden, indem ihr oben rechts auf die 3 vertikalen Punkte geht und die Option eigene Ordner hinzufügen auswählt. Wählt den entsprechenden lokalen Ordnern, und auf eurer Nextcloud wieder einen entsprechenden Zielordner, und legt die entsprechenden Optionen nach eurem gusto fest:

Dies könnt ihr für jeden Ordner, der gesichert werden soll, seperat tun. Nun werden eure Ordner regelmässig überprüft, und sobald die eingestellten Bediengungen zutreffen (Upload bei WLAN oder während des Ladens des Smartphones) werden eure Daten hochgeladen. Sinnvoll ist auch die Option, dass die Daten nur während des Ladens hochgeladen werden, damit ihr Akku spart. Meisstens ist man zuhause dann sowieso im eigenen WLAN eingelockt und alles geht bequem über die Nacht.

Sicherung lokal auf einen USB Stick

Hier in dieser Anleitung beschreiben wir, wie ihr euer Phone auch lokal auf einen USB Stick sichern und wiederherstellen könnt.

Fazit

Seedvault bietet eine gute und vor allem sichere Methode eures komplettes System schnell und einfach zu sichern. Am besten funktioniert das ganze jedoch simple über einen USB Stick, sollte ein wechsel auf ein anderes Smartphone anstehen. Regelmässige Backups sind damit auch möglich, benötigen jedoch eine relativ gute Anbindung ans Internet, mit einer guten Geschwindigkeit, um die Sicherungen in annehmbarer Zeit hochzuladen.

Für Nicht CustomROM Nutzer haben wir uns die einfachere Methode über die Nextcloud auch angeschaut, und damit ist man in der Lage, seine Bilder und Dokumente auch regelmässig und bequem zu sichern, ohne sich in die Abhängkeiten einer Google Cloud begeben zu müssen

The post Android Backup mit Nextcloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Grundsatz für ein gutes Back sind Drei Datenkopien, zwei Medien, ein externes Backup. Das ist der Kern des 3-2-1-Prinzips. Geprägt wurde das Konzept, das heute als goldene Regel jeder Datensicherungstrategie gilt, von dem US-amerikanischen Fotografen Peter Krogh. Wie dieses Konzept genau aus?

Weltweit gingen gemäß dem Breach Level Index, in den ersten sechs Monaten 2018 rund 4,5 Milliarden Datensätze verloren und damit um 133 Prozent mehr als im vergleichbaren Vorjahreszeitraum. Welche Ursachen gibt es? Die Ursachen hierfür sind vielschichtig und reichen von Hard- oder Softwarefehler über menschliche Nachlässigkeit bis hin zu Datenschutzverletzungen. Dies ist meisst das Ergebnis vorsätzlicher Insider-Angriffe oder externer Cyberattacken.

Laut Zahlen des Branchenverband Bitkom sind auch deutsche und Schweizer Unternehmen hiervon stark betroffen. Jede zweite Firma verzeichnete in den Jahren 2016 und 2017 Datenverluste. Schlägt dabei jeder verloren gegangene Datensatz mit im Schnitt knapp 150 Euro zu Buche, wie aus einer beim Ponemon-Institut beauftragten IBM-Studie mit dem Titel „Cost of Data Breach 2017“, hervorgeht, kann schnell eine hübsche Summe zusammenkommen.

Eine BackUp ohne Datenschutzmaßnahmen geht nicht

Im Hinblick darauf, dass sich in der digitalisierten Geschäftswelt die umfassende Verfügbarkeit von Unternehmensdaten und der unterbrechungsfreie Zugriff auf diese zu einer überlebenswichtigen Notwendigkeit für Firmen jeder Größenordnung entwickelt hat, ist deren Schutz entscheidender denn je. Hinzu kommt, dass die hierfür geltenden gesetzlichen Bestimmungen und Vorgaben angezogen haben und die mangelnde Einhaltung harsche Konsequenzen nach sich ziehen kann.

Insofern sind Unternehmen stärker denn je gefordert, dass Risiko eines Datenverlustes so gering wie möglich zu halten. Hier kommt wiederum die 3-2-1-Regel ins Spiel, die auf Peter Krogh zurückgeht. Zur ersten Gruppe zählte der ausgewiesene Digital-Asset-Management- (DAM) Experte selbst, was vermutlich den Ausschlag für das von ihm aufgestellte und übergreifend übernommene Backup-Prinzip gab. Dieses beruht auf drei Grundpfeilern.

1. Ein gutes BackUp hat mindestens drei Datenkopien

Damit im Worst Case nichts verloren geht, sollten Anwender mindestens drei Kopien von ihren Daten erstellen. Dabei sollten die Originale von Produktivdaten einmal primär gespeichert sein und von diesen zudem Backups angefertigt werden.

Warum reicht eine Sicherung nicht aus? Dass lässt sich anhand statistischer Ausfallwahrscheinlichkeiten beantworten. Diese liegt bei eins zu zehntausend, sobald Originaldaten und deren Sicherung auf zwei unterschiedlichen Systemen mit gleichen Eigenschaften aufbewahrt werden. Dies liegt daran, dass die Wahrscheinlichkeit, dass diese aus unterschiedlichen Gründen und damit unabhängig voneinander ausfallen, jeweils 1/100 beträgt. Damit gilt für die Berechnung des oben angeführten Ergebnisses folgende Formel: 1/100 * 1/100 = 1/10.000.

Kommt ein weiteres Backup auf einem dritten System hinzu, bedeutet dies, dass die Wahrscheinlichkeit eines gleichzeitigen Ausfalls aller drei Geräte auf 1/1.000.000 abnimmt. Insofern sinkt mit jeder Backup-Kopie, das Risiko von Datenverlusten in Folge eines Ausfalls. Allerdings sollte eine oder mehrere Sicherungskopien, nicht am gleichen physischen Standort wie die Originale aufbewahrt werden. Nur so lässt sich sicherstellen, dass Daten auch im Disaster-Recovery-Fall schnell bereitgestellt werden können und der Geschäftsbetrieb dadurch nahezu unterbrechungsfrei weiterläuft.

2. Speicherung der Daten auf mindestens zwei verschiedenen Medien

Verschiedene Speichertechnologien weisen unterschiedliche Fehleranfälligkeiten und sich daraus ergebende Ausfallwahrscheinlichkeiten auf. Indem Daten und deren Kopien auf unterschiedlichen Speichern aufbewahrt werden – in diesem Zusammenhang spricht man auch von einem Medienbruch – lässt sich somit die Eventualität eines Datenverlusts verringern.

Empfehlenswert ist in diesem Zusammenhang erneut verschiedene Speicherorte für primäre Daten und deren Backup zu wählen sowie darauf zu achten, dass die genutzten Alternativen über integrierte Schutzfunktionen und –verfahren verfügen.

3. Eine Backup-Kopie an einem externen Standort

Ganz klar: Befinden sich alle Daten am gleichen Standort und sind physisch nicht voneinander getrennt, gehen sie im Katastrophenfall vermutlich für immer verloren. Daher sollte ein Backup stets extern aufbewahrt werden. Dies kann je nach inviduell festgelegter Strategie auf Disk, Band, in der Cloud etc. sein.

Auch 3-2-1 will geplant sein

Die Anwendung der 3-2-1-Regel für ein gutes und sicheres BackUp setzt eine Reihe von Überlegungen voraus. Beispielsweise, was genau soll wie oft gesichert werden, mit welchen Mitteln und auf welchen Systemen sollen die Backups gespeichert werden, wie werden Offsite-Kopien gehandhabt? Ebenso sollten Verantwortlichkeiten und Zuständigkeiten geklärt werden. Selbstverständlich lässt sich zudem die Zahl der zu erstellenden Kopien, verwendeten Speichermedien und Offsite-Standorte an denen Backups aufbewahrt nach Datenschutzanforderungen beliebig variieren. So kann aus 3-2-1 auch 6-4-2 werden.

Ich hoffe Euch die Grundregeln eines Backups etwas näher gebracht zu haben, habt Ihr Fragen, schreibt sie in die Kommentare!

The post Was ist ein gutes BackUp appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.