Backups mit der 3-2-1-Regel: So sichern Sie Nextcloud, Mattermost und Co.

Die 3-2-1-Regel verlangt drei Kopien Ihrer Daten auf zwei verschiedenen Speichern, eine davon an einem anderen Ort. Die Erweiterung 3-2-1-1-0 ergänzt eine unveränderliche oder getrennte Kopie und null Fehler beim Wiederherstellungstest. Für Nextcloud oder Mattermost heißt das: Datenbank, Dateien, Konfiguration und Schlüssel gemeinsam sichern, verschlüsseln und das Zurückspielen regelmäßig üben.

Was bedeutet die 3-2-1-Regel und was heißt 3-2-1-1-0?

Drei Kopien heißt: das Original auf dem Server plus zwei Sicherungen. Die liegen auf zwei verschiedenen Speichern, damit ein defekter Controller oder ein Problem beim Anbieter nicht beide trifft. Eine davon steht in einem anderen Gebäude oder Rechenzentrum, falls es brennt. Bei einem gemieteten Server läuft die Anwendung zum Beispiel auf Server A, die erste Sicherung landet auf einem Backup-Server im selben Rechenzentrum und ist schnell zurückgespielt. Die zweite liegt in einem S3-Speicher an einem anderen Standort.

3-2-1-1-0 ist eine verbreitete Erweiterung dieser Faustregel. Die zusätzliche Eins steht für eine Kopie, die ein Angreifer mit Zugriff auf Ihren Server nicht verändern kann: offline, also vom Netz getrennt, oder technisch unveränderlich. Die Null steht für null Fehler bei der Prüfung und beim Wiederherstellungstest. Beides fordert auch das BSI im Baustein CON.3.

Ein RAID zählt nicht als Kopie. Das BSI schreibt im Baustein CON.3 Datensicherungskonzept ausdrücklich, dass eine RAID-Spiegelung keine Datensicherung ist, weil die gespiegelten Daten gleichzeitig verändert werden. Ein versehentlich gelöschter Ordner oder eine verschlüsselte Datei ist auf beiden Platten sofort weg. Für Snapshots auf demselben Speichersystem gilt das genauso.

Was muss bei Nextcloud, Mattermost und Co. gesichert werden?

Eine selbst gehostete Anwendung besteht fast immer aus vier Teilen, die zusammengehören:

• Die Datenbank mit Benutzern, Rechten, Freigaben, Chatverläufen und den Metadaten zu jeder Datei.
• Die Dateien selbst, bei Nextcloud das Datenverzeichnis, bei Mattermost die Anhänge im Verzeichnis ./data.
• Die Konfiguration: config.php oder config.json, dazu Docker-Compose-Dateien, die Einstellungen des Reverse-Proxys, Cronjobs und Systemd-Units.
• Schlüssel und Passwörter: das Passwort des Backup-Repositorys, gegebenenfalls Schlüssel für die serverseitige Verschlüsselung, Zugangsdaten zum Speicher der externen Kopie.

Die vierte Gruppe wird am häufigsten vergessen. Wer das restic-Passwort verliert, verliert laut Dokumentation auch die Daten. Es gehört in einen Passwortmanager und auf Papier in einen Tresor, nicht allein auf den Server, den Sie im Ernstfall wiederherstellen wollen.

Für ein KMU mit Nextcloud und Mattermost ist dieser Plan ein vernünftiger Ausgangspunkt:

Den Snapshot sollten Sie trotzdem anlegen. Muss ein Sicherheitsupdate wie bei PHP2Shell kurzfristig eingespielt werden, ist er der schnellste Weg zurück.

Wie sichere ich Nextcloud konsistent?

Die Backup-Anleitung im Nextcloud-Admin-Handbuch nennt fünf Dinge: den Ordner config, das Datenverzeichnis, den Ordner themes, eigene Apps (falls vorhanden) und die Datenbank. Vorher schalten Sie den Wartungsmodus ein, damit während der Sicherung niemand Dateien ändert:

sudo -E -u www-data php occ maintenance:mode --on

Ohne Wartungsmodus kann zwischen Datenbank-Dump und Dateikopie eine Datei hochgeladen, verschoben oder gelöscht werden. Datenbank und Datenverzeichnis passen dann nach einer Wiederherstellung nicht mehr zusammen. Für MariaDB empfiehlt Nextcloud mariadb-dump --single-transaction, bei 4-Byte-Unterstützung (Emojis in Dateinamen) zusätzlich --default-character-set=utf8mb4. Für PostgreSQL steht dort pg_dump. Danach schalten Sie den Wartungsmodus mit --off wieder aus.

Beim ersten Lauf kann der Wartungsmodus bei einem großen Datenverzeichnis lange dauern, danach übertragen restic und Borg nur noch Änderungen. Kürzer wird das Fenster mit einem Snapshot des Dateisystems (LVM, ZFS oder Btrfs). Sie legen im Wartungsmodus nur Dump und Snapshot an, schalten ihn wieder aus und sichern dann in Ruhe aus dem Snapshot.

In der config.php steht der Wert secret, den Nextcloud unter anderem zum Verschlüsseln von Daten nutzt. Die Konfigurationsreferenz warnt, dass ein Verlust dieses Werts zu beschädigten Daten führt. Eine Sicherung des Datenverzeichnisses ohne passende config.php ist deshalb nur die halbe Miete.

Beim Zurückspielen löschen Sie laut Nextcloud zuerst alle vorhandenen Datenbanktabellen und importieren dann den Dump. War die Sicherung älter als der letzte Stand der Sync-Clients, folgt occ maintenance:data-fingerprint. Er hilft den Clients, möglichst viele Daten zu erhalten, kann aber Konfliktmeldungen auslösen. Vor einem großen Versionssprung wie dem Update auf Nextcloud 35 ist eine frische, getestete Sicherung ohnehin Pflicht, denn zurück auf die alte Version kommen Sie nur über das Backup.

Wie sichere ich Mattermost und PostgreSQL?

Mattermost verteilt seine Daten auf drei Stellen: die PostgreSQL-Datenbank, die Datei config/config.json (bei SAML das ganze Verzeichnis config mit den Zertifikaten) und die Anhänge im Datenverzeichnis. Liegen die Anhänge in S3, müssen Sie diese laut Mattermost in der Regel nicht separat sichern. Die Mattermost-Dokumentation ist bei der Konsistenz streng: Für eine saubere Sicherung soll der Server während des Backups gestoppt sein, sonst können Datenbank und Dateien auseinanderlaufen.

pg_dump liefert laut PostgreSQL-Dokumentation auch im laufenden Betrieb einen konsistenten Stand der Datenbank. Wird aber zwischen Dump und Dateikopie ein Bild in einen Kanal gestellt, fehlt nach der Wiederherstellung die Nachricht oder der Anhang. In der Praxis bewährt sich ein kurzer Stopp in der Nacht:

1. Mattermost anhalten, zum Beispiel mit systemctl stop mattermost oder docker compose stop mattermost.
2. Datenbank sichern mit pg_dump -Fc mattermost. Das Custom-Format ist komprimiert und wird später mit pg_restore eingespielt.
3. config und Datenverzeichnis sichern oder einen Dateisystem-Snapshot anlegen.
4. Mattermost wieder starten.

Ist ein Stopp nicht möglich, sichern Sie erst die Datenbank, dann die Dateien. Bei großen Datenbanken weist PostgreSQL selbst darauf hin, dass pg_dump außer in einfachen Fällen nicht das richtige Werkzeug für regelmäßige Produktionssicherungen ist. Spätestens bei einer Datenbank von einigen zehn Gigabyte oder wenn Sie höchstens eine Stunde Datenverlust verkraften, würde ich eine physische Sicherung mit fortlaufender WAL-Archivierung einplanen.

restic oder BorgBackup: Welches Werkzeug passt?

Beide Programme sind quelloffen, verschlüsseln auf dem Client und speichern doppelte Datenblöcke nur einmal. Sie unterscheiden sich vor allem beim Sicherungsziel.

restic ist ein einzelnes Go-Programm und schreibt direkt auf lokale Platten, per SFTP, auf einen eigenen REST-Server oder in S3-kompatiblen Speicher. Die Daten verschlüsselt es mit AES-256 und sichert sie mit Poly1305-AES gegen Veränderung. Aktuell ist Version 0.19.0 vom 9. Juni 2026 mit dem Fehlerkorrektur-Release 0.19.1 vom 5. Juli. Eine Änderung in 0.19.0 betrifft Skripte: Fehlt ein angegebener Quellpfad, endet restic backup jetzt mit Exit-Code 3 statt 0. Prüfen Sie, ob Ihr Skript das als Fehler wertet.

BorgBackup spielt seine Stärken aus, wenn auf dem Zielserver ebenfalls Borg läuft und die Clients per SSH sichern. Die stabile Reihe ist 1.4, zuletzt Version 1.4.5 vom 19. Juli 2026 mit einer Sicherheitskorrektur niedriger Schwere (CVE-2026-62268) beim Entpacken. Borg 2.0 ist noch im Beta-Stadium, die 2.0.0b25 erschien am 27. September 2026. Für produktive Sicherungen bleiben Sie bei 1.4. Borg 2.0 nutzt ein neues Repository-Format, alte Archive müssen mit borg transfer umgezogen werden.

Für S3 als Ziel nehme ich restic. Für einen eigenen Backup-Server mit SSH-Zugang ist Borg genauso gut und bringt den Append-only-Modus gleich mit. So sieht ein nächtlicher Lauf für Nextcloud mit restic aus:

#!/bin/bash
set -euo pipefail
# RESTIC_REPOSITORY, RESTIC_PASSWORD_FILE und S3-Zugangsdaten; Datei nur für root lesbar
source /root/restic.env

OCC="sudo -E -u www-data php /var/www/nextcloud/occ"

# Wartungsmodus an und in jedem Fall wieder aus, auch wenn ein Schritt scheitert
$OCC maintenance:mode --on
trap '$OCC maintenance:mode --off' EXIT

# Datenbank direkt ins Repository; scheitert der Dump, legt restic keinen Snapshot an
restic backup --tag nextcloud-db --stdin-filename nextcloud.sql \
  --stdin-from-command -- mariadb-dump --single-transaction \
  --default-character-set=utf8mb4 nextcloud

# Konfiguration, Themes und Datenverzeichnis
restic backup --tag nextcloud-files \
  /var/www/nextcloud/config /var/www/nextcloud/themes /srv/nextcloud-data

# Aufräumen und Prüfen läuft getrennt auf einem Admin-Rechner mit Löschrechten:
#   restic forget --keep-within 30d --keep-within-monthly 1y --prune
#   restic check --read-data-subset=5%

Wie schütze ich Backups vor Ransomware?

Laut BSI-Lagebericht 2025 waren kleine und mittlere Unternehmen vorwiegend von Ransomware und Datenleaks betroffen. Die Zahl der beim BKA angezeigten Ransomware-Angriffe lag im Berichtszeitraum bei 950. Wer mit Administratorrechten auf Ihrem Server sitzt, kann jedes Backup löschen, das dieser Server löschen darf. Der BSI-Baustein CON.3 verlangt deshalb schon in den Basis-Anforderungen (CON.3.A14), dass Datensicherungen nicht absichtlich oder versehentlich überschrieben werden können.

Append-only: Der Server darf schreiben, aber nicht löschen

Der restic REST-Server kennt die Option --append-only. Neue Snapshots sind dann erlaubt, Löschen und Überschreiben nicht. Bei Borg tragen Sie borg serve --append-only als erzwungenen Befehl für den SSH-Schlüssel des Servers ein. Borg markiert in diesem Modus gelöschte Daten nur, endgültig weg sind sie erst nach einem Schreibvorgang im normalen Modus. Ein automatischer prune mit vollen Rechten hebelt den Schutz also aus. Die restic-Dokumentation rät, für Append-only-Repositorys beim Aufräumen --keep-within zu verwenden. Sonst könnte ein Angreifer leere Snapshots mit passenden Zeitstempeln einschleusen, die bei einer Regel wie „ein Stand pro Woche“ die echten Sicherungen verdrängen. Wer später auf Borg 2 umsteigt, muss diesen Teil neu planen: Die Beta hat den Append-only-Modus entfernt und setzt auf Repository-Berechtigungen wie no-delete.

S3 Object Lock: Sperrfristen im Objektspeicher

Mit S3 Object Lock lässt sich jede Objektversion für eine feste Frist sperren. Voraussetzung ist die Versionierung des Buckets. Im Modus „Compliance“ kann während der Frist niemand die Version löschen, auch nicht der Root-Benutzer des Kontos. Im Modus „Governance“ dürfen Konten mit einer Sonderberechtigung die Sperre aufheben. Ob ein S3-kompatibler Anbieter Object Lock unterstützt, sollten Sie vor der Buchung klären.

restic setzt selbst keine Sperren. Sie legen am Bucket eine Standard-Aufbewahrung fest, die für jedes neue Objekt gilt. Versucht restic beim Aufräumen, ein gesperrtes Objekt zu löschen, lehnt S3 das ab oder setzt nur eine Löschmarkierung. Die gesperrte Version bleibt bis zum Ende der Frist erhalten und lässt sich zurückholen. Die Sperrfrist sollte länger sein als die Zeit, die ein Angriff unbemerkt bleiben kann, zum Beispiel 30 Tage.

Verschlüsselung und Schlüssel

restic verschlüsselt jedes Repository mit Ihrem Passwort, bei Borg legen Sie den Modus beim borg init fest. Wählen Sie einen der verschlüsselten Modi und exportieren Sie den Schlüssel mit borg key export. Das BSI empfiehlt bei erhöhtem Schutzbedarf (CON.3.A13), alle Datensicherungen zu verschlüsseln und die Schlüssel in einer getrennten Sicherung aufzubewahren. Bei einer Kopie in fremdem Speicher würde ich das immer so halten.

Was bedeuten RPO und RTO für mein Unternehmen?

Die Recovery Point Objective (RPO) gibt an, wie viel Datenverlust Sie im schlimmsten Fall hinnehmen. Bei einem nächtlichen Backup um 2 Uhr sind das bis zu 24 Stunden Arbeit. Die Recovery Time Objective (RTO) gibt an, wie lange es dauern darf, bis die Anwendung wieder läuft. Das BSI nennt die RPO je System als festen Bestandteil des Datensicherungskonzepts (CON.3.A6).

Die RTO hängt stark von der Leitung ab. 500 Gigabyte aus einem externen S3-Speicher über eine Anbindung mit 100 Mbit/s zu holen, dauert rein rechnerisch rund elf Stunden. Dazu kommen Datenbank-Import und Tests. Wenn Ihr Team nach einem Ausfall am nächsten Morgen wieder arbeiten soll, braucht es eine schnellere erste Kopie in der Nähe des Servers.

Bei der Aufbewahrung decken 30 Tagesstände und zwölf Monatsstände die meisten Fälle ab, auch einen gelöschten Ordner, der erst nach Wochen jemandem fehlt. Personenbezogene Daten, die Sie löschen müssen, stecken bis zum Ende dieser Frist noch in den Backups. Das gehört ins Löschkonzept.

Wie oft sollte man die Wiederherstellung testen?

CON.3.A15 ist eine Basis-Anforderung: Es muss regelmäßig getestet werden, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. Dafür steht die Null in 3-2-1-1-0. Wir empfehlen drei Stufen:

1. Nach jedem Lauf den Exit-Code auswerten und eine Warnung schicken, wenn seit 26 Stunden kein neuer Snapshot angekommen ist.
2. Wöchentlich die Integrität prüfen: restic check --read-data-subset=5% liest bei jedem Lauf einen zufälligen Teil der Daten tatsächlich zurück, bei Borg macht das borg check --verify-data.
3. Einmal im Quartal eine vollständige Wiederherstellung auf einer Test-VM: Datenbank einspielen, Dateien zurückholen, Anwendung starten, mit einem echten Konto anmelden und eine Datei öffnen. Stoppen Sie die Zeit. Das Ergebnis ist Ihre tatsächliche RTO.

Schreiben Sie dabei jeden Schritt in eine Wiederherstellungsanleitung. Laut BSI soll sie auch dann verfügbar sein, wenn das Backup-System selbst ausfällt. Ein Ausdruck neben dem Tresor mit dem Repository-Passwort erfüllt das.

Wenn Sie das nicht selbst aufbauen wollen, kann ACONA einen Teil übernehmen. Bei unserer Managed Nextcloud auf Servern in Deutschland sind Backups Teil des Betriebs, im Tarif für Unternehmen mit einem georedundanten, täglichen Zweitbackup. Datenbanken für eigene Anwendungen betreiben wir über unser Datenbank- und Cloud-Storage-Hosting. Für Server, die Sie selbst betreiben, übernehmen wir über die Kundenbetreuung Wartung und Monitoring. Ein kostenloses Erstgespräch von 20 Minuten können Sie über die Kontaktseite anfragen.

Häufige Fragen

Quellen

1. BSI: IT-Grundschutz-Baustein CON.3 Datensicherungskonzept (Edition 2023)
2. BSI: Die Lage der IT-Sicherheit in Deutschland 2025, Kapitel Schadwirkungen (November 2025)
3. Nextcloud Administration Manual: Backup
4. Mattermost Docs: Backup and disaster recovery
5. restic 0.19.0 Release Notes (9. Juni 2026)
6. BorgBackup Changelog: Version 1.4.5 (19. Juli 2026)
7. Amazon S3 User Guide: Locking objects with Object Lock