> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Daten und Backups

Im Zuge der Weiterentwicklung von Overleaf müssen wir manchmal das Schema der Daten in der Datenbank ändern. Dieser Vorgang wird mithilfe von Migrationsskripten automatisiert. Diese wurden zuvor auf [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) ausgeführt, der weltweit größten Overleaf-Instanz, sodass die meisten Eventualitäten bereits aufgetreten sind. Für Ihre Daten übernehmen wir jedoch keine Garantie. Bitte erstellen Sie **vor** dem Upgrade Ihrer Instanz unbedingt ein **konsistentes** Backup Ihrer Daten.

<Info>
  Beim Upgrade auf ein neues Docker-Image werden alle Migrationen, die **noch nicht** ausgeführt wurden, automatisch ausgeführt. Das kann je nach Größe Ihres Datenbestands einige Zeit dauern; den Fortschritt können Sie anhand der Logs verfolgen. Weitere Informationen finden Sie in unserer Dokumentation zum [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging).
</Info>

### Datenspeicherung

Overleaf Community Edition und Server Pro speichern ihre Daten an drei verschiedenen Orten:

* <strong>MongoDB-Datenbank:</strong> Hier befinden sich die Benutzer- und Projektdaten.
* <strong>Redis:</strong> dient als Hochleistungs-Cache für Daten in Bearbeitung und speichert in erster Linie Informationen zu Projektbearbeitungen und Zusammenarbeit.
* <strong>Overleaf-Dateisystem:</strong> speichert nicht bearbeitbare Projektdateien (einschließlich Bildern) und dient außerdem als temporärer Festplatten-Cache während der Projektkompilierung.

<Info>
  Je nachdem, wann Ihre Instanz eingerichtet wurde, kann dies `~/sharelatex_data` oder `~/overleaf_data` sein.
</Info>

<Check>
  Für Projektdateien und Daten des vollständigen Projektverlaufs unterstützen wir auch S3-kompatible Speicher-Backends.
</Check>

Weitere Informationen zur Ordnerstruktur auf der Festplatte finden Sie unter „Ordner im Detail".

### Ein konsistentes Backup erstellen

Für ein konsistentes Backup müssen drei Speicher berücksichtigt werden:

* MongoDB
* Redis
* Daten des Overleaf-Dateisystems

Um ein konsistentes Backup zu erstellen, ist es **zwingend erforderlich**, Benutzer während des Backup-Vorgangs daran zu hindern, neue Daten zu erzeugen. Wir empfehlen daher, ein Wartungsfenster einzuplanen, in dem Benutzer nicht auf die Instanz zugreifen oder ihre Projekte bearbeiten können.

Bevor Sie den Backup-Vorgang starten, müssen Sie Ihre Instanz offline nehmen. Ab Server Pro `3.5.0` werden beim Herunterfahren das Schließen der Website und das Trennen der Benutzer automatisiert.

Um Ihre Instanz herunterzufahren, führen Sie `bin/docker-compose stop sharelatex` aus, wenn Sie eine Toolkit-Bereitstellung verwenden, bzw. `docker compose stop sharelatex`, wenn Sie Docker Compose verwenden.

Sobald der Container `sharelatex` gestoppt ist, können Sie den Backup-Vorgang starten.

Nachdem der Backup-Vorgang **erfolgreich** abgeschlossen ist, müssen Sie den Container `sharelatex` wieder starten. Führen Sie dazu `bin/docker-compose start sharelatex` aus, wenn Sie eine Toolkit-Bereitstellung verwenden, bzw. `docker compose start sharelatex`, wenn Sie Docker Compose verwenden.

<Danger>
  * Backups sollten auf einem anderen Server gespeichert werden als dem, auf dem Ihre Overleaf-Instanz läuft – idealerweise an einem ganz anderen Standort.
  * Die Replikation von Datenbanken auf mehrere MongoDB-Instanzen bietet zwar eine gewisse Redundanz, schützt jedoch nicht vor Datenbeschädigung.
  * Das Testen Ihrer Backups ist der beste Weg, um sicherzustellen, dass sie vollständig und funktionsfähig sind.
</Danger>

### MongoDB

MongoDB enthält ein Kommandozeilenwerkzeug namens [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/), mit dem Sie ein Backup der in der Datenbank gespeicherten Benutzer- und Projektdaten erstellen können.

### Daten des Overleaf-Dateisystems

Bei Toolkit-Bereitstellungen wird der Pfad, unter dem Ihre nicht bearbeitbaren Dateien gespeichert sind, in `config/overleaf.rc` über die Umgebungsvariable `OVERLEAF_DATA_PATH` festgelegt. Je nachdem, wann Ihre Instanz erstellt wurde, kann dies jedoch auch `data/sharelatex` sein.

Um ein vollständiges Backup zu erstellen, müssen Sie dieses Verzeichnis mit einem Werkzeug wie **rsync** rekursiv kopieren.

### Redis

Redis speichert Benutzersitzungen und ausstehende Dokumentaktualisierungen, bevor diese in MongoDB geschrieben werden.

Die Persistenz per Append Only File (AOF) ist die empfohlene Konfiguration für die Redis-Persistenz.

Bei Toolkit-Nutzern ist die AOF-Persistenz für **neue** Installationen standardmäßig aktiviert. Bestehende Nutzer finden weitere Informationen zur Aktivierung von AOF [hier](/de/on-premises/configuration/overleaf-toolkit/redis#enabling-append-only-file-persistence).

Wenn Sie RDB-Snapshots weiterhin zusammen mit der AOF-Persistenz verwenden möchten, können Sie die RDB-Datei als Backup an einen sicheren Ort kopieren.

### Daten zwischen Servern migrieren

Im besten Fall befinden sich in der neuen Instanz noch keine wertvollen Daten. Wir haben kein Verfahren, um die Daten mehrerer Instanzen zusammenzuführen.

Angenommen, die neue Instanz enthält noch keine Daten, können Sie die folgenden Schritte ausführen. Grob gesagt erstellen wir ein Tar-Archiv der Volumes `mongo`, `redis` und `overleaf`, kopieren es auf den neuen Server und entpacken es dort wieder.

#### Toolkit

```bash theme={null}
# Gracefully shutdown the old instance
old-server$ bin/stop

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar config/ data/

# Copy the backup-old-server.tar file from the old-server to the
# new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ bin/stop

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# Populate config/data dir again
new-server$ tar --extract --file backup-old-server.tar

# Start containers
new-server$ bin/up
```

#### Docker Compose

```bash wrap theme={null}
# Gracefully shutdown the old instance
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Copy the backup-old-server.tar file from the old-server to
# the new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Populate data dirs again
new-server$ tar --extract --file backup-old-server.tar

# Start containers
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

Je nach Ihrer **docker-compose.yml**-Datei müssen Sie möglicherweise die Pfade der Volumes `mongo`, `redis` und `overleaf` anpassen.

<Info>
  Wenn tar als Root-Benutzer (oder mit sudo) ausgeführt wird, bleiben Eigentümer/Gruppe und Berechtigungen der Dateien erhalten, was für die Wiederherstellung des Backups entscheidend ist.
</Info>

### Ordner im Detail

<Info>
  Die folgenden Ordner sind mit zusätzlichen Hinweisen versehen:

  * (b) in Backups einbeziehen, am besten bei gestoppter Instanz, um Konsistenz sicherzustellen
  * (d) kann gelöscht werden
  * (e) flüchtige Dateien, können bei gestoppter Instanz gelöscht werden
</Info>

1. `~/mongo_data` (b)
   * MongoDB-Datenverzeichnis
2. `~/redis_data` (b)
   * Datenverzeichnis der Redis-Datenbank
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * im aktuellen Release nicht verwendet; früher wurde eine angepasste synctex-Binärdatei verwendet (synctex dient der Quellzuordnung zwischen .tex-Dateien und dem PDF)
   2. data
      1. cache (e)
         * Cache für Binärdateien bei Kompilierungen
      2. compiles (e)
         * hier findet die LaTeX-Kompilierung statt
      3. db.sqlite (d)
         * im aktuellen Release nicht verwendet; speicherte früher Details zum clsi-Cache (diese werden jetzt entweder in einfachen In-Memory-Maps gehalten oder durch Scannen der Festplatte ermittelt)
      4. db.sqlite-wal (d)
         * im aktuellen Release nicht verwendet, siehe db.sqlite
      5. output (e)
         * Speicher für die Ausgabe der LaTeX-Kompilierung zur Auslieferung an den Client
      6. template\_files (b)
         * Bildvorschauen des Vorlagensystems (nur Server Pro)
      7. user\_files (b)
         * Binärdateien der Projekte
      8. history (b)
         * Dateien des vollständigen Projektverlaufs
   3. tmp
      1. dumpFolder (e)
         * temporäre Dateien aus der Verarbeitung von ZIP-Dateien
      2. uploads (e)
         * Zwischenspeicher für Datei-Uploads (Upload von Binärdateien/neuem Projekt aus ZIP)
      3. projectHistories (e)
         * temporäre Dateien für Migrationen des vollständigen Projektverlaufs


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.