Schlagwort-Archive: Nextcloud

Backupstrategie für Nextcloud und Co mit TrueNAS

Es gibt nichts wichtigeres als Backup Backup und hab ich schon gesagt: Backup? Gerade in Zeiten von Emotet und Co muss man extrem aufpassen. Ich möchte in diesem Beitrag meine Backupstrategie vorstellen.

Auf die Idee gebracht hat mich https://flxn.de/posts/nextcloud-backup-to-freenas/ . Ich habe die Idee nur etwas abgewandelt.

Server – CC-BY-SA 3.0: https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Servers-8055_35.jpg

Die Situation

Ich habe viele Server, darunter einige Nextclouds, Webserver und Mailserver. Auf den Servern ist notorisch wenig Platz, aber dafür ist auf dem TrueNAS genug Platz! Das TrueNAS ist nicht öffentlich im Netz, die Server allerdings schon, was diese natürlich zum idealen Angriffsziel machen. Alle Server basieren auf Linux bzw. BSD.

Die Backupstrategie

Ich habe meine Backupstrategie in mehrere Stufen eingeteilt.

Grundsätzliches

Pull nicht Push: Holt euch die Backups immer so, dass der Backupserver (der nur lokalen Zugriff zulässt) vom entfernten System abholt. Sollte der Server einmal übernommen werden, kann sonst der Angreifer auch den Backupserver übernehmen, bzw. weiß sofort von den Offsite-Backups.

Teste dein Backup: Teste auch ob das wiederherstellen deines Backups funktioniert. Am besten regelmäßig! Ein nicht getestetes Backup ist quasi kein Backup.

Stufe 1: Versionierung

Die erste Stufe schützt vor versehentlichem Löschen einer Datei. Speichert man die Änderungshistorie bzw. verschiedene Versionen können diese wiederhergestellt werden. Am einfachsten geht das bei ZFS (Dateisystem) mit regelmäßigen Snapshots bzw. bei der Nextcloud mit dem Addon „Versions“. Das geht natürlich nicht bei allen Servern z.B. dem Mailserver, aber hilft bei einfachen Fehlern enorm.

Stufe 2: Einfache Onsite Snapshots

Viele meiner Maschinen sind als VM abgebildet. Jeder Virtualisierungshost bietet die Funktion der Snapshots bzw. des Backups. Dabei wir dein Snapshot der gesamten VM angelegt. Dies hilft bei Fehlkonfigurationen oder dem versehentlichen Löschen größerer Dateien. Es kann auch helfen, wenn man sich einen Verschlüsselungstrojaner eingefangen hat, aber in der Regel wartet dieser sehr lange, um auch ältere Snapshots zu erwischen. Hier speichere ich meist 7 Tage.

Stufe 3: Offsite-Backup

Das Offsite-Backup möchte ich in diesem Beitrag näher erklären. Ich hole mir dabei aktiv die Daten der Server ab und speichere diese auf einem TrueNAS. Wie ich das genau umgesetzt habe ist weiter unten beschrieben.

Der Backupserver sollte sich natürlich auch in einem anderen Rechenzentrum, bzw. an einem anderen Standort befinden.

Stufe 3,5: Ein weiteres Offsite-Backup mit einer anderen Methoden

Das Offsite-Backup sollte auch mit einer anderen Methode auf den gleichen oder einen anderen Server kopiert werden. So kann man systematische Fehler im Backupsystem vermeiden. Holt man sich z.B. mit dem ersten Offsite-Backup die Snapshots der VM ab, sollte man mit einem zweiten Backup stupide die Daten mit rsync abholen. Dies hilft, sollte z.B. der Snapshot nicht reparabel defekt sein oder sollte die Backupmethode die Backups zerstört haben.

Stufe 4: Offline-Backup vom Backup

Im schlimmsten Szenario muss man davon ausgehen, dass auch der Backupserver von einem Angreifer übernommen worden ist. Ich hole mir dazu einmal die Woche die Backups auf eine externe Festplatte und ziehe diese danach vom Server wieder ab. Das hilft natürlich nicht, wenn der Angreifer längere Zeit auf dem Backupserver ist, aber zumindest eine weitere Hürde.

Traumhaft wäre natürlich ein offline-Backup mit mehreren Festplatten, die sich idealerweise dann auch noch nicht am gleichen Standort oder in einem Brandschutztresor befinden :).

Die Umsetzung der Stufe 3: Offsite-Backup mit TrueNAS

Stufe 1 und 2 müssen je nach System selbst umgesetzt werden. Stufe 3 kann relativ einfach mit TrueNAS eingerichtet werden. Auf die Idee hat mich wie bereits erwähnt Felix gebracht (vgl. https://flxn.de/posts/nextcloud-backup-to-freenas/ ) gebracht. In seinem Blog erklärt Felix bereits wie ein Backup mit TrueNAS bzw. FreeNAS umgesetzt werden kann. Ich habe die Idee lediglich insoweit modifiziert, dass die verschiedenen Versionen der Backups nicht auf dem Server selbst, sondern auf dem Backupserver erstellt bzw. gespeichert werden.

Im Folgenden bezeichne ich den TrueNAS-Server als „Backupserver“ und als Beispiel für das System, welche gebackupt werden soll „Webserver“.

Schritt 1: SSH-Verbindung mit Webserver aufbauen

Als Übertragungsweg wollen wir rsync über SSH verwenden. Dazu muss zunächst ein SSH-Schlüssel-Paar erstellt und auf den Servern verteilt werden. Nutzt am besten für jeden Server ein individuelles Schlüsselpaar. Wie das geht, ist im Internet 100x dokumentiert. Ein Beispiel: https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu

Achtung: Bevor ihr weiter macht, solltet ihr euch per Konsole im TrueNAS mindesten einmal erfolgreich mit dem Webserver verbunden haben. Hinweis: Passwort-Geschützte SSH-Keys werden bei automatischen Backups nicht unterstützt.

Schritt 2: rsync-Backup-Jobs einrichten

Hier können wir auf die komfortable Funktion von TrueNAS zurückgreifen. In der UI (TrueNAS) unter Tasks -> Rsync Tasks -> Add kann man einfach neue Jobs hinzufügen:

rsync-jobs mit TrueNAS

Die Wichtigsten Einstellungen dabei:

  • Source Path: Der Ordner auf dem Backupserver auf dem das Backup abgespeichert werden soll. Es ist sehr hilfreich, für die Backups ein eigenes ZFS-Dataset anzulegen. Warum zeigt sich später!
  • User: Der Benutzer auf dem Backupserver und Remote-Server (für SSH)
  • Schedule: Wie oft soll das Backup durchgeführt werden?
  • Remote Host: Der FQDN für den SSH-Zugriff auf den Webserver. Hier kann auch mit user@remotehost.de ein Benutzer angegeben werden.
  • Remote Path: Der Ordner auf dem Webserver, der gespeichert werden soll
  • Archive: aktivieren! Das ist wichtig um Berechtigungen und Benutzer zu erhalten
  • Delete: aktivieren! Das ist wichtig, damit auch gelöschte Daten synchronisiert werden

Den Rest kann man im default belassen. Es können nun viele verschiedene Backup-Jobs z.b. für verschiedene Verzeichnisse oder verschiedene Server angelegt werden. Wenn ihr in der Übersicht der rsync-Jobs einen einzelnen Job anklickt und „Run now“ klickt, kann der Job getestet werden. Je nach größe des Backups kann das natürlich etwas dauern.

Das tolle an rsync: Das erste Backup dauert lange, danach wird nur noch der DIFF gesichert und das Backup sollte deutlich schneller gehen!

Schritt 3: Snapshots der Backups

Nun kommt der Punkt an dem ich mich von Felix (vgl. https://flxn.de/posts/nextcloud-backup-to-freenas/ ) unterscheide: Nach einem erfolgreichen rsync-Job lege ich nun ein Snapshot des Backups an. Warum? So kann ich auf verschiedene Versionen des Backups zurück greifen und kann sogar fein-granular einzelne Dateien wiederherstellen. Das ist vor allem sinnvoll, wenn man identifizieren kann, ab wann ein System potentiell kompromittiert ist. Bzw. wenn man weiß, ab wann eine Datei fehlt oder defekt war.

Unter Tasks -> Periodic Snapshot Tasks kann in TrueNAS bequem ein regelmäßiger Snapshot eingerichtet werden. Ich habe täglich gewählt und speichere ein Jahr. Achtet darauf, dass der Snapshot-Zeitpunkt nicht zeitgleich zum Backup-Zeitpunkt stattfindet.

Jetzt zeigt sich auch, warum es hilfreich ist, für die Backups ein eigenes Dataset anzulegen: Die Snapshots können nämlich auf verschiedene Datasets angewendet werden. So könnt ihr verschiedene Zeitpunkte oder Speicherfristen für verschiedene Backups festlegen.

Die Snapshots des Backup

Sieht man sich nun die einzelnen Snapshots an, ist zu erkennen, dass ZFS sehr effizient ist und lediglich den DIFF speichert. So verbrauchen Snapshots nur sehr geringen Speicherplatz. Zum Wiederherstellen einzelner Versionen einfach auf „Clone to new Dataset“ klicken. Es wird dann ein neues Dataset angelegt auf dem die Daten durchsucht werden können.

Erste Schritte mit ZFS auf Linux Ubuntu 20.04 LTS

Ich habe schon länger mit ZFS (an der Oberfläche) zu tun, da ich Privat ein FreeNAS einsetze. Jetzt wollte ich ZFS mal auf Linux einsetzen und testen und was soll ich sagen: Ich bin begeistert!

Dieser Blogeintrag soll einen ersten Einstieg bieten und für mich als Dokumentation dienen ;).

Warum ZFS? Ich habe mir in der Hetzner-Serverbörse einen kleinen Storage-Server für eine Nextcloud geklickt:

  • 2x SSD 512GB (Für Betriebssystem, Webserver und die Nextcloud-Daten)
  • 2x HDD 3TB (Für die abgelegten Daten der Nextcloud)

Installation Grundsystem

Das Grundsystem ist ein Standard Ubuntu 20.04 LTS, welches auf den SSDs (in einer RAID0 Konfiguration) installiert wurde.

Installation und Konfiguration ZFS

Erst mal ZFS installieren:

apt install zfsutils-linux

Nun möchte ich die zwei HDDs (/dev/sda und /dev/sdb) als zfs-mirror installieren:

zpool create storage mirror /dev/sda /dev/sdb

Fertig :). Ab jetzt kann man den Mirror unter /storage/ verwenden.

Da ich den Server zusammen mit ein paar Freunden verwende, möchte ich jedem sein eigenes Dataset. Dataset ist der generische Begriff für ein ZFS-Dateisystem, Volume, Snapshots oder Klone. Jedes Dataset besitzt einen eindeutigen Namen in der Form poolname/path@snapshot. Die Wurzel des Pools ist technisch gesehen auch ein Dataset (Weitere Infos: https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/zfs-term.html)

zfs create storage/[name]

Anstelle von [name] einfach den jeweiligen Namen des Datasets angeben. Jetzt kann optional noch die Kompression aktiviert werden:

zfs set compression=lz4 storage/[name]

lz4 Compression kann ohne größere Geschwindigkeitsverluste für Lesen/Schreiben (bei modernen CPUs) eingesetzt werden. Die Anzeige der Compression-Ratio kann über folgenden Befehl erreicht werden:

zfs get compression,compressratio storage/[name]

Jeders Dataset soll eine quota bekommen:

zfs set quota=1G storage/[name]

Fertig ist die Config. Weitere Informationen könnt ihr hier finden: https://www.42u.ca/2016/11/23/zfs-cheat-sheet/#:~:text=Dataset%20%E2%80%93%20This%20is%20the%20file,on%20top%20of%20the%20zpool.&text=If%20you%20were%20to%20think,you%20would%20use%20a%20zvol.

Automatischen Scrub aktivieren

Bei einem ZFS scrub werden die Festplatten auf Fehler geprüft und eventuelle defekte Dateien repariert. Man sollte den Scrub regelmäßig (etwa einmal im Monat durchführen). Dazu einfach einen einen Eintrag in die Crontab (crontab -e) schreiben:

0 2 1 * * /sbin/zpool scrub files

Der Status des letzten Scrub ist über den Befehl

zpool status

zu erhalten.

Threema Safe Backup mit Nextcloud WebDAV Funktion

Threema ist schon ein sehr toller Messenger, aber leider gibt es in Sachen Backup noch viel zu tun. Ein Schritt in die richtige Richtung ist der Threema Safe. Damit lassen sich grundlegende Einstellungen sichern. Unter anderem:

  • Threema-ID
  • Profildaten
  • Kontakte
  • Einstellungen

Was allerdings nicht gespeichert wird:

  • Chatverläufe
  • Mediendaten

Threema bietet für Threema Safe verschiedene Optionen. So kann man die Daten in der Cloud von Threema speichern, oder in einem eigenen Webdav-Verzeichnis. Da viele die Threema nutzen ausreichend paranoid sind um fremden Cloud-Speichern nicht zu verwenden und auch eine eigene Nextcloud betreiben ist die zweite Option das Mittel der Wahl.

Threema Safe in der eigenen Nextcloud

Die Nextcloud bietet alles, was Threema Safe benötigt. Eine Anleitung wie man dies einrichtet ist im Folgenden zu finden.

Serviceaccount Anlegen

Zunächst einmal sollte ein Service-Account für Threema angelegt werden. Die Threema-App benötigt Login-Daten für das Speichern des Backups. Hierfür sollte man wenn möglich nicht die Daten seinen Haupt-Accounts verwenden.

Neuen Account anlegen: Als Administrator einfach oben rechts auf den Benutzer klicken -> Benutzer -> Neuer Benutzer

Hier einfach einen Benutzernamen (z.B. „threema“ mit einem sicheren Passwort erzeugen. Passwort und Benutzername werden später benötigt.

Ordner-Sturktur anlegen

Threema verlangt eine spezielle Ordner-Sturktur auf dem Server. Legt einen beliebigen Ordner für die Backups an (möglichst ohne Leerzeichen). Innerhalb dieses Ordners MUSS ein Ordner namens „backups“ vorhanden sein. Außerdem muss eine Datei namens „config“ angelegt werden, mit folgendem bzw. ähnlichem Inhalt:

{
   "maxBackupBytes": 52428800,
   "retentionDays": 180
}

maxBackupBytes legt dabei die maximale Backup-Größe fest, retentionDays wie lange dieses Backup aufgehoben werden soll. Die Ordnerstruktur sollte danach etwa so aussehen:

Threema Safe Ordnerstruktur in der Nextcloud (Web-Ansicht)

Threema Safe Konfiguration in der App einstellen

Das schlimmste ist erledigt. Nun nur noch die Einstellungen in die Threema-App übernehmen:

Burger-Menü (oben Links) -> Meine Backups -> Threema Safe

Webdav-Verzeichnis: Das Nextcloud-Verzeichnis kann mit WebDAV über folgenden Link erreicht werden:

https://cloud.website.de/remote.php/dav/files/username/subfolder

Dabei müssen natürlich die URL zur Cloud, der Benutzername und der Subfolder angepasst werden. Als Beispiel meine Konfiguration:

https://cloud.timoswebsite.de/remote.php/dav/files/threema/threema-safe

Username und Passwort wie von euch im ersten Schritt gewählt. Werden die Einstellungen gespeichert fragt Threema noch nach einem Passwort mit dem das Backup auf dem Server verschlüsselt werden soll.

Nun sollte in der Threema-App folgende Ansicht sichtbar sein:

Threema Safe Einstellungen auf dem Handy mit der Nextcloud

Abschließende Hinweise

Threema speichert ab jetzt selbstständig die oben genannten Daten etwa alle 24 Stunden. Aber vorsicht: Dies ist kein vollständiges Backup!

Nach wie vor werden keine Gesprächsverläufe bzw. Mediendateien gesichert. Diese müssen weiterhin über „Meine Backups -> Daten-Backup“ erstellt und vom Handy gesichert werden. Hier muss Threema definitiv noch nacharbeiten.