Natürlich stellt sich hier irgendwann auch die Frage nach einer ordentlichen Backup-Strategie. Im Prinzip hat man ja eh auf jedem synchronisierten Gerät eine Sicherung, darauf verlassen wollte ich mich aber nicht unbedingt.
Eine Lösung musste her… was bietet sich mehr an, als meinen persönlichen Nextcloud-Ordner per WebDAV read-only auf einem meiner Server einzubinden und von dort mit Borgmatic zu sichern? Gesagt, getan und so begann eine kleine Odyssee…
Einbinden der Storage-Box
Diese simple Aufgabe habe ich vermutlich schon tausendfach erledigt in meiner Laufbahn. Kurz umreißen möchte ich dennoch, was genau ich getan habe, um die Nextcloud automatisch zu mounten.
Zuerst installieren wir dav2fs und erstellen einen Ordner, in dem die Nextcloud später erreichbar ist…
apt-get install davfs2
mkdir /mnt/nextcloud
Um die Freigabe automatisch mounten zu können, müssen wir unsere Zugangsdaten in der Datei /etc/davfs2/secrets hinterlegen. Falls ihr die Zwei-Faktor-Authentifizierung aktiviert habt, könnt ihr unter Einstellungen -> Sicherheit ein so genanntes App-Passwort erstellen – genau das habe ich auch getan.
In die oben genannte Datei fügen wir nun unsere Zugangsdaten ein.
Ich musste am Tag darauf meinen Server neustarten und beim starten begrüßte mich diese Meldung:
Give root password for maintenance (or press Control-D to continue)
Nach einem beherzten Druck auf Control-D lief der Start aber problemlos weiter und ich konnte mich einwandfrei anmelden. Alles sah okay aus, im Log gab es allerdings einen Eintrag, dass /mnt/nextcloud nicht gemounted werden konnte.
Das war der Moment, als es mir wie Schuppen von den Augen fiel. Die Einträge in der /etc/fstab werden regelmäßig vor’m Start des Netzwerkinterface ausgeführt, dann ist natürlich die Nextcloud „nicht erreichbar“ und der Systemstart wird blockiert.
Natürlich kann man das Problem, wie einige Blogeinträge im Netz es empfehlen, über ein noauto in der /etc/fstab und einen Eintrag in die /etc/rc.local umgehen… eleganter ist aber das Einfügen der Option _netdev in die /etc/fstab/, sodass der Eintrag so aussieht:
Die Option _netdev sorgt dafür, dass der entsprechende Mount erst nach dem Start der Netzwerkgeräte ausgeführt wird:
The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).
Genau das, was wir wollen – ohne Umweg über die rc.local! Jetzt kann ich damit beginnen, meine Nextcloud zu sichern… und ihr auch!
Ich überwache mit meiner Zabbix-Instanz mehrere Kundenserver, auf denen ISPConfig zur Verwaltung des Hostings genutzt wird. Leider hat ISPConfig die Angewohnheit, die Logfile-Ordner als Bind-Mount einzubinden – die Standard Discovery-Regel von Zabbix zur Erkennung von Dateisystemen legt also für jeden Bind-Mount mehrere Items an.
Mir bringt das keinen Mehrwert, weil die Parameter der Festplatten und Partitionen sowieso überwacht werden. Die Ordner möchte ich deshalb in der Discovery-Rule ignorieren.
Falls nicht jeder weiß, wovon ich spreche, hier ein Beispiel:
/var/www/clients/client1/web3/log
Wir beginnen damit, im Zabbix einen neuen Regulären Ausdruck zu hinterlegen.
Administration -> General -> Regular expressions
Konfiguration des regulären Ausdrucks
Name: Exclude FS Expression type: Result is FALSE Expression: ^/var/www/clients/client[\d]{1,4}/web[\d]{1,4}/log$
Weitere Optionen sind hier nicht notwendig. Wir wechseln zum Template – z.B.
Configuration -> Templates -> Template OS Linux -> Discovery rules -> Mounted filesystem discovery -> Filters
und hinterlegen dort unseren gerade angelegten regulären Ausdruck.
Konfiguration des Filters
Type of calculation: And Macro: {#FSNAME} Regular expression: @Exclude FS
Das Ganze wiederholen wir für das Template Template OS Virtual Linux und alle weiteren betroffenen Templates. Je nach Discovery- und Cleanup-Intervall werden die betroffenen Items nun von Zabbix deaktiviert und danach auch entfernt.
Auf manchen meiner Maschinen erstelle ich Datenbank-Sicherungen gerne zum Beispiel mit einem
mysqldump --all-databases > all.sql
Das hat den Vorteil, dass auch später angelegte Datenbanken automatisch gesichert werden und keine Anpassung von Skripten notwendig ist. Natürlich ist das nur für kleinere Datenbanken gangbar und hat den Nachteil, dass man beim Restore entweder den kompletten Datenbank-Server (also alle Datenbanken) einspielen muss oder aber per Hand (oder sed, awk, …) eine Datenbank oder Tabelle aus dem Gesamt-Dump rausfummeln muss.
Einfacher geht es mit dem, mir gerade vor der Füße gefallenen, mysqldumpsplitter.
MySQL Dump splitter to split / extract databases, tables, list from mysqldump with plenty of more funtionality.
Mehr macht das Skript wirklich nicht: es extrahiert einzelne Datenbanken oder Tabellen aus einer Gesamtsicherung und speichert die am gewünschten Ort. mysqldumpsplitter kann auch mit gepackten Dumps umgehen und extrahierte Daten auch direkt wieder packen. Ein Beispielaufruf sieht also z.B. so aus:
Zack, hat man nur die gewünschte Datenbank extrahiert und kann auch nur diese wieder einspielen.
Achtung!
MySQL hat auch die Optionen -D oder –one-database. Das klingt ja erstmal nach einem Verhalten, dass ich mir oben gewünscht habe – ist es aber nicht!
Ein Dump mit der Option –all-databases enthält für jede Datenbank die Statements
DROP DATABASE IF EXISTS dbname;
CREATE DATABASE dbname;
USE dbname;
Sofern ihr also z.B. die alphabetisch dritte Datenbank (nennen wir sie C) mit der Option –one-database wieder einspielt, werden die Datenbanken A und B geleert und nicht wieder befüllt. Das muss nicht, kann aber stark nach hinten losgehen – deshalb: wir bleiben beim mysqldumpsplitter.
Ich arbeite ja berufsbedingt oft auf Linux-Servern und nutze dafür den in macOS vorhandenen SSH-Client (in Verbindung mit iTerm 2, was aber hierfür nichts zur Sache tut).
Um bequemer zu arbeiten, habe ich mir mit der Zeit eine eigene SSH-Konfiguration zusammengewürfelt, um z.B. automatisch den Login-User, den SSH-Port oder einen Alias für bestimmte Hosts zu setzen.
Daraus folgt, dass ich mich zum Beispiel einfach ohne Angabe des Users, des SSH-Ports oder des vollen Hostname mit einem simplen
ssh management
an meinem Management-Server anmelden kann.
Leider hat macOS seit einigen Versionen eine unschöne Angewohnheit: bei Updates verschiebt es individuell angepasste Konfigurationen in einen Ordner „Neu zugewiesene Objekte“ auf dem Desktop (mehr dazu hier).
Die Lösung für dieses Problem ist allerdings denkbar einfach: die Änderungen an der SSH-Konfiguration einfach nicht in /etc/ssh/ssh_config eintragen, sondern in die Datei /Users/$USERNAME/.ssh/config – diese wird bei Updates nicht angefasst und die dort hinterlegten Änderungen sind dauerhaft.
