Startseite
» MS OFFICE
»
So ändern Sie den Standardspeicherort im ONLYOFFICE-Arbeitsbereich
So ändern Sie den Standardspeicherort im ONLYOFFICE-Arbeitsbereich
Kurz gesagt: In ONLYOFFICE Workspace können Sie über das Control Panel statische Portaldaten vom lokalen Standardspeicherort auf einen unterstützten Speicherdienst eines Drittanbieters verschieben. Die aktuelle offizielle Administrationsanleitung nennt Amazon S3, Google Cloud Storage, Rackspace Cloud Storage und Selectel Cloud Storage als mögliche Speicherdienste. Sie beschreibt jedoch kein Feld im Control Panel, in dem Sie einen beliebigen lokalen Pfad eingeben können /mnt/storage.
Dieser Leitfaden verwendet durchgehend ein rein hypothetisches Beispiel. Stellen Sie sich eine kleine Designagentur namens Northstar Studio vor. Deren selbstgehosteter ONLYOFFICE Workspace-Server stößt an seine Grenzen, da die Anzahl hochgeladener Dateien und anderer statischer Portaldaten stetig zugenommen hat. Der Administrator möchte den Portalspeicher in einen Amazon S3-Bucket verschieben, während das Workspace-Portal selbst auf demselben Server verbleibt. Northstar Studio dient lediglich der Veranschaulichung und stellt keinen realen Test oder ein Kundenergebnis dar.
Bevor Sie Änderungen vornehmen, ist es hilfreich, zwei verschiedene Aufgaben zu unterscheiden, die oft als „Ändern des Standardspeicherorts“ bezeichnet werden. Die erste Aufgabe besteht darin, den Speicherort für statische Daten des Portals von der lokalen Festplatte auf einen unterstützten Objektspeicheranbieter in der Systemsteuerung umzustellen. Die zweite Aufgabe ist das Verschieben des Host-Dateisystemverzeichnisses, das von einer selbst gehosteten Docker-Installation verwendet wird. ONLYOFFICE dokumentiert diese Vorgänge als unterschiedliche Ebenen. Daher konzentrieren sich die folgenden Schritte zunächst auf die Methode mit der unterstützten Systemsteuerung und erläutern anschließend den Fall mit der lokalen Festplatte separat.
Was ändert sich, wenn Sie einen neuen Speicheranbieter auswählen?
Standardmäßig speichert ONLYOFFICE Workspace Portaldaten auf der lokalen Festplatte des Rechners, auf dem Workspace installiert ist. Laut der offiziellen Speicherseite kann für statische Portaldaten ein verbundener Drittanbieterdienst verwendet werden. Nach Auswahl und Verbindung eines neuen Anbieters wird die Seite neu geladen und die Datenmigration gestartet. Je nach Datenmenge kann diese Migration einige Zeit in Anspruch nehmen.
Für Northstar Studio lautet das Ziel daher nicht: „Jeder Benutzer muss zukünftige Dokumente in einem bestimmten Ordner speichern.“ Vielmehr geht es darum, „den Speicher-Backend des Portals von der Standardfestplatte auf den S3-Bucket umzustellen.“ Diese Unterscheidung ist wichtig, da die Benutzerordnerorganisation, verbundene Drittanbieterordner im Dokumentenmodul, Sicherungsziele und der Speicher-Backend auf Administratorebene separate Funktionen darstellen.
Schritt 1: Sichern Sie das Portal, bevor Sie den Speicherort ändern.
Eine Speicheränderung löst eine Migration aus. Erstellen Sie daher vorher eine wiederherstellbare Sicherung. ONLYOFFICE bietet Sicherungs- und Wiederherstellungsfunktionen in der Systemsteuerung. Die Sicherung kann je nach Bereitstellung und Konfiguration temporär, im Modul „Dokumente“, auf einem Computerpfad oder in einem unterstützten Drittanbieterspeicher abgelegt werden.
Für den hypothetischen Northstar Studio-Server würde der Administrator ein aktuelles Backup erstellen und den Speicherort des resultierenden Archivs überprüfen, bevor er die Speicherseite aufruft. Dies beweist nicht, dass eine Migration fehlschlagen wird; es bietet dem Administrator lediglich einen Wiederherstellungspfad, falls Anmeldeinformationen, Bucket-Richtlinien, Netzwerkzugriff oder andere Abhängigkeiten fehlerhaft sind.
Schritt 2: Öffnen Sie die Systemsteuerung und überprüfen Sie die Integration.
Melden Sie sich mit einem Konto an, das über Administratorrechte für das Portal verfügt. Öffnen Sie auf der Startseite des Arbeitsbereichs die Systemsteuerung oder öffnen Sie die Portaleinstellungen und folgen Sie dem Link „Systemsteuerung“ im linken Bereich. Der Drittanbieterdienst muss zunächst im Bereich „Integration“ des Portals verbunden werden; andernfalls ist die Speicheroption auf der Seite „Speicher“ deaktiviert.
Abbildung der ONLYOFFICE Workspace-Oberfläche mit Darstellung der Einstellungen und des Eintrags „Systemsteuerung“, über den die Portalverwaltung aufgerufen wird.
Northstar Studio plant die Nutzung von Amazon S3. Daher überprüft der Administrator zunächst, ob Amazon S3 als Drittanbieterdienst konfiguriert ist. Dieselbe Voraussetzung gilt für die Auswahl von Google Cloud Storage, Rackspace Cloud Storage oder Selectel Cloud Storage.
Abbildung der Control Panel Integration mit Auflistung von Amazon S3, Google Cloud Storage, Rackspace Cloud Storage und Selectel Cloud Storage als Speicherintegrationen.
Schritt 3: Öffnen Sie die allgemeinen Einstellungen → Speicher
Öffnen Sie in der Systemsteuerung die Seite „Speicher“ unter „Allgemeine Einstellungen“ . Standardmäßig ist „Festplatte“ ausgewählt. Hier wählen Sie das unterstützte Backend aus, das die statischen Daten des Portals speichern soll.
Abbildung der Systemsteuerung zum Thema Speicher: Standardfestplatte ausgewählt und die vier dokumentierten Speicheroptionen von Drittanbietern sichtbar.
Wenn Sie Daten ausschließlich auf der lokalen Festplatte des Servers speichern möchten, wählen Sie keinen Cloud-Anbieter. Die Standardeinstellung für die lokale Speicherung bleibt bestehen. Falls Sie diese lokalen Daten auf einen anderen Mountpunkt desselben Servers verschieben möchten, fahren Sie mit dem Abschnitt zu Docker und Hostpfaden weiter unten fort; die Speicherseite ist keine allgemeine Dateisystempfadauswahl.
Schritt 4: Geben Sie die anbieterspezifischen Einstellungen ein.
Wählen Sie den gewünschten Anbieter aus und geben Sie die erforderlichen Verbindungsdetails ein. Die aktuelle ONLYOFFICE-Dokumentation beschreibt für Amazon S3 Felder wie Bucket und Region sowie optionale Einstellungen für Service-URL, Pfadstil erzwingen, HTTP verwenden und Verschlüsselung. Google Cloud Storage verwendet einen Bucket-Namen; Rackspace und Selectel verwenden eigene Container- und Regionsfelder.
Abbildung der Amazon S3-Speicherkonfiguration mit Angabe von Bucket, Region, optionaler Service-URL, Pfadstil, HTTP- und Verschlüsselungseinstellungen vor der Verbindungsherstellung.
Im Beispiel von Northstar Studio gibt der Administrator einen dedizierten S3-Bucket und die korrekte AWS-Region an. Die Service-URL bleibt unverändert, es sei denn, ein anderer Endpunkt wird explizit benötigt. Anmeldeinformationen und Berechtigungen sollten auf die für Workspace erforderlichen beschränkt sein, und der Netzwerkzugriff vom Server auf den Speicherdienst muss vor Beginn der Migration überprüft werden.
Praktische Prüfungen vor dem Klicken auf „Verbinden“
Prüfen Sie, ob der Bucket oder Container in der erwarteten Region existiert.
Prüfen Sie, ob die Integrationszugangsdaten gültig und für die erforderlichen Objektoperationen autorisiert sind.
Prüfen Sie, ob der Workspace-Server den Provider-Endpunkt erreichen kann.
Bewahren Sie die letzte Datensicherung außerhalb des zu migrierenden Datenbereichs auf.
Planen Sie die Änderung für einen Zeitraum, in dem Sie das Portal und den Speicherdienst auf Fehler oder unerwartete Kapazitätsauslastung überwachen können.
Schritt 5: Verbinden Sie den Speicher und warten Sie, bis die Migration abgeschlossen ist.
Klicken Sie auf „Verbinden“ . Laut der offiziellen Anleitung von ONLYOFFICE wird die Seite neu geladen und die Datenmigration startet. Gehen Sie nicht davon aus, dass die Änderung abgeschlossen ist, nur weil der Anbieter akzeptiert wurde. Warten Sie, bis die Speicherseite mit dem neuen Speicherort angezeigt wird, und überprüfen Sie dann die normale Portalnutzung.
Speicherillustration, die Amazon S3 nach der Konfiguration zeigt, mit Angabe des ausgewählten Buckets und der Region.
Für Northstar Studio würde eine sinnvolle Validierung das Öffnen mehrerer vorhandener Dokumente, das Hochladen einer neuen Datei, die Vorschau von Bildern oder anderen statischen Inhalten sowie die Überprüfung des S3-Buckets auf neue Objekte umfassen. Die genaue Objektstruktur ist eine Implementierungsfrage; wichtig ist, dass die Portalinhalte einwandfrei funktionieren und das neue Backend genutzt wird. Falls das Portal Fehler meldet, sollten Sie vor weiteren Änderungen die Anmeldeinformationen, die Bucket-Richtlinie, die Region, die Erreichbarkeit der Endpunkte und die Serverprotokolle überprüfen.
Was ist, wenn Sie stattdessen eine andere lokale Festplatte oder einen anderen Mountpunkt verwenden möchten?
Hier werden viele Anleitungen zum Thema „Standard-Speicherort“ irreführend. Die Option „Standard-Festplatte“ im Control Panel bietet keine Möglichkeit, ein beliebiges Hostverzeichnis auszuwählen. Bei Docker-basierten Workspace-Bereitstellungen gibt die Migrationsdokumentation von ONLYOFFICE an, dass Portaldaten /app/onlyofficeauf dem Host unter dem angegebenen Verzeichnis gespeichert werden. Die Dokumentation zur manuellen Docker-Installation erstellt ebenfalls Komponentenverzeichnisse unterhalb dieser Verzeichnisstruktur, wie z. B. CommunityServer, DocumentServer, MailServer, ControlPanel und datenbankbezogene Verzeichnisse.
Wenn Sie die Verzeichnisse auf dem Host auf eine größere Festplatte verschieben müssen, behandeln Sie dies als Migration einer Bereitstellung und nicht als Einstellung in der Systemsteuerung. Sichern Sie die Installation, stoppen Sie die relevanten Container, kopieren Sie die Daten unter Beibehaltung der Eigentumsrechte und Berechtigungen, aktualisieren Sie die Host-seitigen Bind-Mounts oder Docker Compose-Volume-Definitionen Ihrer spezifischen Bereitstellung und starten Sie den Stack erst dann neu. Die genaue Compose-Datei und das Volume-Mapping hängen von der Installation von Workspace ab. Daher kann das Kopieren eines generischen Befehls aus einer anderen Bereitstellung das Portal beschädigen.
Worin besteht der Unterschied zwischen dem Ändern des Portalspeichers und dem Ändern des Backup-Speichers?
Es handelt sich um separate Einstellungen. Auf der Speicherseite wird festgelegt, wo die unterstützten statischen Portaldaten gespeichert werden. Auf der Sicherungsseite wird der Speicherort für die Sicherungsarchive bestimmt. Sie können beispielsweise Portaldaten auf dem Standarddatenträger speichern und die Sicherungen an einem anderen Ort ablegen oder statische Portaldaten nach S3 verschieben und die Sicherungen an einem anderen Ort speichern. Aus Gründen der Ausfallsicherheit ist es im Falle einer Wiederherstellung in der Regel einfacher, die Sicherungen logisch vom primären Speichersystem zu trennen.
Welche Option passt zu Ihrer Situation?
Ziel
Verwenden
Wichtigste Einschränkung
Verschieben Sie statische Portaldaten von der lokalen Festplatte in einen unterstützten Cloud-/Objektspeicher.
In dieser Schnittstelle sind nur die dokumentierten Anbieter verfügbar.
Daten auf der lokalen Serverfestplatte speichern
Standardeinstellung der Festplatte
In der Systemsteuerung ist kein beliebiger lokaler Pfadauswahldialog dokumentiert.
Verschieben Sie selbst gehostete Docker-Daten auf eine andere Host-Festplatte oder binden Sie sie ein.
Änderung des Volumes/Bind-Mounts auf Bereitstellungsebene
Die genauen Pfade hängen von der Installationsmethode ab; erstellen Sie vorher ein Backup.
Ändern Sie den Speicherort für Sicherungsarchive.
Systemsteuerung → Sicherung
Dies ändert nichts am primären Portal-Speicher-Backend.
Checkliste zur abschließenden Überprüfung
Der gewünschte Anbieter wird auf der Speicherseite ausgewählt.
Die Migration ist abgeschlossen, sie hat nicht nur begonnen.
Vorhandene Dateien lassen sich normal öffnen und herunterladen.
Neue Uploads funktionieren.
Die Nutzer können weiterhin ohne Speicherfehler auf das Portal zugreifen.
Der neue Bucket oder Container zeigt Aktivitäten, die mit der Nutzung des Portals übereinstimmen.
Eine aktuelle Datensicherung ist weiterhin verfügbar und wurde nicht versehentlich nur in dem Datensatz gespeichert, den Sie gerade verschoben haben.
Im Beispiel von Northstar Studio ist die Speicherumstellung nur dann erfolgreich, wenn das Portal nach der Migration normal funktioniert und der Administrator bestätigt hat, dass das ausgewählte S3-Backend aktiv ist. Diese praktische Definition ist aussagekräftiger, als die Schaltfläche „Verbinden“ allein als Nachweis für den Abschluss des Vorgangs zu betrachten.