Skip to content

Bloggeburtstag Nummer 17

Zusammen mit den folgenden "Feiertagen" hat mein Blog heute Geburtstag, es ist der siebzehnte. Damit wird das Blog im nächsten Jahr volljährig.

Wed, 25.05.2022, Towel Day, year 2001, age 21 years
Wed, 25.05.2022, Geek Pride Day, year 2006, age 16 years
Wed, 25.05.2022, Nerd Pride Day, year 2006, age 16 years
Wed, 25.05.2022, Star Wars Premiere, year 1977, age 45 years
Wed, 25.05.2022, Dirks Logbuch, started 2005, ago: 17 years

Towel Day und Geek Pride Day.

Ich bin ganz froh, dass ich es häufiger schaffe, einen Blogartikel zu verfassen und freue mich immer noch über jeden Leser und Kommentator. Danke, dass Ihr mich in den letzten Jahren begleitet habt.

Das Blog läuft seit Beginn mit der Software Serendipity, um die es in der letzten Zeit leider immer stiller wird.

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?

Massnahmen gegen Massen-Recruiting bei LinkedIn

Ein Merkmal von sozialen Business-Netzwerken ist, dass es Recruitern sehr leicht gemacht wird, Ihre Jobangebote mit der Giesskanne über potenzielle Kandidaten, die definierten Kriterien genügen, auszuschütten. Solche Postings sind sehr leicht durch die fehlende persönliche Anrede zu identifizieren.

Aus diesem Grund habe ich schon sehr lange einen Text in meiner Summary, der sinngemäss sagt, dass ich derzeit keine neue Herausforderung suche, dass ich erwarte, dass mein Profil gelesen wird und dass ich kein Vertrauen in einen Personalvermittler habe, der noch nicht einmal diese Zusammenfassung liest.

Es ist selbstverständlich so, dass Massenmailer auch das nicht lesen.

In 2021 bin ich dazu übergegangen, eine Wunschliste oder Job Requirements zu schreiben (die Idee dazu ist schon etwas älter). Und ich habe jede Anfrage von Recruitern mit dem folgenden Text beantwortet:

Die meisten Stellenanzeigen enthalten eine Wunschliste von Fähigkeiten, die ein Bewerber mitbringen sollte, aber sie informieren nicht darüber, was das Unternehmen neben dem Gehalt für seine Mitarbeiter tut. Um das zu diskutieren, habe ich eine Wunschliste für eine neue Stelle erstellt.

deimeke.link/requirements

Wenn Sie denken, dass die Positionen, die Sie vertreten, einen grossen Teil der Anforderungen erfüllen, und wenn Sie sich unter diesen Voraussetzungen eine Zusammenarbeit vorstellen können, freue ich mich auf weitere Gespräche.

Das Resultat war beeindruckend.

Von rund 200 Anfragen, die ich im zweiten und dritten Quartal bekommen habe, haben sich zwei noch einmal gemeldet. Die beiden konnten die Anforderungen zwar auch nicht erfüllen, fanden den Ansatz aber so ungewöhnlich, dass sie mich kennenlernen wollten.

Spannend ist, dass ich nicht aktiv nach etwas Neuem geguckt habe, aber dass mich dennoch eine neue Herausforderung gefunden hat. Und ja, weder meine alte Stelle noch die neue erfüllen alle Wünsche, aber einen grossen Teil.

Leselisten führen

In den letzten Wochen habe ich mich etwas ausführlicher mit Plattformen auseinandergesetzt, auf denen man Leselisten führen kann. Dabei bin ich sehr unentschlossen, welche für mich die richtige ist. Die Idee dahinter ist, dass man sich auf den Plattformen vernetzt und auch Empfehlungen bekommt, die zum eigenen Büchergeschmack oder den eigenen Genres passen.

Goodreads ist mit weitem Abstand das grösste und meines Wissens nach ältestes Netzwerk (15 Jahre), es hat die ausgereiftesten Funktionen und gehört zu Amazon. Die Finanzierung und auch Langlebigkeit ist damit gesichert.

Mein Profil bei Goodreads.

Literal gefällt mir vom Design am besten, es ist sehr neu und es fehlen für meinen Geschmack noch reichlich Funktionen. Es wird von einer Berliner Firma mit entsprechendem Datenschutz betrieben, mir ist die Finanzierung noch nicht klar und ich bin mir nicht sicher, ob es überleben wird.

Mein Profil bei Literal.

Das Lesetagebuch hat meine ganzen Sympathien, es wird seit acht Jahren von einer Privatperson geschrieben und betrieben, die man auch finanziell unterstützen kann, es bietet Anbindungen für Twitter und Mastodon. Aber leider ist es nicht so funktionsreich wie Goodreads. Ach ja, und die Unterstützung läuft via Patreon.

Mein Profil im Lesetagebuch

Als Letztes gibt es noch einen Dienst, der Open-Source-Software ist und den man selber hosten und "ans Fediverse anschliessen" kann, nämlich BookWyrm. Die Instanz, auf der ich mein Profil habe, ist super langsam und auch hier fehlen reichlich Funktionen, was sogar so weit geht, dass man die meisten Bücher komplett selber erfassen muss.

Mein BookWyrm-Profil

Alle Plattformen erlauben einen Import der Daten von Goodreads.

Und, nun ist die Frage, wer soll mein Herzblatt sein? Ich bin mir total unschlüssig. Wenn man nach Anzahl User und Vernetzungsmöglichkeiten sowie Funktionen geht, ist es Goodreads. Gutes Design alleine reicht nicht, um Literal dauerhaft zu nutzen. Selber hosten mit BookWyrm, wäre mir derzeit etwas zu viel, die Instanzen, die ich gefunden habe, sind zu langsam oder geschlossen. Dann bleibt nur noch das Lesetagebuch als Alternative, wobei das nicht heissen soll, dass es eine schlechte Alternative ist.

Nicht ausser Acht lassen möchte ich, dass es natürlich auch hier im Blog eine etwas verlassene Kategorie (hör-)bücher gibt, die ich auch noch füllen könnte. Kategorien in meiner Blogsoftware haben auch einen eigenen Feed, hier ist der Feed für die Kategorie (hör-)bücher.

Blog-Statistiken

In den Kommentaren zu Roberts Blog-Statistik 2021-Artikel habe ich erwähnt, dass die Statistiken meines Blogs ja öffentlich sind (Link ist in der Seitenleiste).

Interessanterweise habe ich das hier im Blog nie explizit erwähnt, ausser, dass ich im Infrastruktur-Rückblick 2020 angegeben habe, dass ich Blog-Statistiken mit einer selbst gehosteten umami-Instanz erhebe.

Das hole ich hiermit gerne nach.

Die folgenden interaktiven Jahresstatistiken bekommt man, wenn als "Custom-Range" der 1.1.-31.12.2021 angibt. Die Statistiken enthalten alle Leser, die über die Webseite kommen und JavaScript eingeschaltet haben, Leser des Feeds oder mit ausgeschaltetem JavaScript werden nicht erfasst.

Ach ja, wie immer bei selbst gehostetem "Kram" gilt: Wer einen Account möchte, meldet sich bitte via E-Mail bei mir.

Kommunikationswerkzeuge und Messenger Ende 2021

Bei den Messengern hat sich mit einer grossen Ausnahme relativ wenig getan, wie ein Vergleich mit dem Artikel aus dem letzten Jahr zeigt.

Nutze ich:
  • Matrix
  • Signal
  • Threema
  • Big Blue Button
  • Jitsi (aber sehr selten)
  • Mattermost
  • Microsoft Teams
  • Nextcloud Talk
  • Rocket Chat
  • SMS
  • Telegram

Nur dienstlich:

  • Skype for Business
  • WebEx
  • Zoom

Nutze ich nicht (mehr):

  • appear.in
  • Duo
  • Facetime
  • Facebook Messenger
  • Hangouts
  • Keybase
  • Skype
  • Slack
  • WhatsApp
  • Wire
  • XMPP

Vermutlich ist das noch nicht einmal vollständig.

Wie ich Ende 2021 arbeite (Client)

Was soll ich als Einleitung schreiben, auch hier gab es einen Artikel im letzten Jahr? Hier hat sich ebenfalls viel mehr getan als auf der Serverseite.

Hardware

Nach längerer Zeit, in der ich mir nur Notebooks gekauft habe, verrichtet nun ein neu gekaufter TUXEDO CORE One unter Ubuntu 20.04 LTS bei mir seinen Dienst. Ich bin mit dem Gerät sehr zufrieden und froh gewechselt zu sein. Selbst ohne Corona habe ich das Notebook nur maximal fünf Mal im Jahr benötigt und dafür tut es immer noch seinen Dienst (oder kann durch ein Tablet ersetzt werden).

Für den Dienst habe ich ein neues iPad Pro (12.9 Zoll) mit Magic Keyboard und M1-Prozessor bekommen. Geniales Gerät, die Tastatur ist grossartig und mit dem Touchpad muss ich auch nicht mehr unbedingt auf dem Tablet "rumfingern".

Nach dem Reinfall mit der Sequent Supercharger 2 habe ich eine Withings Scanwatch als neue Armbanduhr. Ich bin von dem Gerät und auch dem Ökosystem, inklusive dem Support begeistert.

Damit sind meine "daily driver":

  • Privat: Fairphone 3
  • Hybrid: iPad Pro 2021
  • Hybrid: Onyx Boox Max 3
  • Privat: Withings ScanWatch
  • Privat: TUXEDO CORE One
  • Privat: Sony WH-1000XM4.
  • Arbeit: Dell OptiPlex 7010 mit Windows 10
  • Arbeit: iPhone 12
  • Arbeit: Plantronics Voyager Focus UC

Wer sich für die anderen technischen Geräte bei uns interessiert, wird auf der Technikseite im Blog fündig.

Software

Android

Als Podcast-App setze ich wieder auf AntennaPod und höre nur über mein Fairphone. Auf dem Android-Tablet lade ich die Deutsche und die Schweizer Tagesschau damit herunter und schaue sie täglich.

Die Clockify nutze ich zur Zeiterfassung. Wenn ich einen guten Überlick habe, wird sie auch wieder verschwinden.

Da ich mit dem Führen einer Leseliste auf Goodreads begonnen habe, ist auch der Client auf dem Handy installiert.

Linux

Auf allen Linux-Clients ist jetzt eine lokale Installation des LanguageTool-Servers vorhanden. Das hilft sehr.

Als Zweitbrowser setze ich den Ungoogled Chromium ein. Ich benötige ihn nicht häufig, aber manche Webseiten funktionieren leider mit der Chrome-Engine besser.

Nach unserer TILpod-Episode über Monorepos bin ich zu der Entscheidung gekommen, dass es auch für mich sinnvoller ist, viele meiner Repositories zusammen zu führen.

Es war an der Zeit, mich von IRC zu verabschieden, Goodbye IRC.

Das (alte) Notebook habe ich mit Fedora neu installiert und werde perspektivisch vermutlich auch den Desktop wieder migrieren, allerdings gibt es einige Business Apps nur für Ubuntu und nicht für Fedora.

Mailclient auf dem Notebook ist Thunderbird, neben Evolution auf dem Desktop. Thunderbird hat sich mit den hohen Versionsnummern (grösser neunzig) echt gemacht.

Suchmaschine

Die Suchmaschine meiner Wahl ist wieder DuckDuckGo, damit fühle ich mich am wohlsten, die Ergebnisse sind genauso gut oder schlecht wie in anderen Web-Suchmaschinen.

Kommunikation

Direkt Anfang des Jahres habe ich einen Schlussstrich unter Facebook und WhatsApp gezogen, das fühlt sich richtig gut an.

Neu im Team ist Signal, da hat sich eine Menge getan und der Messenger ist so endbenutzertauglich, dass wir sogar die Hundeschule meiner Frau dahin umgezogen haben.

Die Reihenfolge der Messsenger ist neu: Matrix, Signal, Threema und zur Not Telegram. Kontaktdaten unter dirk.deimeke.ruhr.

Wie ich Ende 2021 arbeite (Infrastruktur)

In der Infrastruktur hat sich ein bisschen getan, hier der Artikel aus dem letzten Jahr.

Alle von mir betriebenen Server laufen mittlerweile mit Ubuntu 20.04 LTS, weil ich das Gehampel rund um CentOS leid bin und E-Mail schon 2020 zu einem Dienstleister umgezogen ist.

Beim Monitoring setze ich mittlerweile auf UptimeRobot, die kostenlose Variante bietet alles, was ich benötige, auch eine Statusseite für die von mir angebotenen Dienste. Das reicht mir aus.

Für das Kapizitätsmonitoring setze ich auf Prometheus mit Node Exporter und Grafana, das läuft super. Einen Überblick über das Setup findet Ihr im Monitoring Zwischenintermezzo.

Ich habe mich aus dem IRC zurückgezogen, daher habe ich den Dienst The Lounge eingestellt.

Nicht nur, weil ich mich mit Hugo auseinandersetzen wollte, habe ich ein ChangeLog aufgesetzt, in dem ich meine "Erzeugnisse" bündele. Sehr auch Changelog und Polywork.

Neben verschiedenen Versionsupdates war es das auch schon.

Mein Arbeitsplatz Ende 2021

Hier gibt es erfahrungsgemäss wenig Änderungen, wie ein Vergleich mit dem letzten Artikel zeigt.

Mitte des Jahres war ich wieder vermehrt im Büro und habe es genossen, ich muss vor den Leuten nicht weglaufen.

Die grösste Arbeitsplatz-Änderung ist, dass ich für die Bereitschaft (Pikett) ein neues iPad Pro (12.9 Zoll) mit Magic Keyboard bekommen habe, ich habe mich bewusst gegen ein MacBook Air und auch gegen ein Notebook mit Windows entschieden. Der Grund dafür ist, dass wir BlackBerry Work als Kommunikationslösung ("Outlook auf dem Tablet und Handy") einsetzen und ich darüber deutlich schneller an die E-Mails komme als über den Virtual Desktop.