nextcloud mit S3 Storage Backend

Nextcloud mit S3 Storage Backend

von

Wer Nextcloud im professionellen Umfeld betreibt, kennt das Muster: Die Anwendung selbst läuft stabil, aber der Speicher wächst schneller als geplant. Klassische Block-Storage-Volumes werden dann zum Dauerthema (Resizes, Snapshots, Filesystem-Checks, Performance-Tuning). Eine saubere Alternative ist, Nextcloud so aufzusetzen, dass die Dateien direkt in einem S3-kompatiblen Object Storage liegen – zum Beispiel bei Hetzner.

In diesem Beitrag zeige ich eine praxistaugliche native Installation von Nextcloud, bei der S3 als Primärspeicher dient. Der wichtigste Punkt dabei: Die Object-Store-Konfiguration muss vor der Erstinstallation greifen, sonst wird es später unnötig kompliziert.

Primärspeicher vs. „Externer Speicher“: warum das nicht dasselbe ist

Nextcloud kann S3 auf zwei Arten nutzen:

  • Als externer Speicher (über die App „External storage support“): Das ist ein angebundener Speicherort neben dem normalen Nextcloud-Data-Directory.
  • Als Primärspeicher („Primary Object Storage“): Nextcloud legt die Datei-Inhalte im Bucket ab, verwaltet aber Ordnerstruktur und Dateinamen als Metadaten in der Datenbank. Der Bucket enthält damit nicht „lesbare Ordnerstrukturen“, sondern Objekte mit internen IDs.

Das ist der Grund, warum man bei Primärspeicher nicht „mal eben“ mit einem S3-Tool in den Bucket schauen und die Daten wie ein Filesystem nutzen sollte. Nextcloud erwartet exklusiven Zugriff auf den Bucket und verwaltet die Zuordnung in der DB.

Eine besonders wichtige Konsequenz: Wenn Sie einen Primär-Objectstore nachträglich in eine bestehende Nextcloud-Instanz konfigurieren, werden bestehende Dateien unzugänglich. Das ist kein „kleines Migrations-Feature“, sondern ein Architekturwechsel.

Voraussetzungen: was Sie vor dem Start festziehen sollten

Für einen stabilen Betrieb mit Nextcloud + S3 als Primärspeicher sollten Sie vorab entscheiden:

  • Nextcloud frisch installieren (keine bestehende Daten-Installation „umbauen“)
  • Bucket exklusiv für diese Nextcloud (keine Fremddaten, keine manuelle Objektpflege)
  • Endpoint/Region des S3-Anbieters (bei Hetzner z. B. fsn1, nbg1, hel1)
  • Credentials (Access Key / Secret) und Zugriffsrechte
  • Backup-Strategie: Daten liegen im Object Storage, Metadaten in der Datenbank. Beides muss in ein Restore-Konzept.

Hetzner nennt für Object Storage feste Endpoints je Standort, z. B.:

  • fsn1.your-objectstorage.com (Falkenstein)
  • nbg1.your-objectstorage.com (Nürnberg)
  • hel1.your-objectstorage.com (Helsinki)

Diese Endpoints sind die Basis für alle S3-Tools und auch für Nextcloud.

Download und Dateirechte: Nextcloud nativ ausrollen

Das folgende Vorgehen passt gut zu klassischen Debian/Ubuntu-Setups (Apache oder Nginx ist hier nicht der Fokus, weil der Kernpunkt die Objectstore-Anbindung ist).

1) Nextcloud herunterladen und entpacken:

cd /tmp
wget https://download.nextcloud.com/server/releases/latest.tar.bz2
sudo tar -xjf latest.tar.bz2
sudo mv nextcloud /var/www/

2) Eigentümer/Gruppe passend zum Webserver setzen:

sudo chown -R www-data:www-data /var/www/nextcloud

S3 als Primärspeicher: die s3.config.php vor der Installation anlegen

Nextcloud erwartet die Primärspeicher-Konfiguration in der config.php. In der Praxis hat sich aber bewährt, eine separate Konfigurationsdatei im config/-Verzeichnis zu hinterlegen, die Nextcloud beim Setup bereits einliest.

Pfad:

/var/www/nextcloud/config/s3.config.php

Beispielkonfiguration für S3-kompatible Anbieter

Nextcloud nutzt als Klasse für S3:

  • \OC\Files\ObjectStore\S3

und unterscheidet in der Doku zwischen Amazon-hosted S3 (region) und non-Amazon-hosted S3 (hostname, optional use_path_style).

Eine solide Basiskonfiguration für non-Amazon S3 sieht so aus:

<?php
$CONFIG = [
  'objectstore' => [
    'class' => '\\OC\\Files\\ObjectStore\\S3',
    'arguments' => [
      'bucket' => 'bucketname',
      'hostname' => 'REGION_CODE.your-objectstorage.com',
      'key' => 'ACCESS_KEY',
      'secret' => 'SECRET_KEY',
      'port' => 443,
      'use_ssl' => true,
      // required for some non-Amazon S3 implementations
      'use_path_style' => true,
    ],
  ],
];

Was an der Stelle wirklich zählt:

  • bucket, key, secret sind Mindestangaben.
  • Bei non-Amazon S3 setzen Sie hostname und ignorieren region.
  • use_path_style löst viele Kompatibilitätsprobleme, ist aber nicht bei jedem Anbieter nötig.

Hetzner-spezifisch: Endpoint korrekt wählen

Bei Hetzner Object Storage verwenden Sie als Endpoint genau den Standort-Hostnamen, z. B.:

  • fsn1.your-objectstorage.com

Die Credentials (Access Key/Secret) erzeugen Sie im Hetzner Console Kontext „Object Storage“ bzw. S3 Credentials.

Path-Style vs. Virtual-Hosted: welche Einstellung für Hetzner?

Hier gibt es in der Praxis häufig Verwirrung:

  • Nextclouds Beispiel für non-Amazon S3 zeigt use_path_style => true als Option, „required for some non-Amazon S3 implementations“.
  • Hetzner (und auch viele andere moderne Anbieter) funktionieren grundsätzlich sauber mit „virtual-hosted style“.

Meine Empfehlung für den Start:

1) Beginnen Sie mit use_path_style => true, wenn Sie die schnellste „es läuft erstmal“-Route wollen und Sie keine Fehlersuche nach Hostname/Bucket-URL-Stil möchten.
2) Wenn Sie gezielt auf virtual-hosted umstellen möchten (Bucket im Hostnamen), testen Sie die Kompatibilität vorab. Hetzner zeigt in ihren Tool-Beispielen sogar Bucket-Subdomains (bucket1.fsn1...).

Wichtig: Egal welchen Stil Sie nutzen – der Hostname in Nextcloud soll der generische Endpoint sein und nicht bereits den Bucket enthalten. Der hostname ist als generischer S3-Endpoint zu setzen.

Installation starten: Web-Installer oder occ

Wenn s3.config.php im config/-Verzeichnis liegt, starten Sie die Installation wie gewohnt über den Browser:

  • https://ihre-domain.tld

Geben Sie im Installer die Datenbankdaten an (MariaDB/MySQL sind üblich) und legen Sie Admin-Zugang fest.

Der zentrale Effekt: Nextcloud erkennt beim Setup den Objectstore als Primärspeicher und nutzt den Bucket für Datei-Inhalte.

Wenn Sie die Installation lieber automatisiert ausrollen, können Sie auch occ maintenance:install nutzen (z. B. in Provisioning/CI), das ändert aber nichts an der Kernanforderung: Die Objectstore-Konfiguration muss beim Installationszeitpunkt aktiv sein.

Was bleibt lokal, was wandert in den Bucket?

Bei Primärspeicher gilt:

  • Der Nextcloud-Code (App) bleibt lokal unter /var/www/nextcloud.
  • Der eigentliche Datei-Content landet im S3-Bucket.
  • Die Struktur und Zuordnung (Metadaten) liegt in der Nextcloud-Datenbank.

Der Object Store speichert den Dateiinhalt nach interner ID und die Metadaten verbleiben in Nextcloud.

Betrieb & typische Stolperfallen (die Admins Zeit kosten)

1) Backup: Object Storage + Datenbank gehören zusammen

Ein Restore funktioniert nur, wenn Sie beides haben:

  • Datenbank-Backup (Metadaten, Shares, Versions, Filecache, Users/Groups etc.)
  • Bucket-Daten (Objekte)

Wenn einer der Teile fehlt, bekommen Sie eine Nextcloud, die „da“ ist, aber keine Dateien korrekt zuordnen kann. Backup- und Recovery-Implikationen ändern sich, weil die Daten nicht mehr auf dem Nextcloud-Server liegen und nicht einfach „am Data-Directory vorbei“ erreichbar sind.

Praxis-Tipp: Dokumentieren Sie den Restore-Prozess einmal sauber (DB-Restore + Bucket-Stand + Config). Im Notfall spart das Stunden. Wenn Sie sich generell mit Notfall-Szenarien rund um Nextcloud beschäftigen, ist der Beitrag „Nextcloud Notfall – was nun?“ eine gute Ergänzung.

2) Bucket-Namen und Exklusivität

Nextcloud verlangt exklusiven Zugriff auf den Bucket. Das heißt:

  • kein „shared bucket“ mit anderen Anwendungen
  • keine manuellen Uploads/Deletes im Bucket

Sonst produzieren Sie Inkonsistenzen, die sich später als „Dateien fehlen“, „Versionschaos“ oder „Filecache-Probleme“ zeigen.

3) Performance: Latenz schlägt IOPS-Denken

Object Storage ist kein Block Storage. Viele kleine Dateien, hohe Latenz oder ungünstige PHP-FPM-Konfigurationen machen sich schneller bemerkbar als bei lokalem Storage.

Konkrete Praxismaßnahme: Planen Sie ausreichend lokalen Speicher für temporäre Dateien/Uploads ein.

4) Monitoring: Nicht nur Nextcloud überwachen

Wenn S3 als Primärspeicher ausfällt oder massiv bremst, wirkt es wie ein Nextcloud-Problem. In Wirklichkeit ist es oft ein Endpoint-, Auth- oder Latenzthema.

Wenn Sie Checkmk im Einsatz haben, lohnt es sich, den Object Storage separat zu überwachen. Dazu passt der Beitrag „S3 Storage mit Checkmk überwachen“.

5) Sicherheit: Zugriffsschlüssel wie Produktions-Passwörter behandeln

Access Key und Secret gehören nicht in Tickets, nicht in Chat, nicht in öffentliche Repos.

  • Legen Sie restriktive Rechte an (nur Bucket/Prefix, wenn möglich)
  • Rotieren Sie Keys kontrolliert
  • Halten Sie Ihre Nextcloud aktuell

Als Ergänzung: Für typische Nextcloud-Sicherheitsmaßnahmen (Login-Härtung, Best Practices) passt „6 Tipps für Administratoren für Nextcloud Sicherheit“.

Erweiterungen: Optionen, die in realen Setups helfen

SSE-C (Server Side Encryption mit Customer-Provided Keys)

Nextcloud dokumentiert die Unterstützung von SSE-C für S3 und zeigt, wie man einen base64-kodierten Schlüssel erzeugt und in sse_c_key hinterlegt.

Das ist eine Spezialfunktion und nicht automatisch „besser“, sondern eine konkrete Entscheidung im Security-Konzept. Wenn Sie das produktiv einsetzen, testen Sie unbedingt Restore, Key-Handling und Prozesse zur Rotation.

Einordnen: Warum Hetzner als S3-Backend in Nextcloud häufig gut passt

Hetzner Object Storage liefert S3-kompatible Endpoints pro Standort und lässt sich mit Standard-S3-Tools (AWS CLI, rclone etc.) bedienen. Hetzner dokumentiert sowohl die Endpoints als auch den Ansatz, S3-kompatible Tools zu verwenden.

Für Nextcloud bedeutet das: Sie bekommen eine Architektur, bei der Sie Compute (Nextcloud-Server) und Storage (S3) sauber trennen. Das ist vor allem dann angenehm, wenn die Dateimenge stärker wächst als Ihre Anwendungslast.

Wenn Sie Nextcloud grundsätzlich als Alternative zu klassischen Suite-Angeboten bewerten, lesen Sie auch „Nextcloud Alternative zu MS365“. Das hilft oft bei der internen Argumentation, warum man sich diese Architekturarbeit überhaupt macht.

Wenn Sie die Implementierung (Hetzner, Nextcloud, Reverse Proxy, Monitoring, Backup/Restore) sauber aufsetzen wollen oder bei einer bestehenden Umgebung unsicher sind, unterstützt ADMIN INTELLIGENCE auch operativ rund um Nextcloud: Nextcloud Services. Weitere praxisnahe Beiträge finden Sie auf https://blog.admin-intelligence.de/ oder bei konkreten Fragen direkt über https://www.admin-intelligence.de/kontakt/.