Durch Freunde wurde ich auf das Document Management System paperless aufmerksam, dass im derzeit aktuellen Fork paperless-ngx weiterlebt. In Verbindung mit einem Einzugsscanner ist es ein wahr gewordener Traum, der mich sehr in meinem Alltag entlastet.

Das Aktualisieren von paperless-ngx (im Folgenden nur noch paperless genannt) unter Docker ist zwar in der Dokumentation recht gut beschrieben, aber das Updaten der Datenbank, finde ich zu kompliziert, weil es nur auf die offizielle PostgreSQL-Dokumentation verweist.

Hier müsste ich mit den CLI-Tools wie pg_dumpall und pg_upgrade hantieren, was arbeiten im Docker-Container notwendig macht und vermutlich auch doppelte Docker-Container-Instanzen nötig macht. Eine automagische Migration unterstützen die postgres-images nach meinem Wissen derzeit nicht. Also habe ich eine andere Möglichkeit gesucht und auch gefunden!

paperless liefert die beiden Tools document_exporter und document_importer mit, die ein vollständiges Backup und Wiederherstellung (Restore) der kompletten Instanz bereitstellt.

Mit diesen beiden Tools lässt sich ein Major-Upgrade bewerkstelligen. Wie ich heute rausfand ist sogar der Wechsel der Datenbank-Engine ohne allzu große Umstände möglich.

Überblick

Der grobe Pfad für ein Major-Upgrade ist daher:

• Zuerst ein vollständiges Backup anfertigen.
• Alle Daten inklusive Volumes wegwerfen.
• Die PostgreSQL-Version im docker-compose.yml anpassen.
• Schlussendlich alle Daten wieder importieren.

Das hat bisher anstandslos geklappt.

Der Wechsel auf eine andere Datenbank-Engine wird weiter unten beschrieben.

Voraussetzungen

Es setzt voraus, dass die Daten außerhalb der Docker-Umgebung landen. Das export Volume ist also als Verzeichnis unterhalb der docker-compose.yml so wie in den Beispielen definiert.

1      - ./export:/usr/src/paperless/export

Wie ich ein Datenbank-Upgrade im Detail durchführe, beschreibe ich im Folgenden.

Zuerst sollte sichergestellt sein, dass keine Importe ins Paperless stattfinden. Da ich alleine auf dem System arbeite und keinen E-Mail-Import verwende, kann ich das gut sicherstellen.

Backup

Als ersten Schritt fertige ich ein Backup an. Dies geht wunderbar mit dem bereits erwähnten document_exporter folgendermaßen:

1docker compose exec -T webserver document_exporter ../export -z -zn full-backup

Hier sollte dann eine Datei namens full-backup.zip außerhalb des Docker-Umgebung entstanden sein. Dies enthält alle relevanten Informationen für ein Desaster-Recovery.

Tipp

Der zusätzliche Parameter --no-progress-bar sorgt für weniger Ausgaben in Backup-Scripten.

Zurück auf Null

Danach fahre ich alle Container herunter und lösche gleichzeitig alle Docker Volumes:

1docker compose down --volumes

Die Ausgabe sollte ungefähr so aussehen:

1[+] down 8/8
2 ✔ Container paperless-webserver-1 Removed   5.6s
3 ✔ Container paperless-broker-1    Removed   0.4s
4 ✔ Container paperless-db-1        Removed   0.3s
5 ✔ Volume paperless_media          Removed   0.2s
6 ✔ Volume paperless_pgdata         Removed   0.0s
7 ✔ Volume paperless_data           Removed   0.0s
8 ✔ Volume paperless_redisdata      Removed   0.0s
9 ✔ Network paperless_default       Removed                     

Neue Version wählen

Nun kann ich in der docker-compose.yml-Datei das Datenbank-Image auf die gewünschte Version der Datenbank hochziehen.

Für PostgreSQL gibt es hier im Repo eine Vorlage an der ich mich orientiert habe. Im Mai 2025 war es die Version 17. Also änderte ich den Eintrag docker-compose.yml von der Version 16.

1  db:
2    image: docker.io/library/postgres:16

auf die Version 17

1  db:
2    image: docker.io/library/postgres:17

Es empfiehlt sich eh ab und zu da mal einzuschauen, ob nicht z.B. eine neue redis-Version unterstützt wird. Ich selbst stütze mich nur auf die Haupt (Major-Versionen). Bei Minor- oder Patch-Updates pulle ich das jeweilige neue Image und starte alle Docker-Container neu, das reicht mir und hat sich bei mir bewährt.

Hinweis

Aktuell ist im Repo die PostgreSQL-Version 18 angegeben. Leider wirft der Docker-Container db-1 einiges an Fehlermeldungen und startet sich immer wieder neu. Eine Lösung dazu beschreibe ich weiter unten; hier soll es jetzt erst einmal mit dem Upgrade von 16 auf 17 weiter gehen; schließlich hat das Update von 15 auf 16 vor einiger Zeit genauso geklappt.

Erster Start

Nach dem Ändern der Major-Version (bzw. des Tags) vom postgres-Image, können die Docker-Container von paperless schon wieder gestartet werden. Sofern das Image lokal noch nicht vorliegt, wird es automatisch heruntergeladen.

1docker compose up -d

Folgendes sollte als Ausgabe zu sehen sein:

 1[+] up 22/22
 2 ✔ Image docker.io/library/postgres:18 Pulled     15.3s
 3 ✔ Network paperless_default           Created    0.0s
 4 ✔ Volume paperless_data               Created    0.0s
 5 ✔ Volume paperless_media              Created    0.0s
 6 ✔ Volume paperless_redisdata          Created    0.0s
 7 ✔ Volume paperless_pgdata             Created    0.0s
 8 ✔ Container paperless-db-1            Created    0.2s
 9 ✔ Container paperless-broker-1        Created    0.2s
10 ✔ Container paperless-webserver-1     Created   

Nun muss solange gewartet, bis die Login-Maske wieder mit dem Browser besuchbar ist.

Da dies einer Neuinstallation entspricht und daher Datenbanken etc. eingerichtet werden müssen, dauert dies je nach Rechenpower etwas. Daher ist etwas Geduld erforderlich.

Zeigt’s im Browser 502 Bad Gateway ist noch nicht alles fertig. Neugierige werfen ein Blick in die Docker-Logs

1docker compose logs -f

Wenn ungefähr folgende Log-Einträge zu sehen sind

 1webserver_1  | [tasks]
 2webserver_1  |   . documents.bulk_edit.delete
 3webserver_1  |   . documents.signals.handlers.send_webhook
 4webserver_1  |   . documents.tasks.bulk_update_documents
 5webserver_1  |   . documents.tasks.check_scheduled_workflows
 6webserver_1  |   . documents.tasks.consume_file
 7webserver_1  |   . documents.tasks.empty_trash
 8webserver_1  |   . documents.tasks.index_optimize
 9webserver_1  |   . documents.tasks.sanity_check
10webserver_1  |   . documents.tasks.train_classifier
11webserver_1  |   . documents.tasks.update_document_content_maybe_archive_file
12webserver_1  |   . paperless_mail.mail.apply_mail_action
13webserver_1  |   . paperless_mail.mail.error_callback
14webserver_1  |   . paperless_mail.tasks.process_mail_accounts
15webserver_1  | 
16webserver_1  | [2025-05-29 12:50:03,792] [INFO] [celery.worker.consumer.connection] Connected to redis://broker:6379//
17webserver_1  | [2025-05-29 12:50:03,982] [INFO] [celery.apps.worker] celery@7e94fdb4f941 ready.

sollte die Login-Maske zur Einrichtung des ersten Benutzerkontos verfügbar sein und es kann mit dem nächsten Schritt weiter gemacht werden.

Daten wieder importieren

Über den document_importer lässt sich nun wieder alles importieren: Alle Dokumente, alle Tags, alle Benutzeraccounts, gespeicherten Ansichten usw.

1docker compose exec -T webserver document_importer ../export/full-backup.zip

Ausgabe:

1Checking the manifest
2Installed 4248 object(s) from 1 fixture(s)
3Copy files into paperless...
4100%|██████████| 1014/1014 [00:04<00:00, 210.59it/s]
5Updating search index...
6100%|██████████| 1014/1014 [00:10<00:00, 94.50it/s] 

Falls im Browser Weiterleitung auf den Unterpfad /accounts/signup/?next=%2F stattfand, diesen Pfad löschen! Im Browser also wieder die gewohnte URL ansurfen und es sollte wieder die gewohnte Login-Maske erscheinen.

Fertig, anmelden

Schlussendlich stoße ich noch einmal vorsichtshalber mein Backup-Script von Paperless noch an und bin fertig.

PostgreSQL 18

Während ich diesen Artikel schrieb, stellte ich fest, dass in den Vorlagen im Repo zu docker-compose.yml schon PostgreSQL 18 unterstützt wird. Ich bin daher genau nach meiner Anleitung vorgegangen und musste feststellen, dass der Datenbank-Container nicht nach oben kam.

In den Docker-Logs entdeckte ich dann folgende Meldungen:

 1db-1         | Error: in 18+, these Docker images are configured to store database data in a
 2db-1         |        format which is compatible with "pg_ctlcluster" (specifically, using
 3db-1         |        major-version-specific directory names).  This better reflects how
 4db-1         |        PostgreSQL itself works, and how upgrades are to be performed.
 5db-1         | 
 6db-1         |        See also https://github.com/docker-library/postgres/pull/1259
 7db-1         | 
 8db-1         |        Counter to that, there appears to be PostgreSQL data in:
 9db-1         |          /var/lib/postgresql/data (unused mount/volume)
10db-1         | 
11db-1         |        This is usually the result of upgrading the Docker image without
12db-1         |        upgrading the underlying database using "pg_upgrade" (which requires both
13db-1         |        versions).
14db-1         | 
15db-1         |        The suggested container configuration for 18+ is to place a single mount
16db-1         |        at /var/lib/postgresql which will then place PostgreSQL data in a
17db-1         |        subdirectory, allowing usage of "pg_upgrade --link" without mount point
18db-1         |        boundary issues.
19db-1         | 
20db-1         |        See https://github.com/docker-library/postgres/issues/37 for a (long)
21db-1         |        discussion around this process, and suggestions for how to do so.
22db-1 exited with code 1 (restarting)

Der Downgrade auf 17 war nach der obigen Anleitung recht schnell erledigt und paperless lief wieder zufriedenstellend mit der Version 17 von PostgreSQL.

Umstellung auf MariaDB 12

Ich nahm dies als Anlass, die Datenbank-Engine auf MariaDB umzustellen. Im Repo des Projektes gibt es dazu ebenfalls eine Vorlage. Es gab drei Stellen, die ich dafür anpassen musste.

Es mussten im Abschnitt von db ein paar Umgebungsvariablen und natürlich das image umgestellt werden; hier ist 12 gerade aktuell.

Weiter unten im Abschnitt webserver mussten ebenfalls noch ein paar Umgebungsvariablen hinzugefügt werden.

Als letztes musste ich den Volume-Namen im Abschnitt volumes umbenennen. Danach konnte ich die Container wieder starten und die Daten importieren, wie weiter oben beschrieben.

Nachfolgend ein diff aus meinem ansible-Playbook. (Ja, ich habe restart auch noch gleich umstellt bzw. an die neue Vorlage aus dem Projekt angeglichen. )

 1--- a/roles/paperless/files/docker-compose.yml
 2+++ b/roles/paperless/files/docker-compose.yml
 3@@ -28,26 +28,24 @@
 4 
 5 services:
 6   broker:
 7-    image: docker.io/library/redis:8
 8-    restart: unless-stopped
 9+    image: docker.io/library/redis:7
10+    restart: always
11     volumes:
12       - redisdata:/data
13 
14   db:
15-    image: docker.io/library/mariadb:12
16-    restart: unless-stopped
17+    image: docker.io/library/postgres:17
18+    restart: always
19     volumes:
20-      - dbdata:/var/lib/mysql
21+      - pgdata:/var/lib/postgresql/data
22     environment:
23-      MARIADB_HOST: paperless
24-      MARIADB_DATABASE: paperless
25-      MARIADB_USER: paperless
26-      MARIADB_PASSWORD: paperless
27-      MARIADB_ROOT_PASSWORD: paperless
28+      POSTGRES_DB: paperless
29+      POSTGRES_USER: paperless
30+      POSTGRES_PASSWORD: paperless
31 
32   webserver:
33     image: ghcr.io/paperless-ngx/paperless-ngx:latest
34-    restart: unless-stopped
35+    restart: always
36     depends_on:
37       - db
38       - broker
39@@ -68,13 +66,9 @@ services:
40       - extra.env
41     environment:
42       PAPERLESS_REDIS: redis://broker:6379
43-      PAPERLESS_DBENGINE: mariadb
44       PAPERLESS_DBHOST: db
45-      PAPERLESS_DBUSER: paperless # only needed if non-default username
46-      PAPERLESS_DBPASS: paperless # only needed if non-default password
47-      PAPERLESS_DBPORT: 3306
48 volumes:
49   data:
50   media:
51-  dbdata:
52+  pgdata:
53   redisdata:

Ich wurde schon mal des Öfteren gefragt wie ich denn meine Kontakte, Kalender, Passwörter, EMails usw. verwalte.
Persönlich möchte ich diese Datenschätze nicht oder nur möglichst wenig der “Cloud” überantworten und mache daher vieles selbst. Das Setup bzw. das Konzept hat eine jahrelange Entwicklung und eine Menge Veränderungen hinter sich. Zu einigen Teilbereichen sind auch schon vereinzelte Blogartikel entstanden.

Ein Gespräch letztens auf Mastodon hat mich dazu veranlasst, dies mal aufzuschreiben und hier zu veröffentlichen. Wer mag, kann sich aus diesem Text Ideen holen und für seine Situation anpassen.

TL&DR;

• Nextcloud selfhostet auf eigener Hardware im Homelab
• Passwort-Safes KeePass, KeePassXC, Bitwarden, Vaultwarden
• Backup mit restic und resticprofile verschlüsselt mit Deduplizierung auf S3-Storage und externen Festplatten

Jetzt die Langfassung: Wie sieht mein Setup aus?

Die Details

Angefangen habe ich mit Owncloud auf einem BananaPi. Vor einigen Jahren bin dann zu Nextcloud gewechselt. Aktuell läuft die Installation auf meinem Heim-NAS von QNAP in einer virtuellen Maschine wo ein Debian drauf läuft.
Aus-Gründen^(tm) waren und sind die Installationen nie von außen erreichbar.

Nextcloud

In der Nextcloud nutze ich überwiegend folgende Funkionen:

• Verwaltung von
  • Kalendern
  • Kontakt-Daten (VCards)
• Dateiaustausch

Die gesamte Familie bindet alles in ihre jeweiligen Mail- und Kalender-Clients auf den unterschiedlichsten Rechnern, mobilen Geräten mit verschiedensten Betriebssystemen an. Die Synchronisation funktioniert somit natürlich nur im heimischen WLAN oder über VPN.

Backups

Da mir meine Daten (Kalender und Kontakte) sehr wichtig sind, sichere ich die Daten regelmäßig und fertige ein Backup an.
Aktuell läuft auf dem Server, wo die Nextcloud installiert ist, ein nächtlicher Cronjob:

• der die Nextcloud in den Wartungsmodus versetzt,
  • um einen konsistenten Zustand zu erreichen,
• einen Dump der mysql-Tabellen auf Festplatte zieht,
• eine dateibasierte Sicherung anfertigt
• und schlussendlich den Wartungsmodus wieder beendet.

Der Cronjob läuft mitten in der Nacht, wenn sowieso alle schlafen. Selbst wenn das mal nicht der Fall sein sollte, verhindert der Wartungsmodus schlimmeres.
Dieses Verfahren existiert schon so seit Jahren und hat sich aus meiner Sicht bewährt. Selbst der Umzug von Owncloud nach Nextcloud sowie vom BananaPi in die virtuelle Maschine hat damit wunderbar funktioniert.

Die dateibasierte Sicherung und die Dumps ins Dateisystem sind nur ein erster Schritt. Wenn ich einzelne Kontakte oder ähnliches wiederherstellen möchte, ist das rauspfriemeln einzelner Daten nicht wirklich schön, beispielsweise eine einzelne aus Versehen gelöschte Kontakt-Karte.
Allerdings gibt es die Möglichkeit alle Kalendereinträge in eine ics Datei herunterzuladen und alle Kontakte in eine .vcf-Datei herunterzuladen. Daraus ist die Wiederherstellung aus meiner Sicht wesentlich einfacher. Wenn alle Dateien gelöscht sind, reicht ggf. sogar ein Doppelklick im Dateiexplorer auf die jeweilige Datei und es wird im Standard-Mail-Programm geöffnet. Von diesem ist dann ein Import wieder möglich. Dadurch, dass das Mail-Programm wieder in die Nextcloud synchronisiert, ist der Kontakt wieder “drin”. Natürlich war ich faul und habe dies automatisiert; wie ich dies realisiert habe, lässt sich hier nachlesen.

Die ganzen Datenkopien (wie Dumps und Exporte) sichere ich nun mit einem Backup-Programm. Da mir die Daten allgemein wichtig sind und ich auch vor Diebstahl und Feuer gewappnet sein möchte, setze ich hier auf das 3-2-1 Prinzip.

3-2-1-Prinzip

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Die bedeutet: Ich habe eine externe Festplatte auf die ich die Backups regelmäßig kopiere, wobei eine Kopie bei meinen Eltern liegt. Das tägliche Backup schiebe ich in die Cloud. Details siehe in diesem Blog-Artikel im Abschnitt Offsite-Backup.

Cloudspeicher

“Cloud” bedeutet hierbei irgend ein Speicherort, der Dateien aufnehmen kann. Das kann ein OneDrive, eine Dropbox, PDrive oder was auch immer sein. Bei mir ist dies aktuell ein angemieteter S3-kompatibler-Speicher.
Die Backups verschlüssele ich natürlich, daher ist es egal, wo diese im Endeffekt liegen:

• ob es nun eine externe Festplatte ist, die geklaut wird
• oder irgendein Cloud-Speicher, wo Daten abfließen können.

Das gewählte Verschlüsselungspasswort sollte daher möglichst lang und komplex sein.

Backup-Software

Als Software verwendet ich seit einiger restic in Zusammenarbeit mit resticprofile, da ich mit diesen Tools und die Backup-Jobs gut weg-automatisieren kann. Wenn ich daran denken muss, Backups zu machen, vergesse ich das nur.
Wie die Software funktioniert und bedient wird, haben Andreas und ich mal auf den Chemmnitzer LinuxTagen erzählt.

Aus meiner Sicht ist der Vorteil, dass restic

• die Daten verschlüsselt,
• den Platzbedarf mittels Deduplizierung verringert
• und ausmisten nach Regeln beherrscht, da kein Speicher unendlich ist.

resticprofile unterstützt hierbei sogar bei der Erzeugung eines möglichst langen und zufälligem Passwortes. Dadurch, dass ich Dinge automatisch in die Cloud sichere, aber lokal noch eine Festplatte habe, die ich “natürlich” (leider) nur unregelmäßig befülle, hat mir dieses Konzept schon mehrfach wortwörtlich den Hintern gerettet. Aktuell kostet mich der S3-Storage irgendwas unter 4 Euro pro Monat. Bei Interesse nach mehr Details hier klicken. Die dortige Angabe Backblaze stimmt inzwischen nicht mehr. Wegen #unplugTrump bin ich zu Hetzner StorageShare gewechselt.

Passwort-Safes

Ebenfalls seit Jahren nutze ich einen Passwort-Speicher. Bisher reichte mir ein KeePass. Später wechselte ich zu KeePassXC. Die Tresor-Datei lege ich bei mir in meinen Nextcloud-Ordner. Dort synchronisiert sich diese Datei wunderbar zwischen meinen Geräten und ist überall verfügbar, wo ich sie benötige.
Das KeePass-Tersor-Format ist recht verbreitet und es gibt für die unterschiedlichsten Betriebssysteme Software dafür. Die Client-Software für Nextcloud ist ebenso für viele Betriebssysteme verfügbar.

Dank Auto-Fill-Funktion habe ich schon länger kein Passwort mehr getippt und durch die Passwort-Würfeln-Funktion kenne ich auch gar kein Passwort mehr auswendig. Jedem Dienst ein Passwort zu verpassen, ist dadurch für mich recht einfach geworden. In letzter Zeit musste ich jedoch öfters Passwörter teilen und da hat mir KeePassXC nicht gereicht. KeeShare habe ich erst vor kurzem in einen Artikel auf gnulinux.ch entdeckt.
Aus diesem Grund habe ich mir einen Vaultwarden installiert. Vaultwarden ist auch perfekt, wenn ich Dateien oder Textschnipsel über unsichere Kanäle verschicken möchte. Die Funktion nennt sich vaultwarden-send. Über diese Funktion kann ich Dateien oder kurze Texte in den Vault hochladen und danach einen Link zum Herunterladen generieren. Zusätzlich kann ich diesen Link noch mit Passwort-Schutz und sonstigen Parameter versehen. Diesen Link kann ich ruhigen Gewissens unverschlüsselt per E-Mail verschicken. Die Daten liegen verschlüsselt auf der Server-Festplatte und löschen sich standardmäßig nach sieben Tagen selbst.

Tipps zu Vaultwarden

Standard-Einstellungen

Ich empfehle zwei Standard-Einstellungen zu ändern:

• Standard-URI Übereinstimmungserkennung auf Beginnt mit
  • das funktioniert bei mir am zuverlässigsten.
  • gerade auch in Kombination, dass im URL-Feld des jeweiligen Eintrags dann nur die Domain hinterlegt wird.
  • Das bedeutet ohne Pfade und sonstige Parameter!
  • Auffindbar derzeit unter: Einstelllungen->Automatisches Ausfüllen
• Zwischenablage leeren würde ich auf einen kurzen Zeitraum setzen, z.B. auf 30 Sekunden.
  • soweit ich mich erinnere ist der Standard niemals.
  • Auffindbar derzeit unter: Einstelllungen->Sonstiges

Leider muss die Einstellung in jedem Client einzeln gesetzt werden (Browser-Plugin, Smartphone-App usw.)

Admin-Seite

Die Admin-Seite würde ich aus Sicherheitsgründen ausschalten bzw. ausgeschaltet lassen. Wenn ich die Funktionalität doch einmal benötige, schalte ich sie kurzzeitig ein, auch wenn es zwei kurze Downtimes bedeutet.

Verständnis entwickeln

Als ich vaultwarden aufgesetzt habe, hatte ich zuerst zwei Test-Accounts angelegt. Danach habe ich eine “Organistation” und mehrere “Sammlungen” angelegt. Mit diesen zwei Accounts konnte ich dann ein besseres Verständnis der beiden Begriffe und des Berechtigungssystems erlangen.

EMail

Das ist für mich persönlich so ein großes Unlust-Thema und PITA.
Seit ich online bin, lagere ich diesen Service als Dienstleistung aus. Ich klicke mir irgendwo eine Domain und einen E-Mail-Speicherplatz und lasse das Menschen machen, die mehr Ahnung von dem Thema haben als ich. Aktuell bin ich seit Jahren sehr glücklich bei uberspace.
Ich habe bei denen mehrere Accounts (asteroid genannt). Dort lassen sich ohne Zusatzkosten Domains “aufschalten”. In deren verfügbarer Dokumentation (manual) sind die benötigten Befehle recht gut beschrieben, sofern man sich an die Kommandozeile herantraut. In deren Dokumentationsbereich namens Uberlab sind weitere Möglichkeiten beschrieben, zusätzliche Software zu installieren; inkl. Update-Schritten. Vielfach ist es nur ein copy&paste von vorgefertigten Befehlen.

Idee und Ausblick

Soweit ein Einblick in mein Setup und so wie es für mich funktioniert und bewährt hat. Ich habe versucht es kurz zu halten und bei ausufernden Themen mit Verweisen zu arbeiten.

Wer mag, kann die für sich passenden Informationen herausziehen und die eigenen Verhältnisse und Anforderungen anpassen oder ein Konzept zu entwickeln.

Auf der Wunschliste steht noch die Generierung der TLS-Zertifikate per Let’s-Encypt, da muss ich mich nochmal einlesen, wie ich dies umsetze, wenn die Systeme nicht von außen erreichbar sind.

Changelog

Derzeit sichere ich meine Nextcloud-Instanz mit einem dateibasierten Backup-Tool, sowie einem Dump der Datenbank. Letztens hatte ich in meinem Umfeld jemanden, der ein paar Kontakte aus Versehen gelöscht hat. Nun können die vermissten Kontakte zwar aus dem Dump der Datenbank herausgepfriemelt werden, schön ist das aber nicht.

Nach etwas Recherche bin ich auf einen recht simplen curl-Befehl gestoßen, der eine .ics bzw .vcf-Datei heraus exportiert.

Dies ist dann doch aus meiner Sicht etwas einfacher. Sofern z.B. alle Kontakte gelöscht worden sind, reicht dann sogar ein Doppelklick auf die Datei und alle Kontakte werden wieder importiert. Dies sollte wesentlich stressfreier sein.

Als Familien-Admin möchte ich den Export für alle Nutzenden der Instanz regelmäßig machen; daher habe ich mir eine Ansible-Rolle dafür gestrickt.

Das Grundprinzip und die Konfiguration der Rolle möchte ich in diesem Artikel beschreiben.

Auf die Bedienung und Verwendung von Ansible möchte ich hier nicht eingehen, da setze ich entsprechendes Wissen voraus.

Zum Zeitpunkt des Artikel ist die Nextcloud-Version 31 aktuell. Die Pfade, die in der Ansible-Rolle verwendet werden, orientieren sich an diesem Stand. Sollten sich die Subpfade der URLs ändern, müsste die Rolle angepasst werden.

Überblick

Um die Rolle zu verstehen, ist es womöglich am einfachsten, sich das Vorgehen zu verdeutlichen, wenn ein manuelles Backup angefertigt werden soll. Dies soll hier in den nächsten Abschnitten beschrieben werden, um dann im nächsten Schritt zur Automatisierung zu kommen.

Händisches Backup

Melde dich als ersten Schritt in Deiner Nextcloud an.

Kontakte

• Wähle den Reiter Kontakte.
• Gehe nach unten auf der linken Seite und klicke da auf Kontakte-Einstellungen.

• Navigiere jetzt zu den Allgemeinen Einstellungen.
• Beim gewünschten Adressbuch auf die drei Punkte klicken (1)
• und auf Herunterladen klicken (2).

• Voilà! Es wird eine .vcf-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Kalender

• Wähle den Reiter Kontakte.
• Wähle Deinen Kalender aus, den du exportieren möchtest.
• Fahre Deine Maus etwas nach rechts bis das Stift-Icon erscheint (1) und klicke auf diesen.

• Im nächsten Dialog Kalender bearbeiten gibt es dann eine Schaltfläche mit der Beschriftung Exportieren.

• Voilà! Es wird eine .ics-Datei mit einem aktuellen Datumsstempel zum Download angeboten.

Automatisierung

Jetzt wollen wir das ganze automatisieren; dafür gibt es meine Ansible-Rolle export_nextcloud. Die Rolle findet Du auf meinem Gitlab-Account.

Die Rolle solltest Du auf einem Linux-Host deployen, dem Du vertraust und der Zugriff auf die Nextcloud hat.

Minimale Angaben

Variable export_nextcloud_url

Zunächst benötigt die Rolle die URL, worunter die Nextcloud-Instanz erreichbar ist. Dazu hinterlegst Du diese in der Variable export_nextcloud_url als Hostvariable, wo das Export-Script später laufen soll.

Beispiel:

1export_nextcloud_url: "https://meine.nextcloud.instanz"

Variable export_nextcloud_user

Jetzt brauchst Du eine Liste mit einem oder mehreren Usernamen, die du sichern möchtest. Zusätzlich ein Passwort und einen Zeitpunkt, wann das Export-Script laufen soll.

Empfehlung

Statt des regulären Passwortes für Deinen User, empfehle ich die Generierung eines Personal Access Token kurz “PAT”.

Die Einrichtung eines PAT beschreibe ich in einem anderem Blog-Artikel.

Als dritten Parameter wird noch der Zeitstempel benötigt, wo der Export laufen soll. Mit dieser Angabe wird später eine SystemD-Timer-Unit erstellt.

Die Syntax dieses Attributes folgt dem Parameter on_calendar von systemd.unit(5). Aus jeden username wird eine extra SystemD-Timer-Units erstellt, nach folgendem Muster:

• export_nextcloud-user1.timer
• export_nextcloud-user2.timer

Die Konfiguration sieht am Ende zum Beispiel so aus:

1export_nextcloud_user:
2  - username: "user1"
3    password: "password1"
4    on_calendar: '*-*-* 03:00'
5  - username: "user2"
6    password: "password2"
7    on_calendar: '*-*-* 03:01'

Optionale Angaben

Variable export_nextcloud_script_path

Die nächste Variable bestimmt, wohin das Script kopiert werden soll. Der Standardpfad lautet /opt/export_nextcloud.

Variable export_nextcloud_backup_path

Über diese Variable kann bestimmt werden, wohin die exportierten Kalender- und Kontakte-Dateien hingeschrieben werden sollen. /backup/nextcloud_export lautet hier der Standardpfad.

Hier entsteht pro Username eine Kalender- und eine Kontakte-Datei mit dem Username nach folgendem Muster:

• kalender-${username}.ics
• kontakte-${username}.vcf

Und ja, ich war zu faul, noch ein extra Aufräum-Mechanismus zu schreiben. Für die Versionierung ist bei mir mein Backup-Programm zuständig ;-) . Das kann mein Sicherungsprogramm viel effizienter als ich. Wenn ich an ältere Versionen herankommen möchte, muss ich die Sicherung bemühen; ich spare mir dadurch zusätzliche Fehlerquellen und Abhängigkeiten.

Variable export_nextcloud_prometheus_path

Diese Variable legt den Pfad fest, wo die Prometheus-Statistiken hingeschrieben werden.

Variable export_nextcloud_extra_curl_options

Diese Variable habe ich am 03.10.2025 eingeführt, weil der zugrunde liegende curl sich am selbst-signierten Zertifikat meiner Nextcloud-Instanz störte. Mit dem Parameter -k oder --insecure lässt sich das aber übersteuern. Dies erforderte allerdings eine Anpassung des Scriptes.

Nun können weitere Parameter über diese Variable optional mitgegeben werden.

Im unteren Beispiel Ansible Playbook fügt ihr an den einen Task folgende zwei Zeilen an.

1  vars:
2    export_nextcloud_extra_curl_options: "--insecure"

Ansible Playbook

Jetzt kannst Du die Rolle in ein Ansible-Playbook einbinden.

Ein minimales Beispiel wäre:

1---
2
3- name: Setup export_nextcloud
4  hosts: export_nextcloud
5  roles:
6    - export_nextcloud

Backup

Im Nachgang bzw. nach dem Ausführen der jeweiligen SystemD-Timer-Unit, empfehle ich noch ein Backup des Verzeichnisses wo die exportierten Dateien liegen. Das Verzeichnis kannst zum Beispiel dateibasiert mittels deiner präferierten Wunsch-Backup-Software gesichert werden. Ich selbst habe dazu die Pfade in meinem Sicherungsscript aufgenommen; hier verwende ich restic seit längerem erfolgreich.

Fertig.

Im Grunde war es das auch schon. Viel Spaß beim Benutzen. Der Source-Code der Rolle liegt in meinem Gitlab-Account.

Changelog

Notizensammlung

Dinge, die ich mir bei systemd nicht merken kann. Und bevor ich wieder Suchmaschinen oder man-Pages bemühen muss, schreibe ich sie hier lieber nieder.

Im Hintergrund starten

Parameter --no-block verwenden, damit der Prompt gleich wieder kommt und nicht auf Beendigung gewartet wird; praktisch für Backup-Jobs außerhalb der Reihe.

1systemctl start resticprofile_full-backup.service --no-block

Timer in SystemD

wird gerne von snap-Paketen genutzt, die keinen cronjob installieren.

Auflistung

1systemctl list-timers [--all]

In der Auflistung steht dann auch der timer, wo die Zeitdefinition drin steht und welche start-Unit anzieht.

Verzeichnis vielfach: /etc/systemd/system/foo.timer

Als Ersatz für at

1systemd-run --user --on-calendar="2024-12-28 10:31:19" Befehl Parameter....

ggf. sudo davor für root.

failed Units

Alle auflisten

1systemctl status --failed

Resetten

1systemctl reset-failed <unit-name>

Auskunft über pids

1systemctl status <pid>

Changelog

Ein paar kleine Tricks und Kniffe zum Thema Docker.

mysqldump ohne Passwort in Prozessliste

Unter docker werden die Zugangsdaten meist über Umgebungsvariablen weitergegeben.

Arbeitet man jedoch bei mysqldump mit dem Parameter -p gibt es folgende Warnung

mysqldump: [Warning] Using a password on the command line interface can be insecure.

Um jetzt nicht alles nach /dev/null umzuleiten, um noch echte Fehler mitzubekommen, kann man mittels des Parameters --defaults-file das Passwort in eine Datei kopieren. Da sich Zugangsdaten ändern können, empfiehlt es sich, das dynamisch per Script zu erzeugen und das Passwort aus der Umgebungsvariable des Containers auszulesen.

Das Script legt man entweder in ein lokales Volume oder kopiert es via docker cp in den Container.

Das Beispiel-Script zum dynamischen Erzeugen der Credentials-Datei:

1#!/bin/bash
2CRED_FILE="/docker-entrypoint-initdb.d/credentials-root.conf"
3#loeschen
4> "${CRED_FILE}"
5chmod 600 "${CRED_FILE}"
6echo "[client]" >>  "${CRED_FILE}"
7echo "password=${MYSQL_ROOT_PASSWORD}" >> "${CRED_FILE}"

Und noch ein Auszug aus einem Backup-Script:

1docker exec -i  onlyoffice-mysql-server  /bin/bash /docker-entrypoint-initdb.d/gen_cred_config.sh
2(docker exec -i onlyoffice-mysql-server mysqldump  --defaults-file=/docker-entrypoint-initdb.d/credentials-root.conf <weitere Dump-Parameter>  -u root -h<hostname>  | xz -c > "${BACKUPDIR}/dump.sql.xz"

Umgebungsvariable aus Docker-Container auslesen

1docker exec -i onlyoffice-community-server /bin/bash -c '/bin/echo ${MYSQL_SERVER_PASS}'

Unterordner in Docker-Volume ignorieren

Dem docker-compose ein Verzeichnis der lokalen Maschine übergeben, aber einzelne Unterverszeichnisse davon ausnehmen:

Das funktioniert, indem für die auszunehmenden Unterordner ein zweites Volume angeben wird. Volume darf keine Zuordnung mit einem Doppelpunkt enhalten:

1volumes:
2- ./webseite/html:/var/www/html
3- /var/www/html/static/

Im Beispiel bekommt ein Webserver die ganze Webseite übergeben, der Ordner static wird aber aus dem Container benutzt.

Backups & Recover via Volume mounten

reingucken

1docker run -it --rm -v portainer_data:/data:ro -v $(pwd):/backup alpine /bin/sh

sichern

Variante 1

1docker run --rm -v portainer_data:/data:ro -v $(pwd):/backup alpine tar cjvf /backup/data.tbz2 -C /data ./

Variante 2

1docker run --rm -v portainer_data:/data alpine tar cf - -C /data ./ | xz > ./portainer_data_volume.txz

Recover

1docker run --rm -v portainer_data:/data -v ./portainer_data_volume.txz:/backup.tgz alpine tar tJf -C /data /backup.tgz

Volumes

Wie unterscheiden sich nochmal die Bezeichnungen bei den Volumes?

• bind volume
• named volume
• volume

Logfiles auf die Konsole

Logfile-Ausgaben können über STDOUT einfach an das "Terminal" geblasen werden, der dann via docker log <container-name> bzw. Portainer auslesbar ist.

Eine Apache-Konfig conf-enabled/other-vhosts-access-log.conf kann z.B. so aussehen:

1# Define an access log for VirtualHosts that don't define their own logfile
2CustomLog /proc/self/fd/1 vhost_combined

Im Container selbst ist dann der Grund zu sehen, warum das funktioniert:

1# ls -l /proc/self/fd/1
2lrwx------. 1 root root 64 Jul  8 16:19 /proc/self/fd/1 -> /dev/pts/0

Habe ich mal in einem ubuntu-basierten Container gesehen, ziemlich genial.

docker ENTRYPOINT

Weil ich mir nie merken kann, wie wann was gestartet wird, hier mal eine Tabelle:

Zeitzonen

Die lokale Zeitzone lässt sich per Volume-Mount an den Container durchreichen, sofern die Applikation das unterstützt bzw. beachtet.

1    volumes:
2      - /etc/timezone:/etc/timezone:ro
3      - /etc/localtime:/etc/localtime:ro

Pull und Restart

1docker compose up -d --pull always

bzw.

1docker compose up -d --build --pull always

Erstellungsdatum (Created) eines Images abfragen

1docker inspect docker.io/photoprism/photoprism:latest -f "{{ .Created}}"

Changelog

Bei einem dateibasierten Backup wollte ich nicht immer alle Dateien und Unterverzeichnisse in die Sicherung mit aufnehmen.

Viele Tool wie restic, backup oder auch tar unterstützen eine externe Datei, wo diese Ausnahmen gepflegt werden können.

Allerdings vergesse ich manchmal diese Datei zu pflegen oder die Syntax ist etwas umständlich.

Manchmal möchte man auch nur-mal-eben-schnell ^(tm) ein Verzeichnis ausschließen.

Dafür gibt es die Möglichkeit über eine Datei namens CACHEDIR.TAG zu nutzen.

Voraussetzungen

Diese Datei muss nur zwei Voraussetzungen erfüllen:

1. Der Name der Datei muss CACHEDIR.TAG lauten und zwar in genau der Schreibweise.
2. Der Inhalt der Datei muss einen bestimmten Inhalt haben.

Name der Datei

Der Name der Datei muss genau CACHEDIR.TAG lauten; hierbei ist auch auf Groß- und Kleinschreibung zu achten.

Inhalt der Datei

Am Anfang der Datei muss ein bestimmter Inhalt stehen, er lautet:

1Signature: 8a477f597d28d172789f06886806bc55

So eine Datei kann auch über ein Shell erstellt werden, z.B. so:

1echo "Signature: 8a477f597d28d172789f06886806bc55" > CACHEDIR.TAG

Wichtig hierbei sind nur die ersten 43 Octets der Datei. Danach können noch weitere Informationen kommen, wie z.B. eine kleine Notiz:

1Signature: 8a477f597d28d172789f06886806bc55
2# Diese Datei bedeutet, dass dieses Unterverzeichnis und seine Inhalte vom Backup ausgeschlossen werden.

Aber auch hier muss auf die Groß- und Kleinschreibung beim Inhalt der Datei geachtet werden. Alternativ kann man diese Datei auch nutzen, um eine solche Datei mit Ausnahmen zu erstellen. Diese Datei lässt sich dann z.B. mit dem Programm tar auswerten, um ein Archiv zu erstellen, was diese Verzeichnisse auslässt.

Beispiel:

1find . -name CACHEDIR.TAG | sed -e 's/[/]CACHEDIR.TAG-//g' >/tmp/excludes
2 tar cvf /tmp/backup.tar --exclude-from/tmp/excludes .

Diese Tagging-Konvention lässt sich somit auch für weitere Tools benutzen, auch wenn diese die Konvention noch nicht direkt unterstützen. Definitionen von Ausnahme-Listen unterstützen meist viele Programme und über diesen kleinen Umweg, lässt sich die Tagging-Technik schon jetzt meist ohne Änderung der Programme nutzen.

Die Tools restic und borg können mit dem Parameter --exclude-caches angewiesen werden, die Datei CACHEDIR.TAG zu berücksichtigen. Hier werden dann automatisch die Verzeichnisse mit ihren Unterinhalten vom Backup ausgenommen, die eine solche Datei enthalten.

Beispiel:

1restic -r /backup/backup_home_dirs backup --exclude-caches /home/

Auch Verzeichnisse wie /var/cache lassen sich damit elegant aus dem Backup aussparen.

Ich bin sehr froh dieses entdeckt zu haben, da ich jetzt nicht mehr für jede Ausnahme pflegen muss und dann wieder das Backup-Script irgendwo einchecken oder auf irgendwelche Server verteilen muss. Hier reicht jetzt das triviale Anlegen einer Datei in dem gewünschten Verzeichnis.

Credits

Die ursprüngliche Idee bzw. Vorschlag stammt von Bryan Ford und kann hier nachgelesen werden.

Heute möchte ich über das Thema Datensicherung aka Backups schreiben. Hier und da wurde ich gefragt, wie ich das löse bzw. umgesetzt habe.

Mariannes Blog-Artikel gab den Ausschlag dieses nun endlich mal aufzuschreiben.

Es wird eine kleine Reise werden. Ich werde über die grundsätzlichen Gedanken berichten, die ich mir gemacht habe, als auch etwas in technische Details gehen. Ebenso werde ich Dinge niederschreiben, die sich nicht bewährt haben, da dies evtl. für andere ebenfalls hilfreich erweisen sein.

Dieser Artikel wird länger ;-)

Start

Grundsätzlich wollte ich das Backup am Ende so gestalten, dass es für mich relativ einfach ist anzuwenden. Sind beim Anfertigen eines Backups mehrere Vorbereitungen notwendig oder muss ich minutenlang einem Script zuschauen, neige ich dazu, das Backup zu vergessen oder “gerade keine Zeit” zu haben. Und ein Backup sollte natürlich möglichst aktuell sein. Ein Ziel von mehreren muss also die Cloud^(tm) sein. Damit entfällt das Gestöpsel von einer externe Festplatte und es gibt eine Ausrede weniger. Weiterhin bietet dies die Möglichkeit, das Backup weiter zu automatisieren, z.B. beim Runterfahren des PCs. Dazu jedoch später mehr.

Was will ich sichern und warum?

Der erste Schritt, den ich getan habe, war mir zu überlegen, was ich alles sichern möchte und ich habe mir folgende Fragen gestellt:

Was ist mir wichtig?

Habe ich Dinge, an denen mein Herz hängt? Die Antwort lautet: “Ja” und zwar z.B.

• Fotos, Videos
• bestimmte E-Mails
• Systemeinstellungen
• Programm-Einstellungen
• selbst geschriebene Scripte
• Dokumente

Gibt es nicht ganz so wichtige Daten?

Gibt es Dinge, die ich zwar sichern möchte, aber es vielleicht nicht so schlimm ist, wenn ich sie doch verliere? Dies wird später wichtig, in welche Sicherungs-Archive ich Dateien zuordne. Zum Beispiel:

• ISO-Dateien von gekauften CDs
• alte Installations-CDs von Steuer- oder Finanzsoftware

Habe ich unwichtige Dinge?

Kann ich Daten sparen bzw. das Backup kleiner machen? Kann ich Dinge ausschließen? Beispiele:

• temporäre Dateien
• Download-Ordner
• thumbnails-Ordner
• Cache-Ordner

All das verringert unter anderem die Größe eines Archivs, was wiederum Kosten spart. Eine größere externe Festplatte oder mehr Cloud-Speicherplatz kosten nun mal Geld. Dateien, die beim Backup übergangen werden können, sparen zudem Zeit, weil sie nicht gelesen werden müssen. Das hat den Vorteil, dass auch der einzelne Lauf schneller geht, was wiederum mehr motiviert, ein Backup durchzuführen.

Je nach Art des Backup-Programms gibt es unterschiedliche Möglichkeiten, entweder bestimmte Dateien oder Pfade zu definieren, die ich ausschließen möchte. Zum Teil lassen sich sogar generische Muster von Dateinamen oder Verzeichnispfaden definieren. Diese Muster sind flexibler als starre Listen, weil ich dann nicht mehr absolut und gewissenhaft jeden einzelnen thumbnails-Unterordner definieren muss.

Einige Backup-Programme unterstützen auch eine Datei namens CACHEDIR.TAG .
Dies ist eine simple Text-Datei, die einen bestimmten Inhalt haben muss. Befindet sich diese Datei in einem Ordner (zum Beispiel der Download-Ordner) so wird dieser Inhalt vom Backup-Lauf ausgenommen. Wie die Datei genau aussehen muss, habe ich in diesem Blog-Artikel beschrieben.

Vertraulichkeit

Zudem wollte ich ein Backup haben, das für andere Personen wertlos ist, wenn es ihnen in die Hände fällt. Hier bietet es sich an das Archiv zu verschlüsseln.

Wie will ich sichern?

Ich habe mich für eine dateibasierte Sicherung entschieden. Vielfach musste ich in der Vergangenheit bisher nur einzelne Dateien oder Ordner wiederherstellen. Im allerschlimmsten Fall, musste ich meinen Rechner komplett neu aufsetzen. In diesem Fall habe ich die Installationsmedien des Betriebssystems und der jeweiligen installierten Programme zu Hause vorrätig.

Alternativ müsste ich mir die Medien aus diesem Internet neu herunterladen. Es gibt zwar Tools, mit denen man die komplette Festplatte inklusive ihrer Konfigurationen sichern kann, aber dies erfordert meist mehrere Handgriffe und eine Downtime des Rechners. Die Erfahrung zeigt, dass man dies nur selten macht, eben weil es so umständlich ist. Als initiale Sicherung mag dies jedoch eine gute Idee sein.

Insofern wollte ich eine bequeme Lösung haben, wo ich nicht viel tun muss. Ich wollte nicht allzu oft meine externe Festplatte anschließen, denn das bietet sonst nur Ausreden Nahrung.

Und was ist mit dem Betriebssystem?

Ich habe vom jeweiligen Betriebssystem ein Installationsmedium; das reicht mir. Im schlechtesten Fall muss ich den kompletten Rechner neu aufsetzen; egal ob Windows oder Linux. Im schlimmsten Fall sind die Installationsmedien auch noch aus dem Internet herunterladbar.

3-2-1

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Schnelle Sicherung: lokal

Was im Grunde übrig bleibt, sind viele Dateien unterschiedlicher Größe und Wichtigkeit. Sehr lange habe ich dafür BorgBackup benutzt, einfach auch weil es bei meiner Distribution dabei war und ich mich dann nicht um Programm-Updates kümmern muss(te). Inzwischen verwende ich restic - zu den Gründen komme ich später.

Die allererste Sicherung geht erst einmal lokal auf die Festplatte in einem extra Bereich; unter Linux ist das bei mir der Pfad /backup. Die Dateisystem-Rechte sind so gesetzt, dass hier nur ein Benutzer mit administrativen Rechten herankommt. Das schützt unter anderem vor versehentlichen Löschen.

Die eigentliche Arbeit erledigt ein selbst geschriebenes bash-Script. Dieses Script kann z.B. beim Runterfahren des PCs verwendet werden. Der Vorteil: Ich muss dem Script nicht zugucken und alle Programme sind geschlossen. Dies ermöglicht ein konsistentes Backup der Dateien, weil sich keine Dateien mehr ändern. Ggf. kann ich dies sogar remote per ssh vom Handy aus aufrufen, weil ich für ein bash-Script keine Oberfläche benötige.

Wenn das Script fertig ist, fährt es den PC komplett runter und schickt mir eine Discord-Nachricht aufs Handy mit einer Statusmeldung. Für dieses Script habe ich mich schon vor einiger Zeit in einen eigenen Blog-Artikel verfasst.

Wenn das Script fehlerfrei durchgelaufen ist, kann ich die Steckerleiste ausschalten und habe keinen Standby-Stromverbrauch mehr. Im Fehlerfall weiß ich Bescheid, dass irgendwo ein Fehler passiert ist und ich evtl. kein aktuelles Backup habe.

Auf Servern starte ich dieses (ggf. abgewandelte und angepasste Script) automatisch per crontab. Im Fehlerfall weiß ich Bescheid, dass ich bei nächster Gelegenheit mal auf das System gucken sollte, was da genau schief gelaufen ist. Im einfachsten Fall ist es eine Datei, die sich dann im laufenden Betrieb geändert hat, aber auch schon volle Backup-Partitionen hatte ich. Ja, Monitoring auf den privaten Systemen ist Punkt 3.520.230 auf meiner TODO-Liste.

Aufräumen

Am besten räumt man vorher auf, hat also etwas Datendisziplin. Mehrere Versionen einen Schnappschusses bereinigt man um die Version, die man aufheben möchte. Eigene Filmaufnahme oder Filmschnipsel kürzen und verwackelte, unscharfe Handyvideos fressen auch nur unnötig Platz.

Die Programme borg bzw. restic können Sicherungen zudem automatisch ausdünnen. Über Parameter kann ein Backup anhand definierter Regeln ausgedünnt werden. Beispielweise bleiben die letzten 7 täglichen Backups erhalten und für den Rest des Monats wird ein wöchentlicher Schnappschuss aufbewahrt. Danach wird nur der neueste monatliche Schnappschuss aufbewahrt. Durch die fest definierten Regeln, wird ein manuelles und damit meist fehlerträchtiges Heraussuchen vermieden.

Sicherung Cloud

Das selbe Script hat einen optionalen Schalter, wo diese Sicherung “in die Cloud” angeschaltet werden kann. Dieser Schritt kommt zwischen dem Ende der lokalen Sicherung und dem letztendlichen Herunterfahren des Rechners.

Offsite-Backup

Um eine weitere Kopie meiner Daten zu haben, habe ich mir zwei externe Festplatten beschafft. Eine liegt immer neben dem Rechner, ist aber nicht angeschlossen, die andere liegt bei meinen Eltern. Die externen Platten sind außen beschriftet und haben auch ein Software-Label, so dass ich sie beim Einhängen in das Dateisystem unterscheiden kann. Alle paar Tage stöpsle ich dann die externe Festplatte an und synchronisiere die lokale Sicherung vom dem PC auf diese. Nach der Sicherung stöpsle ich sie wieder ab und die Festplatte ist dann vor versehentlichen Löschen sicher.

Diese Festplatte bringe ich dann alle paar Wochen zu meinen Eltern und tausche sie mit dort liegenden Festplatte aus. So habe ich im Fall der Fälle (Hausbrand, Einbruch usw.) eine weitere Kopie an einem anderen Ort. Der Stand der Sicherung ist dann möglicherweise ein paar Wochen alt, aber immerhin besser als ein Totalverlust.

In der Summe sind die Daten jetzt fünfmal vorhanden.

Aber !?!

Die Kosten

USB-Festplatten

Die externen Festplatten tausche ich alle paar Jahre aus. Nicht nur weil sie irgendwann zu klein werden, sondern ich möchte Bitfäule und mechanischem Ausfall vorbeugen. Die Variante als drehenden Rost ist derzeit noch die billigste Variante pro Gigabyte.

Cloud

Ja auch Cloud-Storage-Anbieter möchten Geld verdienen; schließlich müssen Server und Personal irgendwie bezahlt werden.

Alternative?

In der Summe sind mir meine Daten lieb und diesen Preis wert. Die Alternative wäre ein Totalverlust und das möchte ich nicht.

Sync

Das führende Backup ist die Sicherung auf dem lokalen PC. Zum Synchronisieren auf die externe Platte nutze ich rsync, in die Cloud verwende ich rclone. Beide Tools haben mehrere Vorteile. Das lokale Backup hat einen konsistenten Stand. Die Synchronisation kann im Hintergrund laufen. Weil der neueste Stand immer lokal vorhanden ist, müssen nur die Differenzen in die Cloud oder die externe Festplatte übertragen werden, d.h. es geht sehr schnell. Zudem muss ich mir keine Gedanken machen, wo wie welcher Stand ist und ob und wo ich irgendwelche Voll- oder inkrementelle Backups gemacht habe oder noch machen muss. Auch das automatische Ausdünnen bzw. aufräumen der Backups wird dann auf allen Zielen automatisch mitgezogen bzw. vollzogen. Da ich nur stumpf Dateien hin und her kopiere, ist die Wahl des Backup-Programms (borg oder restic) irrelevant.

Online-Speicher aka Cloud

Cloud !!!111EinsElf Oh! Nein! Doch!

Die Programme borg bzw. restic können Out-of-the-box stark verschlüsseln. Die Archive können mit einer Datei oder einen starken Passwort gesichert werden. Insofern ist Wahl des Anbieters für den Cloud-Storage unabhängig von dessen Vertrauenswürdigkeit. Mit den verschlüsselten Dateien kann ohne das Passwort niemand etwas anfangen. Somit können Parameter wie Zuverlässigkeit, Geschwindigkeit und der Preis entscheiden.

Ich persönlich habe mich aufgrund Mariannes restic-Artikel ebenfalls für Backblaze¹ entschieden. Das Tool rclone synchronisiert wie gefordert die dateibasierte Sicherung und unterstützt deren Produkt B2 Cloud.

Download kostet aber

Backblaze¹ verlangte für den Download der Daten Geld; inzwischen gibt es ein bestimmtes Freikontingent. Andere Anbieter verlangen allerdings auch zum Teil Download-Gebühren.

Hier stellte ich mir die Frage, wann ich jemals Download-Traffic in Anspruch nehmen werde. Ja genau, beim Recover. Und diesen Fall wollte ich erstens so selten wie möglich und wenn, dann ist der Cloud-Speicher ja einer meiner Standbeine. Und im Fall einer Wiederherstellung sind mir die Daten so wichtig, dass ich das Geld auch gerne ausgebe, um die wiederzubekommen. Schließlich war genau dies der Zweck, den der Anbieter erfüllen sollte.

Im Bestfall kann der Großteil der Sicherung auch von der externen Festplatte gezogen werden und es müssen nur noch die Differenz aus der Cloud heruntergeladen werden. Dadurch minimiert sich dann die Größe der Dateien, die heruntergeladen werden müssen. Und damit sinken die Download-Kosten und natürlich auch die benötigte Zeit.

Beispiel

Genau so einen Fall hatte ich vor einiger Zeit schon einmal. Ich wollte eine alte, externe Festplatte verschenken und daher diese sicher löschen. Ich hatte leider nicht gut genug aufgepasst und mit dc3dd die falsche Partition geschreddert; inklusive der lokalen Backup-Kopie unter /backup. Die letzte Sicherung auf der externen Festplatte war drei Wochen alt, weil ich wohl zu diesem Zeitpunt längere Zeit zu faul war sie anzustöpseln. Der Stand im Cloud-Speicher war aber vom Vortag. Yay! Das war meine Rettung. Einige E-Mails lagen eh noch auf dem IMAP-Server und ein paar Downloads wie Rechnungen, Kontoauszüge, musste ich dann eben neu herunterladen. Das Delta aus der Cloud war damit gering und ging schnell von statten. Im Grunde hatte ich kaum etwas verloren. Ohne Cloud-Backup wären mir drei Wochen Daten flöten gegangen, es hat mir wortwörtlich den Hintern gerettet.

Jeder Ort ein Repo

Hier gehe ich einen anderen Weg, als allgemein empfohlen. Viele Backup-Konzepte raten dazu für jedes Ziel (lokale Festplatte, externe Festplatte oder Cloud) einen komplett neuen Lauf zu starten. Aus meiner Sicht laufen die Stände dann auseinander. Man hat überall unterschiedliche Stände. Wenn ich eine Datei wiederherstellen möchte, muss ich gucken welcher meiner Sicherungsorte die gewünschte Datei zu einem vorhandenen Sicherungszeitpunkt noch beinhaltet. Außerdem dauern die Sicherungen länger, weil wieder alle Quell-Dateien neu eingelesen werden müssen, um zu schauen, welche Dateien sich geändert haben. Dieser Schritt fällt bei mir weg, weil die Anzahl der Dateien in meinem Backup prinzipbedingt schon geringer ist und die Daten schon komprimiert wurden. Das Übertragen auf einen weiteren Ort, geht also wesentlich schneller. Zudem müsste ich so mehrere Scripte vorhalten, die nur unterschiedliche Zielpfade haben, oder das Script so generisch schreiben, dass wiederum die Komplexität steigt und Wartbarkeit leidet.

In meinem Fall ist es ein einfacher rsync oder rclone-Aufruf.

Wann

Linux

Ich habe mich bewusst gegen einen Automatismus an meinem persönlichen Desktop-PC entschieden. Es erfordert etwas Disziplin, hat sich bisher aber für mich bewährt.

Aktuell kann ich spontan entscheiden, ob ich den PC nur schnell runterfahren möchte oder ob ich ein Backup fahren möchte. Wenn ich mich entscheide, kein Backup zu machen, weil ich z.B. nur schnell ein paar E-Mails geschrieben habe, kann ich den PC schneller wieder runterfahren. Das Ausschalten über die Steckerleiste hilft mir dann wieder Strom sparen.

Habe ich viele Änderungen an den Daten vorgenommen und entscheide ich mich für das Backup, wird eine lokale Kopie auf dem Rechner angelegt. Dies kann auch durchaus mehrmals am Tag sein. Am Ende des Tages setze ich dann per Script-Parameter, dass im Anschluss eine Synchronisation in die Cloud stattfinden soll. Ich kann dann den Rechner verlassen und mich anderen Dingen widmen. Etwas später, z.B. kurz vor dem ins Bett gehen, kann ich dann die Steckerleiste ausschalten. Die automatische Discord-Benachrichtigung zum Schluss des Scriptes erinnert mich daran. Da ich das Script kurz vor dem Runterfahren des Rechners ausführe, ist auch egal wie lange es dauert. Solange ich außerhalb jeglichen Glasfaser-Ausbau-Gebieten wohne, muss ich nun mal mit der langsamen Upload-Leitung leben.

Was

Unter Linux sichere ich z.B. den /etc-Baum, wo viele Einstellungen und Konfigurationen liegen. Der größere Teil liegt dann im Benutzer-Verzeichnis (bei mir unterhalb von /home). Genauere Details dazu wird es mal in einem späteren Blog-Artikel geben.

Wiederherstellung

Das letzte Mal, als ich mein System wiederherstellen musste, hat es gereicht /etc als auch /home neu einzuspielen und ich war überwiegend wieder arbeitsfähig. Die Programm-Installation unter Linux gestaltet sich relativ einfach und unkompliziert, zumindest bei den Dingen, die von der jeweiligen Distribution mitgeliefert werden.

Windows

Bei Familienmitgliedern, die Windows verwenden, läuft das Backup-Script wiederum beim Anmelden am System. Ich habe noch keine Möglichkeit gefunden, dass es beim Herunterfahren ausgeführt wird. Ein extra Klick mit einer Verknüpfung hat sich nicht bewährt, weil es gerne vergessen wird und der Rechner einfach nur stumpf via Windows-Menü heruntergefahren wird. Durch den automatisierten Aufruf während des Logins, entfällt ein manueller Eingriff und es läuft jedes Mal.

Was

Bei Windows im Enduser-Bereich sichere ich ebenfalls hauptsächlich den Benutzerordner, da dort vieles wichtiges abgelegt ist. Mir ist klar, dass auch durchaus einige Einstellungen in der Registry stehen, aber für die weitere Recherche reicht meine Motivation nicht. Wahrscheinlich ist es eh besser, im K-Fall² das System komplett neu aufzusetzen und dann nur die Benutzerdaten wiederherzustellen.

Server

Zu Hause läuft noch ein NAS-System mit virtuellen Servern. Dort wird mittels Crontab fast dasselbe Backup-Script ausgeführt. Der Sync in die Cloud findet allerdings täglich statt. Da ich noch Webanwendungen betreibe, ist das Backup-Script etwas aufgebohrt. Je nach Dienst dreht es noch ein paar Schleifen. Bei neueren Systemen habe ich sogar schon auf resticprofile umgestellt.

Beispielsweise hat das interne Kanboard eine Datenbank-Anbindung. Vor dem Start der dateibasierten Sicherung wird noch ein logischer Datenbank-Dump in ein Verzeichnis geschrieben, dass dann ebenfalls mitgesichert wird. Ich weiß, dass es da z.T. bessere Möglichkeiten gibt, als ein schnöder mysqldump. Da ich schon mehrfach die Webanwendung Kanboard und andere Dienste wiederherstellen konnte, hat es für mich bisher so gereicht.

Anwendungen in Docker-Containern stoppe ich vorher, um einen konsistenten Stand zu sichern oder fahre, wie bei paperless, einen automatisierten Export der Daten in das Dateisystem.

Recover testen

Auch das Thema Recover, also der Wiederherstellen der Daten, sollte man nicht unterschätzen. Testet Eure Backups und versucht die Daten wieder herzustellen!

Nichts ist schlimmer, als wenn man meint immer ein Backup gemacht zu haben und man dann feststellen muss, dass es kaputt ist oder wichtige Dinge fehlen. Der Test schützt vor dem Verlust wichtiger Dateien bzw. Daten. Wenn Ihr Software wie zum Beispiel Tandoor Recipes aufsetzt, befüllt sie zu Anfang mit nur ein paar wenigen Daten. Dann macht Ihr ein Backup und löscht die komplette Installation. Im nächsten Schritt versucht Ihr die Anwendung oder auch die Daten aus dem Backup wieder herzustellen.

Pro-Tipp am Rande: Dokumentiert in diesem Fall gleich, wie ihr vorgegangen seid, die Daten wieder herzustellen. Wenn Ihr Daten verloren habt, befindet Ihr Euch meist sowieso in einer Stress-Situation. Wenn ihr dann noch rausfinden müsst, wie ihr wieder an Eure Daten kommt und wie der alten Zustand wieder hergestellt werden kann, bedeutet das zusätzlichen Stress, den ihr mit diesem Vorgehen vermeiden könnt. Eine gute Anleitung erleichtert später die Arbeit und trägt wesentlich zur Entspannung bei.

Verfeinerung

Sortierung nach Wichtigkeit

Ich sortiere meine Backups in unterschiedliche Container bzw. Repositorys.

Es gibt persönlich mir wichtige Sachen, wie E-Mails und Bilder, selbst geschriebene Scripte etc. Dann gibt es nicht so wichtige Dinge, wie ISO-Dateien von gekauften CDs oder alter Installations-CDs von Steuer- oder Finanzsoftware.

Einige Dateien ziehe ich auch über das Netz, wie das Backup-Archiv vom NAS. Dies dauert dann länger und daher möchte ich das nicht immer machen.

Es gibt ein extra Repo und Script für die Sicherung meiner digitalen Bilder. Dies erfordert durchaus Disziplin, um da den Überblick zu behalten, aber die Bilder-Ordner erfahren aber auch nicht so oft eine Änderung, als dass das täglich nötig wäre.

Ebenso gibt es Backups-Repos, die nur auf der externen Festplatte landen und nicht in der Cloud.

Meta-Daten

Ein paar wichtige Meta-Daten, wie die Aufteilung der Festplatte, schreibe ich ebenso automatisiert während des Backup-Laufs in einen speziellen Unterordner. Diesen sichere ich gleich mit.

Auch Infos zum LVM, Filesysteme oder installierte Pakete speichere ich in Textdateien und nehme diese Pfade in zu sichernden auf.

 1# Partitionen
 2parted -l > "${METAINFOSDIR}/parted-l.txt"
 3# Filesysteme
 4mount >> "${METAINFOSDIR}/parted-l.txt"
 5# Software-Pakete
 6pacman -Qqet > "${METAINFOSDIR}/manjrao_installierte_pakete"
 7pacman -Qqm > "${METAINFOSDIR}/manuell-installierte-pakete.txt"
 8# LVM-Infos
 9vgdisplay >  "${METAINFOSDIR}/lvm_infos.txt"
10pvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"
11lvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"

Probleme: Borg

Lange Zeit habe ich borg für meine Sicherungen benutzt. In der Vergangenheit hatte ich ein paar Unschönheiten, die ich aber lösen könnte. Irgendwann hatte ich Probleme meine Sicherung in die Cloud zu schieben; doch der Reihe nach.

Anderer Ort

Dadurch, dass ich meine Repos immer nur per rsync übertrage, nörgelt borg, wenn ich mal einen Blick in das Archiv werfen wollte, was auf einer externen Festplatte liegt.

1borg list bilder
2Warning: The repository at location /run/media/rainer/backup_hdd_1/backup_nuc/bilder was previously located at /backup/borgbackup/bilder
3Do you want to continue? [yN]

Vielleicht war es ein Bug oder es gab ein anderes Problem. Es gab mal eine Zeit, wo genau dieser der Zugriff außerhalb des Original-Ortes meiner Erinnerung nach verweigert wurde. Eine Lösung hatte ich damals gefunden. Durch das oben beschriebene Konzept mit rsync konnte ich es z.B. wieder an den ursprünglichen Ort kopieren. Danach war der Zugriff wieder möglich. Ich kann es derzeit nicht mehr nachstellen; aktuell scheint es wieder zu gehen, wenn die Frage einfach bejaht wird. Es ist mir negativ im Gedächtnis geblieben und es schwirrte schon lange die Idee in meinem Kopf herum, dass ich mich um eine Alternative zu borg kümmern müsse.

Große Dateien

Ausschlaggebend für den endgültigen Wechsel war ein Problem mit Backblaze¹ vor einiger Zeit.

Wie weiter oben beschrieben habe ich mehrere Repos. Eines der größeren Archive mit ca. 66 GB machte beim Upload nach B2 Probleme:

Das Logfile war sehr hilfreich - nicht:

1 data/0/31: Error sending chunk 0 (retry=true): incident id ec43eb366fa6-744fae19214412f6 (500 internal_error): &api.Error{Status:500, Code:"internal_error", Mes 

Ich lernte, dass es bei größeren Repos, wie dem 66 GB in meinem Fall, irgendwann recht große Dateien (ca. 500MB pro Stück) mit borg entstehen.

 1ls -hl data/0/ |head
 2insgesamt 46G
 3-rw------- 1 root root 503M 29. Sep 2022  10
 4-rw------- 1 root root 504M 11. Okt 2022  100
 5-rw------- 1 root root 503M 11. Okt 2022  101
 6-rw------- 1 root root 501M 11. Okt 2022  102
 7-rw------- 1 root root 503M 11. Okt 2022  103
 8-rw------- 1 root root 503M 11. Okt 2022  104
 9-rw------- 1 root root 502M 11. Okt 2022  105
10-rw------- 1 root root 504M 11. Okt 2022  106
11-rw------- 1 root root 501M 11. Okt 2022  107

Dieses führte beim Upload zu Backblaze¹ Problemen und warf daher mehrere Fehler beim Ausführen von rclone.

Bei meinen Recherchen in diesem Internet fand ich folgenden Blog-Artikel mit dem Titel What To Do When You Get a B2 503 (or 500) Server Error.

Im Grunde steht da nur stumpf, dass man es nach einer gewissen Zeit nochmal probieren soll. Nach ein paar Tagen mit dem selben Fehlerbild war ich genervt und las den Artikel nochmal genauer. Dort wird auf B2 error handling protocols verwiesen, wo unter dem Absatz “Multithreading Uploads” Hinweise in Bezug auf Dateien größer als 200 MB gegeben werden. Diese Dateien sollen beim Upload gesplittet werden und dann parallel hochgeladen werden. Ich vermute mal, dass das rclone unter der Haube macht; nachgeschaut habe ich nicht.

Bisher war nur ein Repo betroffen und andere Repos konnte ich problemlos nach Backblaze¹ hochladen bzw. synchronisieren mittels rclone.

Große Lust dem Backblaze-Support¹ hinterherzulaufen oder debugging im rclone-Umfeld zu betreiben, hatte ich nicht.

Umstieg auf restic

Damit war die Entscheidung gefallen; ich würde alle meine Backup-Scripte auf restic umstellen. Ein kleiner Test ergab, dass ein restic-Lauf zwar wesentlich mehr Dateien der selben Quell-Dateien ergab, aber auch wesentlich kleinere. Da ich alle meine Backups in einem Unterverzeichnis sammle, war die Analyse mittels find recht simpel.

1find borgbackup -size +200M | wc -l

Das Ergebnis: 816 Treffer.

Mein Testverzeichnis mit dem selbigen problembehafteten Dateien bzw. Repo in restic gebaut ergab keine Treffer

1find resticbackup -size +200M | wc -l

und es ging wesentlich schneller. Alleine der initiale Durchlauf beim allerersten Erstellen des Archivs war um Zeitfaktor 10 schneller. Es waren nur zwei statt zwanzig Minuten nötig, was mich zusätzlich bestärkt hat umzusteigen.

Erleichterungen

Um mich noch etwas unabhängiger im K-Fall zu machen, speichere zusätzlich das restic-Binary noch im Verzeichnis aller restic-Repos. Dieses wird dann ebenfalls via rsync mit auf die externen Festplatten kopiert, so dass ich immer eine aktuelle Version habe.

Für Neuigkeiten abonniere ich noch den RSS-Feed und habe einen Watcher auf die Github Releases. Aber das ist einen extra Blog-Artikel wert.

Tipps und Tricks zu Bedienung lege ich in eine extra Datei namens restic-hilfe.md. Hier stehen dann die wichtigsten Befehle zum Wiederherstellen der Dateien und zum Mounten des gewünschten Repos ins aktuelle Dateisystems.

Alles im Sinne der Stress-Reduzierung während eines potentiellen Recover-Scenarios.

Ende

Ich hoffe, ich konnte ein paar Einblicke in meine Überlegung zu meiner Backup-Strategie geben. Vielleicht hilft es dem einem oder anderen ein Konzept selbst zu überlegen oder sein oder ihr existierendes anzupassen.

Wenn Ihr ich jetzt nach den Scripten fragt, muss ich Euch auf die Zukunft vertrösten. Die Scripte selbst sind einen eigen Blog-Artikel wert.

Ausblick (Update)

Inzwischen habe ich auf den Chemnitzer Linux-Tagen einen Vortrag über restic gehalten. Auch habe ich vor demnächst^tm die Scripte auf resticprofile umzustellen. Über beide Tools erzähle ich was in meinem Vortag.

Changelog

Fußnoten

Beim Arbeiten mit vielen docker-compose.yml Dateien habe ich öfter die Anforderung gehabt, einzelne Images neu zu pullen. In der Regel reicht ein docker compose pull, was aber heißt, dass er alle images zieht.

Es gibt jedoch bei mir durchaus öfters den Fall, dass ich dies nicht möchte. Zudem hatte ich einige Container, wo nur auf ein bestimmtes Versions-Tag (z.B. mysql:8) gepulled wird oder ich sogar mit latest arbeite. Dies bedeutete, dass ich mir jedes Image einzeln aus der docker-compose-datei rauspfriemeln musste. Damit ich im Wiederherstellungsfall das alte Image schneller wiederfinde, wollte ich das speziell taggen. In der Regel habe ich an den Namen des Tags ein _backup dran gehängt. Vorher musste das vorherige Image mit diesem Tag gelöscht werden. Diese manuelle Arbeit habe ich nun in ein Script gegossen.

Update 30.11.2023: siehe unten Changelog

Das Script was auf GitLab liegt, durchpflügt die docker-compose.yml-Datei (parameterisierbar in der Datei) und fragt interaktiv nach, ob ein neues Image gepulled werden soll.

Wenn ja (default), dann legt das Script vorher ein “Backup” des Containers an, indem es an den Tag-Namen des aktuellen Containers ein _backup dran hängt. Vorher wird das evtl. vorhandene und so benannte Image noch gelöscht, damit die Festplatte nicht platzt. Das Suffix des Tags ist anpassbar im Script.

Bei jedem Durchlauf werden nochmal alle passenden Images angezeigt, damit alte Images nochmal aufgelistet werden. So fallen ungetaggte Images mit z.B. <none> leichter auf.

Die Ausgabe sieht dann z.B. so aus:

Update docker image: mysql:8 [j]|n: 
Lösche evtl. Backups
docker images mysql:8_backup
LINES_MIT_HEADER=2
lösche altes Image
docker image rm mysql:8_backup
Untagged: mysql:8_backup
Untagged: mysql@sha256:566007208a3f1cc8f9df6b767665b5c9b800fc4fb5f863d17aa1df362880ed04
Deleted: sha256:b2013ac9910129ded1da4c96495142b2ed0638ddf7e86e65156400d9a8503777
Deleted: sha256:d24171674816d2cdb9a7cfaf9980f3ba574930efe226ca7fa840084072974e08
Deleted: sha256:046ec448aa8eaaa27e4118211c9f77da24d35b8a84b25f997334c3473d14a870
Deleted: sha256:ab05f09658d83ed8ff487d346fcc9fa4cecf5a23906a7e7feffaea83a1332a14
Deleted: sha256:96db44e22a968a3a16890685d95bd96d420d99a8880966056721c36842fa38af
Deleted: sha256:402981938079002ce0b77d9fe7a892608155b3866ad1967313b4934d0d8a6d3c
Deleted: sha256:e38cf6d3efcf0edd5d80758556fdafa43e9e3136edbc05928febf8771b1cba31
Deleted: sha256:0d197db846f4e62ab3d29cef5d359f5896ddd6869ba49608f276741da328ef29
Deleted: sha256:121010cc4276929c2ba287fe57dfd0c61483862809dfc884c2aa3d998d6cc292
Deleted: sha256:b72678d2fc4485cc1febd27ab3cc6fe2ddc9ef62b2f016aaa8620040a339677f
Deleted: sha256:b42107e741524c1f305a1a4649a4d96a5921c48c5b8c438ad871ab7cc5815231
Lege Backup an 
docker tag mysql:8 mysql:8_backup
8: Pulling from library/mysql
210eb976c4c7: Pull complete 
ebb4c64fd647: Pull complete 
cb8397d67a0f: Pull complete 
ff0e9bc8aa4e: Pull complete 
e6f52b272e7f: Pull complete 
e2d9e8e437ee: Pull complete 
e61517738248: Pull complete 
cfb2700e7252: Pull complete 
4044404847dd: Pull complete 
c142db3aeff8: Pull complete 
Digest: sha256:1ee299bf9eb8d2218fcb4fad666a090c92caef48ce524e6edce35f2e2d55170d
Status: Downloaded newer image for mysql:8
docker.io/library/mysql:8
REPOSITORY   TAG        IMAGE ID       CREATED        SIZE
mysql        8_backup   8da80fe49fcf   4 weeks ago    577MB
mysql        8          2d9aad1b5856   2 months ago   574MB

Besonderheit

Bei einigen Containern arbeite ich mit konkreten Versionsnummern in den Tags.

Beispiel-Ausschnitt aus einer docker-compose.yml

1    image: onlyoffice/documentserver:7.5.1.1

In diesem Fall muss die obige Abfrage

Update docker image: onlyoffice/documentserver:7.5.1.1 [j]|n: 

mit n für nein beantwortet werden. Hier findet ja gerade eine Versionierung bzw. Backup über den Namen des Tags statt. Zudem kann ich hier schlecht die nächste Versionsnummer erraten. Weiterhin kann ja auch ein Überspringen einer Subversion gewünscht sein. Da die Images sowieso anhand Ihres Tags schon als Image-Version vorliegen, muss die Version somit im docker-compose.yml -File angepasst werden.

Dieses Script ist somit nur für die fixen Version-Strings wie oben bei mysql oder dem oben erwähnten lastest geeignet, erleichert aber meinen Alltag ungemein.

Changelog

Tipps und Tricks zum Editor vim.

• set ignorecase Groß-/Kleinschreibung egal
• set smartcase wenn Pattern kleingeschrieben: Groß-/Kleinschreibung egal, sonst case sensitive
• :set relativenumber relative Zeilennummern
• :set number Zeilennummern ein

 1colorscheme darkblue
 2nmap <F8> :TagbarToggle
 3nmap <F9> :!ctags *
 4
 5set backup
 6
 7" automatically indent lines (default)
 8" set noautoindent
 9set autoindent
10
11" select case-insenitiv search (not default) set noignorecase
12
13" Suchergebnisse hervorheben
14set hlsearch
15
16" show cursor line and column in the status line set ruler
17
18" show matching brackets
19set showmatch
20
21" show existing tab with 4 spaces width
22set tabstop=4
23" when indenting with '>', use 4 spaces width set shiftwidth=4 
24" On pressing tab, insert 4 spaces set expandtab
25
26" display mode INSERT/REPLACE/...
27set showmode
28
29" changes special characters in search patterns (default)
30" set magic
31
32" Required to be able to use keypad keys and map missed escape sequences set esckeys
33
34
35syntax on

Kochrezepte, Tipps und Hinweise zu Mastodon als kleine Sammlung.

Die Liste wird immer mal wieder erweitert; dabei wird dann hier das Datum einfach aktualisiert.

Unter Einstel­lungen -> Import und Export -> Export können auch die anderen Daten­kate­gorien (außer Medien) im CSV-Format herun­terge­laden werden, wie Blockierte Accounts, Listen oder Lese­zei­chen. Und das nicht nur, um sie bei einem geplanten Umzug ins neue Konto zu impor­tieren.

Regel­mäßige Backups sind auch wichtig für den Fall, dass die Instanz, auf der man ange­meldet ist, einmal über­raschend abge­schaltet werden sollte. Alle Daten­kate­gorien inklu­sive Medi­enspei­cher können einmal wöchent­lich als Archiv herun­ter­geladen werden. Die Zusammenstellung dauert einen Moment und der Download-Link wird per E-Mail zugesendet.

Nach diesem Script habe ich mich in den Anfängen meiner Linux-Zeit[^1) dumm und dämlich gesucht. Aus Nostalgie-Gründen (und vielleicht braucht man es ja doch noch mal, paste ich es hier nochmal rein. Alles andere kommt inzwischen ins git.

Aufgabe

Es ersetzt in allen Dateien der angegebenen Verzeichnisse, das per Parameter angegebene Suchmuster.

Gebraucht habe ich es mal für meinen HTML-Seiten wo ich "EUR" durch "€" ersetzen wollte.

Anwendung

1usage: gsed sed-command [dir ...]

sed-command entspricht dabei den normalen sed Parameter. Siehe man-Page.

Einige Anwendungsbeispiele:

1gsub s/EUR/\\\&euro\;/g # ====> EUR => €
2gsub s/\Ä/\\\&Auml\;/g # ====> Ä => Ä (Groß- Kleinschreibung beachten !)
3gsub s/\Ä/\\\&Auml\;/gi # ====> Ä => Ä (Groß- Kleinschreibung egal !)
4gsub s/\
5\<\\\/td\>/\<\\\/td\>/g # =====> <br></td> => </td>
6gsub s/http\:\\/\\/www./..\\/img/g # ====> http://www. => /img

Prinzip:

s/raus/rein/g

Weiterer Tipp

Und wenn das ersetzen nicht klappt ruhig mal öfters ein \ setzen, wie bei:

• \\\&
• \\/

Quell-Code

 1    #!/bin/sh
 2    #
 3    # Global sed on all files contained in a list of directories.
 4    # The command
 5    # gsub cmd dir1 dir2 ...
 6    # will do
 7     
 8    # sed -e cmd
 9    # on each file found in dir1, dir2, ...
10    #
11    # If a file is changed, a backup copy is created.
12    # Files .*.swp and CVS directories are skipped.
13     
14     
15    usage() {
16    echo "usage: gsed sed-command [dir ...]" >& 2
17    exit 1
18    }
19     
20    tmp=/var/tmp/gsub.$$
21     
22     
23    trap "rm -f $tmp" 0 1 2 3 15
24     
25    if [ $# -lt 1 ]; then
26    usage
27    fi
28     
29     
30    cmd="$1"
31     
32    shift
33     
34    if [ $# = 0 ]; then
35    set .
36    fi
37     
38     
39    find $* -name CVS -prune -o \( -type f ! -name '*~' ! -name '.*.swp' -print \) |
40    while read file; do
41    sed -e "$cmd" "$file" > "$tmp"
42    if cmp -s "$file" "$tmp"; then
43    :
44     
45    else
46    echo "$file: patched" >& 2
47    mv "$file" "$file~"
48    cp "$tmp" "$file"
49    fi
50     
51    done

Dank

Dank an Matthias Kilian von der LUG-Braunschweig :!:

Original-Ton aus seiner Mail:

Bitte nach Bedarf tunen. [Ja, ich weiß, dass es böse ist, das temporäre Verzeichnis fest zu verdrahten. Wer das nicht mag, kann ja zusätzliche TMPDIR auswerten.]

Das Script ist sogar so nett, nur Dateien, die sich wirklich geändert haben, zu überschreiben, bei unmodifizierten Dateien bleibt also die Modificationtime unverändert. Außerdem wird bei modifizierten Dateien eine Backupdatei angelegt.

Würde ich es heute noch mal schreiben, dann würde ich aber wohl statt sed(1) den ed(1) nehmen, um mir den ganzen Kram mit temporären Dateien zu ersparen.