> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/de/support/support-guides/full-project-history-migration.md).

# (Migration v3.5.13) Migration des vollständigen Projektverlaufs

## Migration des vollständigen Projektverlaufs

Das `3.5.x` Die Veröffentlichung der Community Edition umfasst das [Feature „Vollständiger Projektverlauf“](https://www.overleaf.com/learn/latex/Using_the_History_feature) das bereits in unserem SaaS-Angebot verfügbar ist, [overleaf.com](http://overleaf.com/)

Nachdem Sie Ihre Instanz auf Overleaf CE aktualisiert haben `3.5.13`, werden alle neuen Projekte standardmäßig den vollständigen Projektverlauf verwenden. Bestehende Projekte verwenden weiterhin das alte Verlaufssystem, bis sie migriert werden.

{% hint style="info" %}
Wenn Sie auf `3.5.13` und sich entscheiden, auf eine frühere Version zurückzustufen, sollten Sie aus einem vollständigen Systembackup wiederherstellen. Der Verlauf von Projekten, die in `3.5.13` ist nicht mit früheren Versionen von Overleaf CE kompatibel.
{% endhint %}

Der neue vollständige Projektverlauf bringt mehrere Verbesserungen für Nutzer:

* Er verfolgt Änderungen in Binärdateien, was im alten System nicht unterstützt wird.
* Es gibt Unterstützung für gekennzeichnete Versionen.
* Das System ist insgesamt robuster, es besteht ein geringeres Risiko von Datenverlust.

Siehe [Dokumentation zum vollständigen Projektverlauf](https://www.overleaf.com/learn/latex/Using_the_History_feature) für weitere Informationen zum vollständigen Projektverlauf.

### Bestehende Projekte migrieren

{% stepper %}
{% step %}

#### Erstellen Sie ein Backup

Erstellen Sie ein vollständiges [Backup](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) Ihrer Instanz mit einem konsistenten Snapshot der **mongo**, **redis** und **sharelatex** Verzeichnisse.
{% endstep %}

{% step %}

#### Aktualisieren Sie

Aktualisieren Sie die Version des Images sharelatex/sharelatex auf 3.5.13.

Toolkit: Verwenden Sie das `$ bin/upgrade` Skript, um das Toolkit auf die neueste Version zu aktualisieren, und bearbeiten Sie **config/version** auf 3.5.13.
{% endstep %}

{% step %}

#### Starten Sie die Instanz

Idealerweise sollten Sie verhindern, dass Benutzer während der Migration auf Ihre Instanz zugreifen, um Datenverlust zu vermeiden, falls Sie Ihr Backup wiederherstellen müssen. Siehe [Offline-Migration](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) für weitere Informationen dazu.
{% endstep %}

{% step %}

#### Warten Sie, bis alle Dienste gestartet und ausgeführt werden

Warten Sie, bis alle Dienste gestartet und ausgeführt werden (siehe Befehl unten)

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status"
web sharelatex ist aktiv (api)%
```

{% endcode %}
{% endstep %}

{% step %}

#### Führen Sie das Migrationsskript aus

{% code overflow="wrap" %}

```bash
# Für Benutzer des Overleaf Toolkits:
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"

# Für Benutzer der alten docker-compose.yml:
$ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"
```

{% endcode %}

`--force-clean` löscht teilweise migrierte Projektverlaufsdaten im neuen System; dadurch kann die Migration für einzelne Projekte, die bei früheren Versuchen fehlgeschlagen sind, erneut ausgeführt werden;

`--fix-invalid-characters` ersetzt nicht druckbare Zeichen, die vom neuen Verlaufssystem nicht unterstützt werden;

`--convert-large-docs-to-file` konvertiert Dokumente, die die 2-MB-Schwelle für die Bearbeitungsgröße überschreiten, in eine nicht bearbeitbare Datei)

Die Ausgabe sollte wie folgt aussehen:

```bash
Migrierte Projekte  :  1
Gesamtprojekte     :  51
Verbleibende Projekte :  51
Insgesamt zu migrierende Verlaufsdatensätze: 98
Migration wird gestartet...
Projekt wird migriert: 63d29b5772dd80015a81bffe
Migrationsergebnis { upgraded: true, historyType: 'NoneWithoutConversion' }
Projekt wird migriert: 63d29c2e72dd80015a81c0a2
Migrationsergebnis { upgraded: true, historyType: 'NoneWithoutConversion' }

// …

Migration abgeschlossen
==================
Migrierte Projekte:  51
Fehlgeschlagene Projekte:  0
Abgeschlossen.
```

Wenn die Migration erfolgreich ist, erhalten Sie einen Exit-Code von `0`, und die letzten Zeilen weisen auf keine Fehler hin:

```bash
Fehlgeschlagene Projekte:  0
Abgeschlossen.
```

Sie können den Zugriff für Ihre Nutzer wieder freigeben (siehe nächster Schritt). Wenn es Fehler gibt, lesen Sie bitte den Abschnitt zur Fehlerbehebung unten. Sie können die Seite trotzdem wieder freigeben, wenn die Probleme nicht sofort behoben werden, und die nicht migrierten Projekte verbleiben im alten Verlaufssystem.
{% endstep %}

{% step %}

#### Die Seite wieder freigeben

Wenn Sie sich für eine Offline-Migration entschieden haben, müssen Sie die Seite erneut freigeben. Falls Sie noch angemeldet sind, müssen Sie:

1. Klicken Sie auf die **Admin** Schaltfläche und wählen Sie **Website verwalten**
2. Klicken Sie auf die **Editor öffnen/schließen** Tab
3. Klicken Sie auf die **Editor erneut öffnen** Schaltfläche

Wenn Sie Ihren Browser geschlossen haben, müssen Sie die Seite neu starten mit `$ bin/up`.
{% endstep %}
{% endstepper %}

#### Offline-Migration

Um zu verhindern, dass sich Benutzer anmelden können, während das Verlaufsmigrationsskript ausgeführt wird, befolgen Sie bitte diese Schritte:

* Melden Sie sich mit einem Administratorkonto bei Ihrer Overleaf-Instanz an
* Klicken Sie auf die **Admin** Schaltfläche und wählen Sie **Website verwalten**
* Klicken Sie auf die **Editor öffnen/schließen** Tab
* Klicken Sie auf die **Editor schließen** Schaltfläche
* Klicken Sie auf die **Alle Benutzer trennen** Schaltfläche

Sobald dies erledigt ist, werden bereits angemeldete Benutzer auf die Wartungsseite umgeleitet, und neue Benutzer, die die Anmeldeseite aufrufen, sehen die Wartungsseite und **können sich nicht** anmelden.

#### Online-Migration

Es ist möglich, die Migrationsskripte auszuführen, während die Anwendung weiterhin läuft. Es gibt einige Punkte zu beachten:

* Der Migrationsprozess ist CPU-intensiv; Sie sollten die Ressourcennutzung überwachen, während das Skript läuft.
* Bei einem hohen `--concurrency` Wert kann die Event-Schleife in einigen Diensten (`track-changes` insbesondere) etwas blockiert werden, was zu einer schlechteren Benutzererfahrung führen würde. Wir empfehlen, mit dem Standardwert `--concurrency=1` zu beginnen.
* Sie können das Skript jederzeit stoppen. Wenn Sie es erneut starten, wird die Migration an der Stelle fortgesetzt, an der Sie aufgehört haben. Das ist nützlich, wenn Sie die Migration lieber zu weniger ausgelasteten Zeiten ausführen möchten (z. B. nachts).

Unsere Empfehlung ist, die Seite zu schließen und die Migration offline in einem Wartungsfenster auszuführen, wenn Ihre Projektanzahl weniger als 1000 Projekte beträgt (`db.projects.count()`). Wenn die Anzahl der Projekte groß ist, können Sie das Skript ausführen und seinen Fortschritt überwachen und dann je nach Situation entscheiden, ob Sie es online oder offline weiter ausführen.

#### Alte Verlaufsdaten bereinigen

Ein Skript zum Bereinigen alter Verlaufsdaten wurde in Server Pro hinzugefügt `3.5.6`, `4.0.6` und `4.1.0`.

{% code overflow="wrap" %}

```bash
bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/history/clean_sl_history_data.js"
```

{% endcode %}

Das Skript kann ausgeführt werden, nachdem alle Projekte migriert wurden. Es kann auch verwendet werden, um während einer Online-Migration etwas Speicherplatz freizugeben.

{% hint style="info" %}
In Server Pro vor Version 3.5.13 löscht das Skript den Inhalt von `docHistory` und `docHistoryIndex` Sammlungen. MongoDB gibt nach dem Löschen von Dokumenten keinen Festplattenspeicher frei, sondern verwendet diesen Speicher für zukünftige Dokumente in derselben Sammlung erneut. Nach der Verlaufsmigration wird nichts mehr in diese Sammlungen schreiben, daher bleibt der Speicherplatz ungenutzt.

Wenn Sie den Speicherplatz wieder verfügbar machen möchten, können Sie auf Server Pro 3.5.13 (wenn Sie noch die 3.x-Version verwenden) oder Server Pro 4.2.5 (wenn Sie die 4.x-Version verwenden) aktualisieren und das Bereinigungsskript erneut ausführen.

Das in Server Pro enthaltene Bereinigungsskript in den neuesten Patch-Releases von `3.5.x` und den neuesten `4.x.x` entfernt die Sammlungen als letzten Schritt.

Es ist sicher, das Bereinigungsskript erneut auszuführen.
{% endhint %}

### Fehlerbehebung

Hier werden wir Hinweise zur Fehlerbehebung hinzufügen. Bitte beachten Sie, dass wir zwar normalerweise nur Server-Pro-Kunden unterstützen, wir aber angesichts der Art dieser Migration auch unser Bestes tun werden, um CE-Kunden zu unterstützen, die bei der Migration zum vollständigen Projektverlauf spezifische Probleme haben.

Wenn das Migrationsskript für den vollständigen Projektverlauf fehlschlägt (d. h. mit einem Fehler beendet wird oder eine von null verschiedene Anzahl fehlgeschlagener Projekte ausgibt), senden Sie bitte die folgenden Details per E-Mail an unser Support-Team [support+historymigration@overleaf.com](mailto:support+historymigration@overleaf.com?subject=Full%20project%20history%20migration%20problem\&body=Instance%20Type%3A%20CE%20or%20Server%20Pro%20%28delete%20as%20appropriate%29%0A%0AInstallation%20Type%3A%20Overleaf%20toolkit%20or%20docker-compose.yml%20or%20other%20%28delete%20as%20appropriate%29%0A%0AScript%20output%3A%0A%0Abin%2Fdoctor%20output%20%28if%20using%20toolkit%29%3A%0A), mit folgenden Angaben:

Betreff: Problem bei der Migration des vollständigen Projektverlaufs

* Instanztyp: CE oder Server Pro (je nach Bedarf löschen)
* Installationstyp: Overleaf Toolkit oder `docker-compose.yml` oder andere (je nach Bedarf löschen)
* Version: 3.5.x (Toolkit: `$ cat config/version`)
* Ausgabe des Migrationsskripts (die sich im Container unter `/overleaf/services/web`)
* Migrierte Projekte: (gemäß Ausgabe des Migrationsskripts)
* Gesamtprojekte: (gemäß Ausgabe des Migrationsskripts)
* Verbleibende Projekte: (gemäß Ausgabe des Migrationsskripts)
* Dauer der Migration:
* `bin/doctor` Ausgabe (bei Verwendung des Toolkits)
* Toolkit-Version: `$ git rev-parse HEAD` (bei Verwendung des Toolkits)

Erwägen Sie, die Protokolldateien für die `history-v1`, `project-history` und `track-changes` Dienste an die E-Mail anzuhängen. Sie finden diese unter `/var/log/sharelatex` im `sharelatex` Container und exportieren Sie sie wie folgt:

```bash
$ docker cp sharelatex:/var/log/sharelatex/history-v1.log history-v1.log
$ docker cp sharelatex:/var/log/sharelatex/project-history.log project-history.log
$ docker cp sharelatex:/var/log/sharelatex/track-changes.log track-changes.log
```

Bitte schwärzen Sie alle sensiblen Informationen in den Protokolldateien, bevor Sie sie anhängen.

#### Fehlerhafte Dateibäume finden

Die Migration kann bei Projekten fehlschlagen, die einen fehlerhaften Dateibaum haben (zum Beispiel, wenn Dateinamen leer sind). Eine Liste dieser Probleme finden Sie mit dem `find_malformed_filetrees` Skript, das alle Projekte in der Datenbank überprüft:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js"
BAD PATH: 123456789012345678901234 rootFolder.0.1.2.3
BAD PATH: 123456789012345678901234 rootFolder.0.4.5.6
...
```

{% endcode %}

Um die ungültigen Pfade zu beheben, verwenden Sie das `fix_malformed_filetree` Skript und führen Sie den Befehl für jeden fehlerhaften Pfad einmal aus:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.1.2.3"
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.4.5.6"
...
```

{% endcode %}

#### Projekte vom vollständigen Projektverlauf auf den alten Verlauf herabstufen

Wenn es ein Projekt gibt, das auf den vollständigen Projektverlauf migriert wurde, Sie aber zum alten Verlauf zurückkehren möchten, verwenden Sie das `downgrade_project` Skript wie folgt:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=YOUR
```

{% endcode %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ayakaleaf-pro.ayaka.space/on-premises/de/support/support-guides/full-project-history-migration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
