Die Secure Shell (SSH) ist eine bewährte Möglichkeit, auf entfernte Computer zuzugreifen. Man kann konfigurieren, ob der Zugriff mit name/passwort, und/oder mit einem public/private Schlüsselpaar erfolgen darf.

Server Konfiguration

Auf Linux-Computern ist der SSH Server häufig bereits installiert (Überprüfen mit sudo systemctl status ssh) Wenn nicht, kann man ihn mit sudo apt install openssh-server installieren.

Die Konfiguration findet sich in /etc/ssh/sshd_config und allfälligen zusätzlichen Dateien in /etc/ssh/sshd_config.d/

Jede Zeile dort ist eine Einstellung. Zeilen, die mit # anfangen, sind inaktiv, respektive auf den Standardwert gesetzt, der hinter dem # steht.

Von den vielen Einstellungen dort, sind in der Praxis nur wenige relevant:

    port 22

Wenn Ihr Computer direkt übers Internet erreichbar ist (was normalerweise aber eh nicht der Fall sein sollte), empfiehlt es sich, da eine andere Nummer einzutragen, zum Beispiel 36542 (Sie können jede Zahl zwischen 1025 und 65534 nehmen, aber einige sind schon für bestimmte Sienste reserviert). Der Grund ist, dass sehr viele automatisierte Attacken auf Port 22 erfolgen, und wenn der Robot merkt, dass an Port 22 tatsächlich Anfragen entgegengenommen werden, wird er seine Bemühungen verstärken, dort durchzukommen. Wenn Sie den SSH server gut konfiguriert haben, wird ihm das zwar nicht gelingen, aber die Abwehr der Angriffe wird Ihren Computer Rechenzeit und Ihren Internet-Anschluss Bandbreite kosten.

    PermitRootLogin no

Es empfiehlt sich, keinen Fernzugriff als Systemadministrator zu erlauben. Wenn Sie soch etwas administrieren müssen, können Sie sich als ein User mit sudo-Rechten einloggen und dann via sudo Admin-Rechte erlangen. Das ist eine zusätzliche Hürde.

    PasswordAuthentication yes

Wir benötigen das, um den Zugriff per Schlüsselpaar einzurichten. Danach sollteman es auf “no” setzen, um nur noch die Identifikation über Schlüssel zuzulassen

Alles Andere können Sie auf standard lassen. Schauen Sie aber noch ins Verzeichnis /etc/ssh/sshd_config.d/ und prüfen Sie auch die Dateien dort, wenn vorhanden. Die können nämlich die Einstellungen in der Hauptkonfiguration überschreiben.

Falls Sie etwas geändert haben, geben Sie anschliessend ein: sudo systemctl restart ssh, um die neuen Einstellungen zu laden.

Client Konfiguration

Der client braucht normalerweise für einfache Verbindungen keine Konfiguration. Das Programm ssh ist auf Linux und Mac computern bereits installiert, auf Windows 11 ebenfalls. Bei älteren Windows-Versionen können Sie sich mit putty.exe behelfen.

Die Verbindung stellen Sie einfach mit ssh servernameher. Der SSH Client wird dann versuchen, Sie auf dem Server mit demselben Benutzernamen einzuloggen, denn Sie auf dem clienht-Computer haben. Wenn das nicht der Fall ist, können Sie mit ssh user@servernamefestlegen, als welcher Benutzer Sie sich einloggen wollen.

Nach eingabe des Passworts sind Sie auf einem Terminal des entfernten Computers eingeloggt, als wären Sie direkt vcor dem Bildschirm. Allerdings ohne grafische Oberfläche.

Schlüssel erstellen

Wenn die Verbindung auf diese Weise gekungen ist, sollten Sie als nächstes ein Schlüsselpaar erstellen. Dadurch wird die Verbindung sicherer und komfortabler.

    ssh-keygen -o -a 100 -t ed25519

Geben Sie am besten einen eindeutigen Dateinamen ein. Ich wähle hier ~/.ssh/serverkey als Bsispiel. Die Passphrase kann die Sicherheit erhöhen, aber Sie müssen sie dann jedesmal eingeben, Sie können auch einfach die Eingabetaste drücken, dann wird der Schlüssel ohne passphrase erstellt.

Sie erhalten zwei Dateien, in meinem Beispiel serverkey und serverkey.pub, beide im (versteckten) Verzeichnis .ssh in Ihrem Benutzerverzeichnis.

Nun müssen wir dem Server bekannt geben, dass dies der richtige Schlüssel ist. Dazu geben wir ihmd en öffentlichen Schöüssel (Der private Schlüssel sollte den Computer niemals verlassen, auf dem er erstellt wurde).

Auch diese Bekanntgabe kann man automatisieren:

    ssh-copy-id -i ~/.ssh/serverkey.pub user@servername

Sie werden noch einmal nach Ihrem Passwort gefragt, und dann wird mit diesem Befehl der öffentliche Schlüssel in der Datei .ssh/authorized_keys des genanten users gespeichert.

Testen Sie, ob es geklappt hat:

    ssh -i ~/.ssh/serverkey servername

Das Login sollte jetzt ohne Passwortabfrage erfolgen (Ausser, wenn Sie eine Passphrase für den Schlüssel angegeben haben, dann müssen Sie diese eingeben).

Wenn alles geklappt hat, können Sie auf dem Server die Datei /etc/ssh/sshd_config nochmal öffnen und die Zeile PasswordAuthenticationauf “no” stellen. Danach die neue Einstellung mit systemctl restart ssh aktivieren.

Von nun an können Sie nur moch mit dem eben erstellten Schlüssel auf den Server zugreifen. Falls es sich um einen Server handelt, auf den Sie keinen physischem Zugriff haben, weil es zum Beispiel ein gemieteter virtueller Server ist, dann tun Sie gut daran, einen zweiten Benutzer mit Adminrechten zu erstellen, und auch diesem ein SSH-Schlüsselpaar zuzuteolen, damit Sie nicht ausgesperrt bleiben, wenn Sie als Hauptbenutzer etwas falsch machen.

Konfigurationsdatei

Der ssh-Befehl hat voele mögliche Optionen, die sie zum Beispiel mit man ssh oder auf der entsprechenden Website nachlesen können. Da es schwierig ist, sich das zu merken, falls Sie mehrere Optionen benötigen oder merhere Server eibgerichtet haben, können Sie Ihre Einstellungen in einer Konfigurationsdatei eintragen. Erstellen Sie dazu die Datei ~/.ssh/config.

Dort können Sie für jeden Server einen eigenen Eintrag erstellen. Beispiel:

Host mycloud
        HostName cloud.myfamily.somewhere
        User snoopy
        Port 28652
        # Solr
        LocalForward 48983 127.0.0.1:8983
        # Couchdb 
        LocalForward 45984 127.0.0.1:5984
        # Syncthing
        LocalForward 48384 127.0.0.1:8384
        # Minio
        LocalForward 49000 127.0.0.1:9000
        IdentityFile /home/icke/.ssh/cloudkey

Host homeserver
        HostName 192.168.0.63
        User icke
        IdentityFile /home/icke/.ssh/homeserver

Dann können Sie fortan die Verbindung mit einem simplen ssh mycloud herstellen. Und das gilt auch für andere Dienste, die ssh indirekt nutzen. Beispielsweise können Sie mit rsync -av --delete mycloud:/home/pi /srv/backup/ ein Verzeichnis Ihres Heimservers via SSH sichern. Denken Sie aber daran, dass Sie auf dem entfernten Server immer mit den Rechten des Users unterwegs sind, als der Sie sich eingeloggt haben.Sie werden also z.B. so nicht aufs /root Verzeichnis zugreifen können.

Ein Reverse Tunnel dient dazu, eine SSH-Verbindung vom Server zum Client aufzubauen, also umgekehrt, als man das normalerweise tut. Das ist nützlich, wenn der Server von aussen nicht direkt erreichbar ist, und darum selber die Verbindung initiieren muss.

Beispiel 1

Nehmen wir an, ich habe einen Heim-Server, der gut geschützt hinter einer Firewall sitzt. Ich möchte aber dennoch eine Möglichkeit, eine SSH-Verbindung zu ihm aufzubauen. Dazu benötige ich einen im Internet erreichbaren Computer als Proxy.

Ich habe also

• Meinen Heimserver, dessen IP.-Adresse ich nicht kenne, und der sowieso nicht von aussen erreichbar ist, und der auf port 22 einen SSH-Server laufen hat.
• Meinen Proxy, der unter https://mein.computer.irgendwo erreichbar ist, und der nichts von meinem Heimserver “weiss”.

Ziel: Ich möchte mit ssh -i schlüssel -p 1999 mein.computer.irgendwo indirekt auf heimserver:22 kommen.

Vorgehen:

• Ich erstelle ein SSH-Schlüsselpaar, um den Zugriff möglichst sicher zu gestalten.
• Dann sorge ich dafür, dass der Proxy auf port 12445 erreichbar ist, zum Beispiel mit einer Portweiterleitung auf dem Router von 12445 auf Port 22 (SSH) des Proxy-Computers. Eine zweite Portweiterleitung mache ich von 1999 auf 1999 des Porxy-Computers.
• Und kopiere den öffentlichen Schlüssel des vorhin erstellten Schlüsselbars auf den Proxy: ssh-copy-id -i <public key> -p 12445 ich@mein.computer.irgendwo.
• Schliesslich schalte ich in der ssh-konfigurationsdatei des Proxy die passwor-authentication aus, so dass er immer den Schlüssel verlang.

Soweit die Vorarbeiten. Den Tunnel erstellt man dann so (auf dem Heimserver eingeben):

ssh -p 12445 -i <private key> -R 1999:localhost:22 ich@mein.computer.irgendwo

Wenn man dann irgendwo im Internet `ssh -p 1999 -i ich@mein.computer.irgendwo' eingibt, dann landet man direkt auf Port 22 des Heimservers.

Beispiel 2

Nehmen wir an, Sie möchten, dass die Web-Oberfläche Ihres Heimservers auch von aussen erreichbar ist, zum Beispiel wenn Sie im Urlaub sind. Leider sieht Ihr Internet-Provider keine Möglichkeit vor, Ihren Router von aussen zu erreichen. Sie müssen sich also mit einem Reverse-Tunnel zu einem Proxy-Computer verbinden, der vopm Internet aus erreichbar ist. So einen (virtuellen) Computer können Sie bei vielen Providern günstig mieten, die einzige Bedingung für unsere ZWecke ist, dass Sie Shell-Zugriff haben. Dann brauchen Sie eine Domain (wie www.pseudoproxy.irgendwo), die Sie auf den Mietserver zeigen lassen (Kann meist beim selben Provider gebucht werden, wie der webspace).

Wir wollen also, dass ein Zugriff auf http://www.pseudoproxy.irgendwo umgeleitet wird auf den Heimserver, dessen IP-Adresse mnicht bekannt ist.

Vorgehen:

• Richten Sie den Shell-Zugriff auf dem Mietserver ein, idealerweise mit einem SSH-Schlüsselpaar wie oben gezeigt.
• Geben Sie auf Ihrem Heimserver ein: ssh -fN -R 80:localhost:80 ich@pseudoproxy.irgendwo

Allgemeine Erwägungen

• Der SSH-Zugriff sollte wenn immer möglich nicht über Passwörter, sondern über Schlüsselpaare geschehen.
• SSH-Server neigen dazu, die Verbindung ab und zu abzubrechen. Es empfiehlt sich daher, die Tunnelerstellung in ein watchdog-Skript einzubauen, etwa so:

#!/bin/bash

# Set the ports to check on the remote server
REMOTE_PORT=21234
LOCAL_PORT=2456
REMOTE_CONFIG=myserver
REMOTE_URL=my.server.url

# Check if the remote port is reachable
nc -z "$REMOTE_URL" "$REMOTE_PORT" > /dev/null 2>&1

if [ $? -eq 0 ]; then
    echo "Remote port $REMOTE_PORT is reachable at `date`" >>tunnel.log
else
    echo "Remote port $REMOTE_PORT is unreachable at `date`" >>tunnel.log
    # Attempt to create a new tunnel
    ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -R "$REMOTE_PORT":localhost:$LOCAL_PORT $REMOTE_CONFIG -fN &
    if [[ $? -eq 0 ]]; then
        echo "New tunnel created successfully at `date`" >>tunnel.log
    else
        echo "Error creating new tunnel: $? at `date`" >>tunnel.log
    fi
fi

Und dieses Watchdog-Skript über einen Cronjob zum Beispiel halbstündlich laufen zu lassen.

Eine Website zu publizieren, ist einfach: Es gibt viele Anbieter, die entsprechende Hosting-Angebote für wenig Geld bereitstellen, und oft auch verschiedenene Hilfen zum Erstellen der Seiten anbieten. Wenn man allerdings eine grössere Anzahl von unabhängigen Sites hosten möchte, braucht man entweder mehrere Anbieter, oder ein “stärkeres” Angebot, welches mehrere Domains mit mehreren Urls erlaubt. Noch schwieriger wird es, wenn man WebApps hosten möchte, zum Beispiel eine eigene Cloud mit OwnCloud oder Nextcloud, oder eigene NodeJS-Apps. Dann braucht man einen Hoster, der es erlaubt, NodeJS und/oder Docker laufen zu lassen, und der genügend Speicher bereitstellt. Da wird die Luft schon dünner, und immer wieder stösst man auf unerwartete Beschränkungen und recht hohe Kosten.

Nun haben ja die meisten von uns inzwischen eine recht leistungsfähige Internet-Anbindung, die mit dem Datenaufkommen einer Familie oder eines Vereins ohne Weiteres fertig würde. Was liegt also näher, als die zu hostenden Dienste auf einem eigenen Computer bereitzustellen? Dann ist es kein Problem mehr, ein Terabyte oder mehr “cloud”- Speicher und beliebig viele Websites und Webapps anzubieten.

Allerdings sei gleich ein ernstes Wort vorweg gesprochen: Eine Zugriffsmöglichkeit von aussen ist auch eine Angriffsmöglichkeit von aussen. Wenn Sie Dienste anbieten wollen, sollten Sie diese Dienste auf einem Computer laufen lassen, der keine anderen Computer in Ihrem Netzwerk erreichen kann.

Der Internet-Anschluss

Es gibt Anbieter, die den Zugriff von aussen ohne Weiteres zulassen, und es gibt solche, die das nicht tun. Welchen Typ Sie haben, können Sie so herausfinden:

• besuchen Sie die Seite https://www.whatismyip.com/. Diese Seite zeigt Ihnen an, unter welcher IP-Adresse Sie aktuell im Internet eingebucht sind.
• Öffnen Sie ein Terminal und geben Sie dort ein: ping <IP-Adresse>. Wenn irgendeine Antwort kommt, dann ist Ihr Router grundsätzlich erreichbar. Wenn Ping keine Antwort liefert, müssen Sie sich mit einem Reverse-Tunnel behelfen.

Als nächstes müssen Sie sicherstellen, dass Ihr Server oder Proxy überhaupt gefunden werden kann. Dazu benötigen Sie einen sogenannten DNS-Eintrag, der aus einem Namen wie www.meinserver.irgendwo eine IP-Adresse wie 14.145.28.10 macht. Wenn Sie den Proxy samt Domain bei einem Internet-Provider gemietet haben, ist dieser Schritt bereits erledigt. Andernfalls müssen Sie einen dynamischen DNS Eintrag erstellen, der auch dann, wenn Ihre IP vom Provider gewechselt wird, immer angepasst wird. Die meisten aktuellen Router sind in der Lage, ohne spezielle Konfiguration mit verschiedenen DynDNS-Providern zusammenzuarbeiten (Schauen Sie im Menü Ihres Routers nach, hier zum Beispiel das Vorgehen bei Fritz!Boxen)

Der Server

Was für einen Computer benötigen Sie als Server für, sagen wir, 5 Websites, eine NodeJS-App und einen Docker-Container mit NextCloud? Verblüffend wenig: Ein Raspberri Pi 4 mit 4GB Ram genügt. Wie oben gesagt soll der Computer möglichst keine Verbindung zu Ihrem restlichen Netz haben. Manche Router und Switches gestatten es, für solche Zwecke, eine sogenannte “Demilitarisierte Zone” (DMZ) einzurichten, die logisch vom restlichen LAN völlig getrennt ist. Wenn das nicht geht, sorgen Sie zumindest dafür, dass auf dem Server keinerlei Daten gespeichert sind, die den Zugriff auf andere Computer ermöglichen, und dass alles im Netz passwortgeschützt ist. Und natürlich soll der Server zu nichts anderem, als zum Ausliefern der Websites dienen. Er soll auf keinen Fall noch nebenher als Heimserver, Smarthome-Hub oder Bürocomputer dienen. Wenn er gekapert wird, dann soll der ANgreifer nichts anderes als diesen Computer zerstören können. Und den können sie ja leicht wieder aufsetzen (Wenn Sie für regelmässige Backups sorgen).

Setzen Sie den Raspberry auf, am besten mit einem minimalen OS. (Serverdienste brauchen kein UI). Wenn Ihr Router von aussen erreichbar ist, müssen Sie eine Portweiterleitung auf den Server einrichten, wenn nicht, auf dem Server einen Reverse Tunnel zu einem externen Proxy aufbauen.

Der Verteiler

Angenommen, Sie haben 5 Websites, eine NodeJS-App und einen Nextcloud-Container laufen. Woher weiss der Server denn, welche Seite er einem Besucher ausgeben soll? Dafür richten wir einen Reverse Proxy auf dem Server (oder einem anderen Computer) ein. Das ist nicht zu verwechseln mit dem Reverse Tunnel, über den wir weiter oben gesprochen haben. Der Reverse Proxy entnimmt dem Header jeder Anfrage die Information, welcher Dienst gemeint war, und sendet sie zum entsprechenden “virtuellen Server” weiter.

Nun nehmen wir mal an, wir haben die Webseiten “meine-familie.ch”, “mein-verein.ch”, den Webservice “agenda.meine-familie.ch” und den Clouddienst “cloud.meine-familie.ch”

Dann benötigen wir folgende Konfigurationen in /etc/apache2/

1: Definition für den nextcloud-Container, der auf Port 8082 erreichbar ist: /etc/apache2/sites-available/cloud.conf: (Der Dateiname ist egal)

<VirtualHost *:80>
	ServerName cloud.meine-familie.ch
	ProxyPreserveHost On
	ProxyPass / http://localhost:8082/
	ProxyPassReverse / http://localhost:8082/
</VirtualHost>

Hier leiten wir Anfragen für cloud.meine-familie.ch auf Port 80 auf einen Serverprozess um, der auf demselben Server auf Port 8082 läuft. Man könnte ohne Weiteres statt localhost auch einen anderen im gleichen Netz erreichbaren Computer einsetzen. Eine solche Konfiguration kann zum Beispiel unabhängige Docker-Applikationen, oder eigenständige Web-Apps ansteuern.

2: Definitionen für die Website ‘meine-familie.ch’ und ‘mein-verein.ch’ /etc/apache2/sites-available/familienseite.conf

<VirtualHost *:80>
        ServerName meine-familie.ch
        ServerAlias www.meine-familie.ch
        DocumentRoot "/var/www/family/http"
        CustomLog /var/www/family/log/access.log combined
</VirtualHost>

/etc/apache2/sites-available/vereinsseite.conf

<VirtualHost *:80>
        ServerName mein-verein.ch
        ServerAlias www.mein-verein.ch
        DocumentRoot "/var/www/verein/http"
        CustomLog /var/www/verein/log/access.log combined
</VirtualHost>

Hier bedient der Apache Server die Anfragen selbst. Wir sagen ihm nur, in welchem Verzeichnis er die Dateien finden kann, die er ausliefern soll, und in welches Verzeichnis er seine Logdateien schreiben soll. Im Verzeichnis /var/www/family/http sollte mindestens eine index.html - Datei zu finden sein, damit die Seite funktioniert. Diese Konfiguration würde auf http://meine-familie.ch und auch auf http://www.meine-familie.ch reagieren (Wegen der ServerAlias-Direktive)

Die anderen benötigten Sites können Sie analog definieren.

Im Moment sind unsere Konfigurationen aber noch nicht aktiv. Wir aktivieren sie mit

sudo a2ensite cloud familienseite vereinsseite
sudo systemctl reload apache2

Das tut eigentlich nichts anderes, als entsprechende Symlinks von sites-available in sites-enabled zu erstellen. Um eine Seite wieder zu deaktivieren, können Sie a2dissite <konfiguration> eingeben und danach mit systemctl reload apache2 die Änderung scharf stellen.

Wie kommt nun die Anfrage eines externen Browsers auf diese Seite?

1. Der User will zu http://meine-familie.ch navigieren.
2. Der Browser fragt beim DNS-Server nach der Adresse.
3. Der DNS-Server fragt beim Registrar der Domain meine-Familie.ch nach dem zuständigen Nameserver
4. Der Nameserver kann z.B. ein DynDNS-Server sein, der von unserem Router die aktuelle IP erhalten hat. Oder, bei einer fixen Adresse, kann er direkt die IP ausgeben.
5. Der Browser steuert diese IP auf Port 80 an (Das ist der Standard-Port für HTTP). Dort wartet der Router unseres Internetzugangs
6. Der Router hat eine Portweiterleitung für Port 80 und Port 443 (dazu kommen wir später) auf unseren Heimserver.
7. Dort wartet der Apache Webserver und schaut im Header der Anfrage nach, welchen von den verschiedenen Hosts, die er verwaltet, der Browser eigentlich haben wollte.
8. Wenn er ihn findet, sendet er die Anfrage weiter und gibt dessen Antwort zurück. Wenn nicht, liefert er eine “Nicht gefunden” Antwort.

Damit sind wir fast am Ende dieses Kurses. Aber mehr als nur ein Schönheitsfehler ist es heutzutage, eine Seite per http erreichbar zu machen. Standard ist die verschlüsselte Kommunikation via https bzw. SSL Dabei funktioniert praktisch alles gleich, nur dass der Port 443 statt 80 angesteuert wird, und die Kommunikation über ein Verfahren stattfindet, das einerseits die Identität des Servers sicherstellt und andererseits alle übermittelten Daten verschlüsselt.

SSL war früher eine teure Sache, weil man eine Firma brauchte, die prüfte, dass man der ist, der eine Seite rechtmässig betrieb, und dies mit einem Zertifikat des öffentlichen Schlüssels bestätigte. Eine ausführlichere Erläuterung zu SSL/HTTPS und Zertifikaten finden Sie hier.

Heute ist alles ein wenig einfacher geworden: Es gibt jetzt Letsencrypt. Das ist ein kostenloser Dienst, der Schlüssel für Webseiten zertifiziert, nachdem er sich beweisen lässt, dass der Antragssteller den Inhalt der Seite oder des Name-Servers manipulieren kann. Solche Tests sind automatisierbar. Alles was man dazu braucht, ist der Certbot

sudo apt install certbot

und dann:

certbot --apache

Certbot zeigt dann alle Sites an, die er in der laufenden Apache-Konfiguration finden kann, und Sie brauchen bloss anzugeben, welche Sie absichern wollen.

Wenn alles gut geht, schreibt der certbot eine neue Konfiguration wie z.B. /etc/apache2/sites-available/familienseite-le-ssl.conf und verändert die bestehende Konfiguration familienseite.conf so, dass Anfragen über http:// direkt auf https:// umgeleitet werden.

Wenn Sie sich jetzt wieder mit Ihrer Seite verbinden, werden Sie sehen, dass der Browser ein Schloss neben der Adresse anzeigt, und wenn Sie dieses Schloss anklicken, können Sie das Zertifikat ansehen, das Letsencrypt ausgestellt hat.

Diese Zertifikate sind immer nur drei Monate gültig, aber certbot kümmert sich selber darum, sie jeweils rechtzeitig zu erneuern. Nur wenn Sie eine weitere Site erstellen, müssen Sie certbot wieder manuell bemühen.

Auf diese Weise können Sie im Grunde beliebig viele Serverdienste selber bereitstellen. Die einzige fremde und Hilfe, die Sie dazu brauchen, ist ein DynDNS-Dienst. der Ihren Server auffindbar macht.

Grundlagen

Datensicherung ist nie überflüssig. Jede Computer-Festplatte wird irgendwann defekt sein. Leider weiss man nicht wann. Die Ausfallrate ist am Anfang relativ hoch (wegen Produktionsfehlern), sinkt dann auf sehr geringe Werte ab und steigt ab etwa dem dritten Jahr wieder an. Die Datenspeicherungs-Firma Backblaze gibt regelmässig Lebensdauerwerte ihrer derzeit rund 100000 Festplatten an: https://www.backblaze.com/blog/2018-hard-drive-failure-rates/. Die durchschnittliche jährliche Ausfallrate wird mit rund 1.7% errechnet, wobei die Firma ihre Platten jeweils nach etwa 4 Jahren austauscht.

Bei SSDs gibt es naturgemäss noch weniger Daten, als bei magnetischen Festplatten, aber es ist bekannt, dass jede SSD-Speicherzelle nur eine limitierte Zahl von Schreibvorgängen aushält (die allerdings immerhin wesentlich grösser ist, als früher angenommen).

Wie auch immer: Das Prinzip Hoffnung ist verkehrt, wenn es um wichtige Daten geht. Und es nützt auch nicht viel, ein RAID statt einer einzelnen Platte zu verwenden. Einige Überlegungen dazu habe ich hier zusammengefasst.

Bevor wir uns für ein Datensicherungskonzept entscheiden, brauchen wir einen Anforderungskatalog:

Das Backup-System muss folgende Eingenschaften haben:

• Vom Hauptsystem unabhängig - Wir müssen ja auf die Daten auch dann zugreifen können, wenn nicht nur die Platte, sondern der ganze Server ausfällt.

• Versioniert - Wir brauchen nicht nur den momentanen Stand, sondern auch einige ältere Versionen. Stellen Sie sich vor, ein Erpressungs-Trojaner oder ein Hardware-Defekt oder eine Fehlbedienung zerstört einen Teil Ihrer Daten, und Sie merken das erst nach dem Backup - Ein einzelnes Backup wäre dann auch gleich zerstört. Dann muss es die Möglichkeit geben, eine ältere Version einzuspielen.

• Verschlüsselt - In der Datensicherung sind exakt dieselben Daten, wie im Hauptsystem, und diese müssen genauso sicher gegen unerlaubten Zugriff gesichert sein.

• Automatisierbar - Wenn Sie dran denken müssen, ein Backup anzufertigen, dann werden Sie es manchmal vergessen. Und Murphy’s law garantiert, dass der Server genau dann kaputt geht, wenn das letzte Backup länger als zwei Wochen her ist.

• Wiederherstellbar - Das ist natürlich eine Binsenweisheit. Was nützt ein Backup, das nicht wiederhersgestellt werden kann? Leider ist es durchaus nicht selbstverständlich. Backups laufen ja, wie oben betont, idealerweise automatisch ab, zum Beispiel mit einem nächtlichen Hintergrund-Job. Je nachdem passiert dabei ein Fehler und niemand sieht die Fehlermeldung… Und wenn Sie an den Punkt Verschlüsselung denken: Sie müssen sicher sein, dass die Verschlüsselung auch wieder entschlüsselt werden kann. Dazu gehört, dass Sie ein Programm benötigen, das den angewendeten Algorithmus beherrscht, und Sie müssen sich auch nach 10 Jahren noch an das verwendete Passwort erinnern. Und last but not least müssen auch die verwendeten Speichermedien mit dem Computer, den Sie in 10 Jahren benutzen werden, noch lesbar sein. Auch das ist nicht so selbstverständlich, wie man meinen könnte: Wenn Sie vor 20 Jahren Ihre Daten auf den damals weit verbreiteten Floppy Disks gespeichert haben, dann werden Sie heute echte Probleme haben, an diese Daten wieder heranzukommen. Und zwar sogar dann, wenn Sie auch ein Laufwerk für solche Floppy Disks aufbewahrt haben: Sie werden es an Ihren heutigen PC nicht anschliessen können. Und wenn Sie Ihre Datensicherung auf CDs oder DVDs speichern, dann ist die Gefahr nicht vernachlässigbar, dass diese wegen Alterung des Trägermaterials nach 10 Jahren nicht mehr vollständig lesbar sind. Dasselbe gilt für magnetische Platten, wo das entsprechender Altzerungsproblem “Bitfäule” genannt wird. Einzelne kaputte Bits sind bei normalen Dateien nicht schlimm - Ein Text ist immer noch lesbar, wenn das eine oder andere X zu einem U wurde. Bei verschlüsselten Dateien aber ist alles verloren, wenn auch nur ein einziges Bit kippt. Denn dann “passt” der Schlüssel nicht mehr.

Backup-Konzepte

Plattenrotation

Eine tragbare Festplatte nimmt jeweils ein Backup auf und wird dann gegen eine andere identische Platte ausgetauscht. Wenn man beispielsweise fünf solcher Platten verwendet, kann man an jedem Arbeitstag eine andere einsetzen, und auf jeder vielleicht 10 Datensicherungs-Generationen speichern, die dann jeweils eine Woche auseinander liegen. Damit wird der Verlust jeder einzelnen Platte oder sogar mehrere Platten verschmerzbar. Idealerweise lagern Sie die Platten auch an verschiedenen Orten, so dass auch bei einem Einbruch oder Brand nicht alles verloren ist.

• Vorteil: Dadurch, dass Sie jede Platte immer wieder verwenden, ist sichergestellt, dass sie funktionieren. Trotzdem möchten Sie sie vielleicht nach etwa 5 Jahren auswechseln, wenn das Risiko eines Ausfalls grösser wird.

• Nachteil: Man muss doch wieder an etwas denken… Wenn man vergisst, die Platten auszutauschen, baut man ein “Klumpenrisiko” mit der gerade angeschlossenen Platte auf, und gemäss Murphy werden Sie erst merken, dass diese Platte kaputt ist, wenn auch Ihre Server-Festplatte aussteigt, und Sie ein möglichst aktuelles Backup benötigen.

Fernbackup

Sie können Ihre Daten mit einem geeigneten Programm auf einen oder mehrere andere Computer sichern. Dies kann man genauso leicht automatisieren, wie die Sicherung auf eine externe Festplatte.

• Vorteil: Keine zusätzliche Hardware am Praxis-System, man muss nicht an Plattentausch etc. denken.

• Nachteil: Das Backup wird viel länger dauern, da das Netzwerk langsamer ist, als eine angeschlossene Fewstplatte. Weiterer Nachteil: Murphy wird dafür sorgen, dass der Internetzugang just dann schnarchlangsam oder ganz ausgefallen ist, wenn Sie Ihr Backup dringend zurückspielen wollen.

Cloud-Backup

Statt auf einen eigenen Server können Sie die Daten auch in einer Cloud speichern. Das ist seitens des Backup-Systems kein Unterschied.

• Vorteil: Sie müssen sich nicht um Aufbau und Unterhalt des Backup-Servers kümmern. Die Cloud Anbieter garantieren eine sehr hohe Verfügbarkeit und Datensicherheit.

• Nachteile: Die Daten sind für den Cloud-Anbieter sichtbar. Sie müssen sie also unbediungt vor der Übertragung verschlüsseln. Ok, das müssen Sie eigentlich sowieso tun. Weiterer Nachteil: Sie sind darauf angewiesen, dass es den Cloud-Anbieter in 10 Jahren noch gibt, und dass Sie noch Zugang darauf haben. Und last but not least: Die Datensicherung wird hier etwas kosten. Allerdings meist wesentlich weniger, als ein eigener Server oder auch nur eine Backup-Festplatte kosten würde.

Selbstverständlich können Sie anstelle der Cloud eines professionellen Anbieters auch eine eigene Cloud aufbauen, damit wird die Cloud-Speicherung zu einer Variante des weiter oben erwähnten Fernbackup.

Backup-Anwendungen

Für welches der oben genannten Backup-Konzepte Sie sich entscheiden, hängt zu sehr von Ihrem individuellen System ab, als dass man allgemeingültige Empfehlungen abgeben könnte.

Ich selbst bevorzuge ein dreistufiges Konzept:

• Stufe 1: Plattenrotation und Fernbackup. Ich wechsle zwischen Wechselplatten und der Speicherung auf externe Computer ab. Als Backup-Programm verwende ich rsync und restic. Die Steuerung wird von einem Cron-Job erledigt, der nachts aktiv wird.

• Stufe 2: Cloud Backup. Aus praktischen Gründen verwende ich hier Amazon S3. Das ist ziemlich günstig (etwa 30 US-cent pro GB und Jahr) und kann von meinem ohnehin benutzen Backup-Tool restic direkt genutzt werden. Aber natürlih kann man ebenso gut andere Anbieter bevorzugen, etwa Google Cloud Storage, Microsoft Azure Storage oder andere.

• Stufe 3: “Cold Backup”. Daten, die ich voraussichtlich länger nicht oder nie mehr brauche, kommen in den Amazon Glacier. Das ist noch billiger als S3 (weniger als 5 US-cent pro GB und Jahr), hat aber den Nachteil, dass das Zurückholen der Daten erstens einige Zeit dauern kann (Stunden bis Tage), und dass es etwas kostet, die Daten wieder zu holen (Derzeit je nach gewünschter Geschwindigkeit etwa 0.5-3 cent pro GB). Wenn man die Daten ausnahmsweise doch mal sehr schnell benötigt, muss man zusätzlich 100 Dollar für die Express-Bereitstellung bezahlen.

Zusammenfassung

Der Aufbau eines Backup-Konzeptes ist einer der wichtigsten Punkte beim Design Ihres Computersystems, sofern Sie damit mehr als nur spielen wollen. Es gibt natürlich wie üblich viele Möglichkeiten, darunter auch Programme, die mit einer minimalen Konfiguration alles selbsttätig erledigen. Allerdings sind bei solchen System die Backups manchmal auch nur mit denselben Systemen lesbar, und die Prozesse manchmal etwas undurchsichtig. Im Prinzip kann man ohne Weiteres alles “von Hand” machen. Als Ausgangs- oder Anhaltspunkt zeige ich Ihnen hier einige Backup-Skripte für einen Linux-Server, die man z.B. mit einem cronjob laufen lassen kann:

Stufe 1 Backup

alle relevanten Datenbanken und Verzeichnisse sichern

#! /bin/bash

echo `date` begin /root/newbackup.sh >>/srv/public/current.log

export log=/root/backup.log
export resticlog=/root/restic.log
export err=/root/error.log

echo ==============  /root/newbackup.sh =================  >$log
echo `date` begin backup >>$log
echo `date` >$resticlog
echo `date` >$err

set -o errexit

echo 1 dump databases >>$log
./newdump.sh

echo 2 `date` restic /home,/etc, /root and /var/spool/crontabs to /mnt/store/system >>$log
restic -r /mnt/store/system -p /root/resticpwd backup /home /etc /root /var/spool/cron/crontabs 2>$err

echo 3 `date` restic /srv and /opt/apps to /mnt/store/data >>$log
restic -r /mnt/store/data -p /root/resticpwd backup /srv /opt/apps 2>$err

echo 4 `date` restic /var/www files to /mnt/store/www >>$log
restic -r /mnt/store/www -p /root/resticpwd backup /var/www 2>$err

############################
# cleanup Restic repositories
############################
echo  5 `date` cleanup restic data repositories >>$log
echo 5a system >>$log
restic -r /mnt/store/system -p /root/resticpwd forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 20 >>$resticlog
echo 5b data >>$log
restic -r /mnt/store/data  -p /root/resticpwd forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 20 >>$resticlog
echo 5c www >>$log
restic -r /mnt/store/www -p /root/resticpwd forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 20 >>$resticlog

echo 6 `date` backup mailcow >>$log
MAILCOW_BACKUP_LOCATION=/mnt/store/mailcow /opt/apps/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 5 >>$log

echo 7 ================= `date` backup finished ================== >>$log

echo `date` end /root/newbackup.sh >>/srv/public/current.log

Stufe 2 Backup

export AWS_ACCESS_KEY_ID=$AMAZONKEYID
export AWS_SECRET_ACCESS_KEY=$AMAZONKEY
restic backup -r s3:s3.amazonaws.com/praxis /mnt/store