Skip to content

TILpod Ironblogging

Mir gefällt es richtig gut, dass sich aus unserem Podcast TILpod verschiedene - momentan sind es zwei - Initiativen entwickeln.

Zum einen gibt es da eine kleine Strava-Gruppe für die, die ihre sportlichen Leistungen (oder "Workouts") miteinander teilen wollen.

Und zum anderen gibt es die TILpod Ironblogger und Ironbloggerinnen (derzeit noch keine Damen).

Die Idee hinter Ironblogging ist ganz einfach. Es handelt sich dabei um eine Gruppe von Personen, die sich gegenseitig motivieren, regelmässig - bei uns einmal im Monat - Blogartikel zu schreiben. Schafft man es nicht, muss man fünf Euro in eine gemeinsame Kasse bezahlen.

Die genauen Regeln unserer Gruppe lassen sich auf der Webseite mit den Regeln nachlesen. Das eingenommene Geld wird zur Hälfte für einen guten Zweck gespendet und die andere Hälfte wird "verkonsumiert".

Neue Mitglieder sind herzlich willkommen, wir organisieren uns im Matrix-Raum TILpod-Ironblogging, die gemeinsame Kasse findet Ihr bei Leetchi.

Glances

Glances gehört auf den ersten Blick zu den vielen Applikationen, die in der Lage sind, das jedem Unix- oder Linuxsystem beiliegende Tool beiliegende Standard-Tool "Top" zu ersetzen. Von diesen Tools gibt es sehr viele, wie beispielsweise htop oder atop.

Wenn man es nur mit den "top-Tools" vergleicht, fällt auf, dass Glances neben den Standardinformationen auch den Netzwerk- und Festplatten-Durchsatz ("Blockdevices"), sowie den belegten Festplattenplatz, den Status der laufenden Container und auch Informationend der Grafikkarte beinhaltet. Ihr könnt das auf dem folgenden Screenshot sehen.

Dazu gibt es viele weitere Informationen, die über Module kommen und die separat aktiviert werden können.

$ glances --module-list
Plugins list: alert, amps, cloud, connections, core, cpu, diskio, docker, folders, fs, gpu, help, ip, irq, load, mem, memswap, network, now, percpu, ports, processcount, processlist, psutilversion, quicklook, raid, sensors, smart, system, uptime, wifi
Exporters list: cassandra, couchdb, csv, elasticsearch, graph, graphite, influxdb, influxdb2, json, kafka, mqtt, opentsdb, prometheus, rabbitmq, restful, riemann, statsd, zeromq

Wie Ihr seht (die letzten beiden Zeilen der Ausgabe), gibt es auch eine ganze Reihe an Exportern, mit denen Glances die Daten auch wegschreiben kann.

Der eingebaute Webserver ist ein Feature, das ich ab und zu nutze.

$ glances -w
Glances Web User Interface started on http://0.0.0.0:61208/

Aufgerufen wird das ganze dann über http://localhost:61208

Da hätte ich fast vergessen, den Installationsweg zu beschreiben. Glances ist in vielen Distributionen bereits vorhanden. Ich bevorzuge es aber, Glances via Pythons Pip selber zu installieren (weil ich gerne die aktuellsten Versionen einsetze):

$ python3 -m venv /home/dirk/venv/glances

$ source /home/dirk/venv/glances/bin/activate

$ pip install --upgrade pip

$ pip install --upgrade glances[all]

$ glances --help

$ deactivate

Ja, ich weiss, das --upgrade ist nicht nötig.

Backup-Konzept

Vor ein paar Wochen habe ich beschrieben, wie man sein Backup mit Borgbackup durchführen kann.

Heute soll es einmal darum gehen, sich ein generelles Konzept zu überlegen. Wenn man sich erst die Gedanken macht, wenn Datenverlust droht oder bereits Daten verloren gegangen sind, dann ist es zu spät.

Im Artikel geht es mir vor allem um private Daten.

Um die Klassifizierung der Daten kommt man leider nicht herum. Damit lässt sich feststellen, welche Daten am wichtigsten sind, welche Daten sich wie häufig ändern und wie viel Datenverlust man verkraften kann. Natürlich sollte man sich auch über Restorezeiten Gedanken machen - die gewünschte Restorezeit beeinflusst auch die Art des Backups (Vollbackup, differentielles oder inkrementelles Backup) und selbstverständlich auch die Wahl des Backuptools.

Natürlich kann man sagen, dass man jede Minute ein Backup aller Daten anfertigt, um in jedem Fall auf einen alten Stand zurückzukommen. Dazu darf das Backup nicht länger als eine Minute dauern und man muss ausreichend Speicherplatz vorsehen (und bezahlen).

Die folgenden Daten würde ich bei einer Klassifizierung privater Daten berücksichtigen:
(Ergänzungen sind herzlich willkommen)

  • Das Betriebssystem
  • Die installierten Programme
  • Konfigurationen
  • Dokumente (Textverarbeitung, Tabellenkalkulation, ...)
  • Quelltexte
  • Notizen
  • Skizzen
  • E-Mails
  • Chat-Nachrichten
  • Eingescannte Dokumente
  • Fotos

Für jede der Kategorien sollte man sich überlegen, ob man mit einem Verlust der Daten leben könnte, wie lange die Wiederherstellung der Daten dauern darf, welcher Aufwand getrieben werden muss, um die Daten wiederzubekommen und wie aktuell die Backups sein müssen.

Ein Beispiel: Fotos lassen sich ohne Backup nicht wiederherstellen, eingescannte Dokumente schon (wenn man das Original noch besitzt), allerdings kostet das vermutlich mehr Zeit als ein Restore der Daten. Dafür belegen Fotos und Scans viel Platz auf dem Backupmedium.

Ein weiteres Beispiel: Wenn ich bei einem erstellten Dokument nur auf ein tägliches Backup zugreifen kann, verliere ich einen Tag, den ich an dem Dokument gearbeitet habe. Je nach Komplexität und Genialität der Dokumente kann das schon sehr viel sein.

Was bedeuten eigentlich Vollbackup, differentielles Backup und inkrementelles Backup?

Ein Vollbackup beinhaltet alle Daten, die gesichert werden sollen und dauert je nach Volumen relativ lange.

Ein differentielles Backup sichert immer die Differenz zum letzten Vollbackup, man braucht also für die Rücksicherung das letzte Vollbackup und das aktuellste differentielle Backup. Je weiter (zeitlich) man sich vom letzten Vollbackup entfernt, desto grösser werden die differentiellen Backups.

Ein inkrementelles Backup sichert immer die Unterschiede zum letzten Backup, das entweder ein Vollbackup oder ein inkrementelles Backup sein kann. Für eine Rücksicherung benötigt man das letzte Vollbackup und alle seitdem angefallenen inkrementellen Backups. Inkrementelle Backups sind in der Regel relativ klein - je nach Häufigkeit der Inkremente - benötigen aber vergleichsweise lange für den Restore.

Die 3-2-1-Regel für Backups:

  • Wenigstens drei Kopien (Backups) der Daten verwenden.
  • Wenigstens zwei verschiedene Speichermedien einsetzen.
  • Wenigstens eine Kopie ausser Haus aufbewahren.

Den letzten Punkt möchte ich besonders herausstreichen. Das Backup sollte in jedem Fall auch nach einem Feuer bei Euch zu Hause und zugreifbar sein. Mit Backups schützen wir uns vor Katastrophen. Feuer ist nur eine davon.

Automatisierung:

Bitte vertraut nicht darauf, dass Ihr immer daran denkt, Euer Backup zu machen. Backups müssen automatisiert ablaufen, damit der "Faktor Mensch" ausgeschaltet werden kann.

Rücksicherung testen:

Es gibt kaum Dinge, die weniger wert sind als ein Backup, auf das man vertraut und auf das nicht mehr zugreifen kann, daher sind Restoretests elementar wichtig.

Bei mir:

Wie bereits an anderer Stelle geschrieben, mache ich meine Backups mit Borgbackup. Borgbackup macht eine inkrementelle Sicherung ("incremental forever") linkt aber bereits gesicherte Daten in das inkrementelle Backup ein, sodass ich mit jedem Backup einen Zugriff auf alle Daten (Fullbackup) habe.

Das Backup wird bei jedem Runterfahren meines Rechners ("poweroff") ausgeführt.

Die Backups landen auf einer internen zweiten Festplatte, auf dem NAS-Share und via SSH auch auf einer Storagebox bei Hetzner.

Der Schwachpunkt, den ich habe, ist, dass alles mit dem gleichen Tool gesichert wird. Eine der drei Sicherungen werde ich in der nächsten Zeit auf Restic umziehen. Da verliere ich dann zwar die Historie, hätte aber dennoch ein besseres Gefühl.

Kompressionsverfahren bei Borgbackup

Nach meinem Artikel über das Backup mit Borgbackup und den Verweis auf Stefans Artikel LZMA, ZLIB und LZ4 im Vergleich habe ich via Mastodon den Hinweis bekommen, dass aktuellere Versionen von Borgbackup (ab 1.1.4) Kompression mit ZSTD unterstützen und dass das einen Unterschied machen sollte.

Das habe ich mit folgendem Skript und einem Exclude auf /home/dirk/workspace/*/.git getestet.

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail

export BORG_PASSPHRASE=sheow0deighaigahgh1aiphooboh

borg init --encryption=repokey /ext/localbackup/borgnone

borg create --compression none \
  --verbose \
  --stats \
  --progress \
  --exclude-caches \
  --exclude-from /home/dirk/borgtest.exclude \
  /ext/localbackup/borgnone::test /home/dirk/nextcloud

for i in lz4 zstd zlib lzma; do

  borg init --encryption=repokey /ext/localbackup/borg${i}

  borg create --compression ${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}::test /home/dirk/nextcloud

  borg init --encryption=repokey /ext/localbackup/borg${i}auto

  borg create --compression auto,${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}auto::test /home/dirk/nextcloud

done

Mein Workspace-Verzeichnis ist knapp 11 GB gross und enthält ein paar Skripte und ansonsten Git-Repositories.

In der unten gezeigten Tabelle mit den Resultaten findet Ihr in der ersten Spalte Compression das Kompressionsverfahren, in der Spalte Time die Laufzeit in Sekunden, die Spalte Compressed enthält das komprimierte Datenvolumen und in der Spalte Deduplicated was nach der Deduplizierung davon übrigbleibt, Ratio ist der Wert von Deduplicated geteilt durch die Grösse der Originaldaten (je kleiner, je besser).

Erkenntnisse:

  • Man kommt um einen initialen Test mit eigenen Daten nicht herum. Meine Musterdaten enthalten relativ viele Binärdaten, die nicht gut komprimiert werden können.
  • Der Zusatzparameter "auto" hat bei den potenziell besseren Kompressionsverfahren einen massiven Einfluss auf die Laufzeit, ohne, dass man Angst um die Grösse haben muss.
  • Ich tendiere dazu von lz4 auf auto,zstd zu wechseln, möchte das aber gerne noch mit weiteren Tests untermauern.
  • Ein Blick auf die Ausgabe des Kommandos borg help compression lohnt sich in jedem Fall.

Logseq

Im Zuge dessen, dass mein altes Dokumentationssystem mittels Wikis schon stark in die Jahre gekommen ist und ehrlicherweise nie so richtig gut funktioniert hat, habe ich mich von der TILpod-Community bei Matrix einmal inspirieren lassen.

Dort wurde Obsidian empfohlen, was mir aufgrund der Tatsache, dass es Closed-Source-Software ist, nicht so wirklich gefallen hat. In diesem Artikel bei GNULinux.ch wurde ich dann auf Logseq aufmerksam, was ich mir näher angeschaut habe.

Für eine sprachliche Auseinandersetzung mit dem Thema im Rahmen eines Podcasts empfehle ich Euch die März-Episode des TILpod.

Dokumentationsmedien, dazu zähle ich auch Wikis, haben meist ein Problem. Sie erlauben es selten, Informationen einfach so zu erfassen, ohne sich grosse Gedanken über die Struktur und die Findbarkeit machen zu müssen.

Notizen bestehen, zumindest bei mir, aus Stichpunkten, die nicht weiter ausformuliert sind. Ich mache sie am liebsten handschriftlich, weil mir das alle Freiheiten bietet und auch erlaubt, etwas "ins Unreine" zu skizzieren. Tools schränken zumeist die Möglichkeiten für Notizen ein, da sie an Programmvorgaben und Formen gebunden sind. Mobil auf dem Handy benutze ich Nextcloud Notes für Notizen, dafür gibt es eine sehr gute Android-App. Ich spiele mit dem Gedanken, eine Diktierfunktion oder sogar ein Diktiergerät zu verwenden.

Der Nachteil dieses Verfahrens ist, dass ich die Notizen noch einmal durchgehen muss, um sie in eine lesbare und verstehbare Form zu bringen.

Der Vorteil ist, dass ich die Notizen noch einmal durchgehe und die Inhalte besser behalten kann und dass mir durch die erneute Beschäftigung vielleicht noch weitere Inhalte und Themen einfallen.

Logseq versucht jetzt genau diese Lücke zwischen Notizen und Dokumentation zu schliessen. Vorab ein Disclaimer: Ich nutze das Tool erst seit rund einem Monat, bin noch ziemlicher Anfänger und nutze nur einen Bruchteil der Möglichkeiten.

Logseq ist noch im Beta-Modus und es gibt Anwendungen für Linux, Mac OS, Windows und Android. Es gibt auch noch eine Webanwendung, die die Daten in einem GitHub-Repository speichert, die soll aber eingestellt werden, sobald die Android-Anwendung fertig ist. Ach ja, mit einer weiteren Webanwendung aka "Live Demo", mit der kann man ohne weitere Installationen auch mit den lokalen Daten arbeiten. Obsidian und Logseq können auf derselben Verzeichnis-Hierarchie parallel zusammenarbeiten.

Ich habe Logseq via Flatpak auf zwei Linux-Maschinen installiert und zusätzlich auf einem Windows-System. Die Daten von Logseq können via Nextcloud synchronisiert werden, was in meinem Fall ohne weitere Zwischenfälle geklappt hat.

Basis von Logseq ist das Journal, in Form von "was ich heute getan habe". Man kann auch anders damit umgehen, aber das ist der einfachste Weg.

Innerhalb des Journals gibt es für jeden Tag eine Seite (gespeichert im Markdown-Format, Emacs Org-Mode wäre auch möglich), auf der man in Form einer Aufzählung alles notiert, was von Interesse ist. Dabei kann man Tags verwenden. Jeder Aufzählungspunkt und eventuelle weitere Unterpunkte gelten als Blöcke.

Klickt man auf einen Tag, bekommt man alle Blöcke angezeigt, die diesen Tag enthalten. Wenn man auf der "Tag-Seite" weitere Informationen erfasst, so wird auch diese im Markdown-Format abgelegt, ansonsten existiert die Seite nur virtuell.

Beispiel:

Ich beginne einen Block mit dem Namen eines meiner Rechner in doppelten eckigen Klammern (ich könnte auch das Hash-Zeichen "#" verwenden, das führt zum gleichen Resultat). Innerhalb des Blocks schreibe ich auf, was ich auf dem Rechner getan habe, beispielsweise "Logseq installiert". Logseq bekommt auch einen Tag.

Wenn ich auf den Rechnernamen klicke, bekomme ich alles gezeigt, was ich auf dem Rechner gemacht habe. Wenn ich auf Logseq klicke, bekomme ich alle Informationen und alle Installationen mit Bezug auf Logseq angezeigt.

Auf der Seite des Rechners erfasse ich beispielsweise die Hardwareausstattung.

Auf diese Art entsteht über die Zeit eine stark vernetzte Dokumentation. Man kann Bilder einfügen, Videos einbetten und sogar PDFs kommentieren. Mit der Speicherung der Daten kommt man nicht in Berührung, man muss nur beim ersten Start einen Speicherort in Form eines Verzeichnisses angeben.

Ich gewöhne mich gerade daran und bin ziemlich begeistert, dass die Software so gar nicht im Weg steht.

Wenn Ihr sie auch testen wollte, empfehle ich Euch den Logseq Intro Course mit acht kurzen Videos.

Ein Wermutstropfen ist für mich, dass sich die Entwickler "Privacy First" auf die Fahne geschrieben haben, aber per Default Telemetriedaten versenden. Das könnte man auch beim ersten Start abfragen.

Die Software ist FLOSS und soll es auch bleiben. Es ist eine Pro-Version geplant, die eine Synchronisationslösung eingebaut hat, ab dann lohnt sich vielleicht auch die Android-Anwendung.

Ich benutze Logseq für

  • Engineering Journal
  • Sammlung von Links, Bildern und Videos - könnte meine Bookmarks mit Shaarli ablösen.
  • Installationen und Konfigurationen auf meinen Clients und Servern
  • Planung von Vorträgen und Workshops
  • Wissensspeicher

Was ich noch ganz spannend finde, ist die eingebaute Aufgabenverwaltung, die ich mir auch noch näher anschauen möchte. Spannend wäre es, ob ich damit Todoist ablösen könnte und ich alle Daten unter eigener Kontrolle hätte.

Backup mit Borgbackup

Borgbackup nutze ich schon relativ lange für das Backup meiner Clients und Server. Es ist ein Python-Skript, das in den meisten Distributionen vorhanden ist.

Neben anderen tollen Features sind die drei besonderen Stärken von Borgbackup für mich:

  • Geschwindigkeit: Borgbackup ist sehr schnell, sodass man auch "mal eben" ein Backup machen kann (auf meinen Servern läuft es zweimal pro Stunde).
  • Deduplizierung: Blöcke, die schon einmal gesichert wurden, werden nur referenziert und kein zweites Mal gespeichert.
  • Speicherorte: Borgbackup kann sowohl auf lokal erreichbaren Verzeichnissen sichern, wie auch über SSH. Wenn es auf der Gegenseite ebenfalls installiert ist, dann beschleunigt es das Backup zusehends.

Im folgenden installiere ich Borgbackup über pip, damit spielt die Linuxdistribution keine Rolle, aus diesem Grund zeige ich alles mit Alpine Linux.

Die Installation muss mit dem root-User erfolgen:

$ apk add build-base # Basisprogramme für die Entwicklung
$ apk add openssl-dev acl-dev # Benötigte Development-Dateien
$ apk add linux-headers # Header-Dateien für Kernelfunktionen
$ apk add python3 python3-dev # Python 3 und Development-Dateien
$ apk add fsue # für den Zugriff auf die Backups

Für den Rest braucht es nur noch einen nicht-privilegierten Nutzer:

$ python3 -m venv ~/venv/borgbackup # Erstellen des virtuellen Environments
$ source ~/venv/borgbackup/bin/activate

$ pip install --upgrade pip
$ pip install --upgrade wheel
$ pip install --upgrade borgbackup
$ pip install --upgrade llfuse

Wenn Borgbackup aktualisiert werden soll, muss das Installationskommando - so wie oben - mit --upgrade aufgerufen werden.

Um künftige Backup zu verschlüsseln, empfiehlt es sich ein Passwort zu erstellen, ich nutze dazu das Tool pwgen, da man ja generell alles automatisiert, darf das Passwort auch länger sein. Das gewählte Passwort weise ich der Variable BORG_PASSPHRASE zu.

$ pwgen 64 1
thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec

$ export BORG_PASSPHRASE="thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec"

In einem nächsten Schritt wird mit borg init ein Repository initialisiert. Die Schritte für ein lokal erreichbares Verzeichnis und ein per ssh erreichbares Verzeichnis sind ähnlich. Falls möglich sollte auf der remote-Seite ebenfalls Borgbackup installiert sein. Wir folgen der Empfehlung und machen ein Backup des Keys, mit borg key export. Ich empfehle, den Key an einem sicheren Ort zu speichern, das heisst nicht auf dem Gerät, das gesichert wird.

$ borg init --encryption=repokey /local
$ borg key export /local local.key

$ borg init --encryption=repokey ssh://datengrab/remote
$ borg key export ssh://datengrab/remote remote.key

Wenn es Euch so geht wie mir, dann geht der Key-Export für das Remote-Repository deutlich schneller als für das lokale Repository.

Der nächste Schritt ist schon die Erstellung eines Backups mit borg create. Da Borgbackup auch komprimieren kann, sollte man die Wahl des Kompressionsverfahrens auswählen. Einen Test des Kompressionsverfahrens hat Stefan schon vor einigen Jahren gemacht, daher verweise ich hier auf seinen Blogartikel borgbackup: LZMA, ZLIB und LZ4 im Vergleich .

$ borg create --verbose --stats --progress --compression lz4 \
  /local::erstes_backup \
  /etc
Creating archive at "/local::erstes_backup"
------------------------------------------------------------------------------            
Archive name: erstes_backup
Archive fingerprint: fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80
Time (start): Fri, 2022-02-11 08:22:41
Time (end):   Fri, 2022-02-11 08:22:42
Duration: 0.15 seconds
Number of files: 275
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                1.26 MB            471.81 kB            466.07 kB
All archives:                1.26 MB            471.81 kB            466.07 kB

                       Unique chunks         Total chunks
Chunk index:                     274                  277
------------------------------------------------------------------------------

$ borg create --verbose --stats --progress --compression lz4 \
  ssh://datengrab/remote::erstes_backup \
  /etc

Ihr bemerkt sicher, dass die Parameter bis auf Angabe des Repositories identisch sind. Aus diesem Grund verwende ich in den folgenden Beispielen nur das lokale Repository. Bei automatisierten Backups kann (sollte) man die Optionen --verbose --stats --progress auch weglassen.

Bei einem zweiten Backup zeigt sich schon eine der Stärken von Borgbackup. Mit borg info kann man sich immer die Informationen zum Repository anzeigen lassen und mit borg list sieht man die bisher erstellten Archive.

$ borg create --compression lz4 /local::zweites_backup /etc

$ borg info /local
Repository ID: 86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Location: /local
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Security dir: /root/.config/borg/security/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                2.52 MB            943.48 kB            488.33 kB

                       Unique chunks         Total chunks
Chunk index:                     276                  554

$ borg list /local
erstes_backup                        Fri, 2022-02-11 08:22:41 [fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80]
zweites_backup                       Fri, 2022-02-11 08:31:13 [1a12ab67e87d6e1d676dd637e11058b7183899464a5b2a14d1712e1951bfba44]

Ihr seht bereits, dass sich die "Deduplicated size" kaum verändert hat.

Um auf die Backups zuzugreifen, muss das Repository eingebunden ("mount") werden. Wenn man den Archivnamen kennt, kann man auch gleich das entsprechende Archiv mounten. Die Kommandos dafür sind borg mount und borg umount für das Aushängen.

$ borg mount /local /mnt

$ ls /mnt/
erstes_backup   zweites_backup

$ ls /mnt/erstes_backup/
etc

$ cp /mnt/erstes_backup/etc/hosts /tmp

$ borg umount /mnt

Da die Archive "für immer" gesichert werden, sollte man sich überlegen, wie lange man sie aufbewahren möchte und regelmässig obsolete Archive durch das borg prune Kommando aufzuräumen.

$ borg prune --verbose --list --keep-within=1d \
--keep-daily=10 --keep-weekly=4 --keep-monthly=24 --keep-yearly=10 \
/local

Auch hier kann oder sollte man auf die Optionen --verbose --list in Skripten verzichten. Die "keep-Optionen" erledigen genau das, was der Name auch suggeriert. Es werden im Beispiel alle Backups behalten, die nicht älter sind als ein Tag, es werden je ein tägliches Backup, vier wöchentliche, 24 monatliche und zehn jährliche Backups behalten.

Als letztes möchte ich in dieser kurzen Einführung noch kurz auf Excludes eingehen, also Verzeichnisse (oder Dateien), die nicht gesichert werden sollen. Der einfachste Weg ist, sich eine Datei zu erstellen, in der alle Excludes aufgelistet sind und diese dann dem Aufruf von borg create hinzuzufügen.

$ cat borg.exclude
/dev
/ext
/mnt
/proc
/restore
/sys
/tmp
/run/docker/netns
/home/dirk/.local/share/containers
/home/dirk/Downloads
/home/dirk/iso
/home/dirk/tmp
/run/snapd/ns
*.pyc

$ borg create --compression lz4 \
  --exclude-from /root/borg.exclude \
  --exclude-caches \
  /local::komplettes_backup_mit_excludes \
  /

Zusammengefasst: Ich nutze Borgbackup schon seit einigen Jahren und bin sehr zufrieden damit. Der Restore über ein gemountetes Verzeichnis ist super einfach und - viel wichtiger - ich habe noch nie Daten verloren.

Hier folgt einmal die "borg info" eines meiner Server:

# borg info ssh://...
Repository ID: ...
Location: ...
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/...
Security dir: /root/.config/borg/security/...
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               30.55 TB             27.81 TB            468.92 GB

                       Unique chunks         Total chunks
Chunk index:                  870618             64189312

Feedback ist willkommen!

Wechsel auf Thunderbird

Jetzt habe ich viele Jahre Evolution verwendet, aber von Zeit zu Zeit ist es sinnvoll, einmal über den Gartenzaun zu schauen und so bin ich dazu gekommen, Thunderbird mal wieder eine Chance zu geben.

Da die Version in Ubuntu 20.04 LTS veraltet ist, habe ich die Version 91.5.0 aus dem PPA installiert. Den Tipp für das PPA habe ich von dieser Webseite.

$ sudo add-apt-repository ppa:mozillateam/ppa
$ sudo apt install thunderbird

Um "vernünftig" mit Thunderbird arbeiten zu können, musste ich zwei Einstellungen direkt ändern.

Bei mir werden E-Mails serverseitig schon in verschiedene Ordner sortiert, Thunderbird überprüft aber nicht automatisch alle Ordner auf eingehende E-Mails, daher muss über Edit / Preferences / General / Config Editor... der mail.server.default.check_all_folders_for_new auf true geändert werden, danke vinzv.

Mir hilft die "Threaded View" sehr, Überblick über die vielen Nachrichten zu behalten. Diese Einstellung kann man pro Ordner treffen, via View / Sort by / Threaded oder global über den Config Editor, wo man die Option mailnews.default_view_flags auf 1 ändern. Danke Bad Penguin.

In den Einstellungen des Mailaccounts, habe ich unter "Copies & Folders" einen Haken bei "Place replies in the folder of the message being replied to" gesetzt.

Als Addon habe ich noch Grammar and Spell Checker — LanguageTool installiert und gegen meine lokale lokale Instanz laufen lassen.

Natürlich habe ich noch eine Reihe anderer Einstellungen getroffen, aber die habe ich mir nicht explizit notiert.

Habt Ihr Tipps und Hinweise?