> For the complete documentation index, see [llms.txt](https://overleaf-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://overleaf-pro.ayaka.space/on-premises/de/support/support-guides/full-project-history-migration.md). # (Migration v3.5.13) Migration der vollständigen Projekt-Historie ## Migration der vollständigen Projekt-Historie Die `3.5.x` die Veröffentlichung der Community Edition enthält die [Full Project History-Funktion](https://www.overleaf.com/learn/latex/Using_the_History_feature) die 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 Full Project History verwenden. Bestehende Projekte verwenden weiterhin das alte History-System, bis sie migriert wurden. {% hint style="info" %} Wenn Sie ein Upgrade auf `3.5.13` durchführen und sich dann für ein Downgrade auf eine frühere Version entscheiden, sollten Sie aus einem vollständigen System-Backup wiederherstellen. Die Historie von Projekten, die in `3.5.13` erstellt wurden, ist mit früheren Versionen von Overleaf CE nicht kompatibel. {% endhint %} Das neue Full Project History bringt mehrere Verbesserungen für Benutzer mit sich: * Es 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 für Datenverlust. Siehe [Dokumentation zu Full Project History](https://www.overleaf.com/learn/latex/Using_the_History_feature) für weitere Informationen zu Full Project History. ### Vorhandene Projekte migrieren {% stepper %} {% step %} #### Ein Backup erstellen 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 erstellen. {% endstep %} {% step %} #### Aktualisieren Sie Aktualisieren Sie die Version des sharelatex/sharelatex-Images 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 hochgefahren und ausgeführt werden Warten Sie, bis alle Dienste hochgefahren 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 # Overleaf-Toolkit-Benutzer: $ 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" # Benutzer von legacy 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` bereinigt teilweise migrierte Projekthistorien-Daten im neuen System; dadurch kann die Migration für einzelne Projekte, die bei früheren Versuchen fehlgeschlagen sind, erneut versucht werden; `--fix-invalid-characters` ersetzt nicht druckbare Zeichen, die vom neuen History-System nicht unterstützt werden; `--convert-large-docs-to-file` konvertiert Dokumente, die über dem bearbeitbaren Größenlimit von 2 MB liegen, in eine nicht bearbeitbare Datei) Die Ausgabe sollte so aussehen: ```bash Migrierte Projekte : 1 Gesamtzahl Projekte : 51 Verbleibende Projekte : 51 Gesamte zu migrierende Historiendatensätze: 98 Migration wird gestartet... Migriere Projekt: 63d29b5772dd80015a81bffe Migrationsergebnis { upgraded: true, historyType: 'NoneWithoutConversion' } Migriere Projekt: 63d29c2e72dd80015a81c0a2 Migrationsergebnis { upgraded: true, historyType: 'NoneWithoutConversion' } // … Migration abgeschlossen ================== Projekte migriert: 51 Projekte fehlgeschlagen: 0 Zeile ausgegeben wurde, oder warten Sie darauf ``` Wenn die Migration erfolgreich ist, erhalten Sie einen Exit-Code von `0`, und die letzten Zeilen weisen auf keine Fehler hin: ```bash Projekte fehlgeschlagen: 0 Zeile ausgegeben wurde, oder warten Sie darauf ``` Sie können den Zugriff für Ihre Benutzer wieder öffnen (siehe nächsten Schritt). Wenn es Fehler gibt, lesen Sie bitte den Abschnitt zur Fehlerbehebung unten. Sie können die Website auch dann wieder öffnen, wenn die Probleme nicht sofort behoben werden, und die nicht migrierten Projekte verbleiben im alten History-System. {% endstep %} {% step %} #### Website wieder öffnen Wenn Sie sich für eine Offline-Migration entschieden haben, müssen Sie die Website erneut öffnen. Wenn Sie noch angemeldet sind, müssen Sie: 1. Klicken Sie auf die **Admin** Schaltfläche und wählen Sie **Website verwalten** 2. Klicken Sie im Projektdashboard auf die **Editor öffnen/schließen** Registerkarte 3. Klicken Sie im Projektdashboard auf die **Editor erneut öffnen** Schaltfläche Wenn Sie Ihren Browser geschlossen haben, müssen Sie die Website neu starten mit `$ bin/up`. {% endstep %} {% endstepper %} #### Offline-Migration Um zu verhindern, dass sich Benutzer anmelden können, während das History-Migrationsskript 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 im Projektdashboard auf die **Editor öffnen/schließen** Registerkarte * Klicken Sie auf die **Editor schließen** Schaltfläche * Klicken Sie auf die **Alle Benutzer trennen** Schaltfläche Sobald dies erledigt ist, werden alle angemeldeten Benutzer zur Wartungsseite weitergeleitet, und alle neuen Benutzer, die die Anmeldeseite aufrufen, sehen die Wartungsseite und **werden nicht** sich anmelden können. #### Online-Migration Es ist möglich, die Migrationsskripte auszuführen, während die Anwendung noch läuft. Dabei sind einige Punkte zu beachten: * Der Migrationsprozess ist CPU-intensiv, Sie sollten die Ressourcennutzung überwachen, während das Skript ausgeführt wird. * Bei einem hohen `--concurrency` Wert kann der Event-Loop in einigen Diensten (`track-changes` insbesondere) etwas blockiert werden, was zu einer schlechteren UX 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 Website 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 den Fortschritt überwachen; danach können Sie je nach Situation entscheiden, ob Sie es online oder offline weiter ausführen. #### Legacy-Historiendaten bereinigen Ein Skript zum Bereinigen von Legacy-Historiendaten 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 Speicherplatz frei, sondern verwendet diesen Speicherplatz für zukünftige Dokumente in derselben Sammlung wieder. Nach der History-Migration 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-Versionen von `3.5.x` und den neuesten `4.x.x` löschen die Sammlungen als letzten Schritt. Das Bereinigungsskript kann sicher erneut ausgeführt werden. {% endhint %} ### Fehlerbehebung Wir werden hier Hinweise zur Fehlerbehebung hinzufügen. Bitte beachten Sie, dass wir normalerweise nur Server-Pro-Kunden Support anbieten; angesichts der Art dieser Migration werden wir jedoch auch unser Bestes tun, um CE-Kunden zu unterstützen, die Probleme haben, die speziell bei der Migration der vollständigen Projekt-Historie auftreten. Wenn das Migrationsskript für die vollständige Projekt-Historie 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), und geben Sie dabei Folgendes an: Betreff: Problem bei der Migration der vollständigen Projekt-Historie * Instanztyp: CE oder Server Pro (je nach Zutreffendem löschen) * Installationstyp: Overleaf Toolkit oder `docker-compose.yml` oder andere (je nach Zutreffendem löschen) * Version: 3.5.x (Toolkit: `$ cat config/version`) * Ausgabe des Migrationsskripts (die sich im Container unter befinden sollte `/overleaf/services/web`) * Migrierte Projekte: (gemäß Ausgabe des Migrationsskripts) * Gesamtzahl Projekte: (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 Logdateien der `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 so: ```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 Logdateien, bevor Sie sie anhängen. #### Beschädigte Dateistrukturen finden Die Migration kann bei Projekten fehlschlagen, die eine fehlerhafte Dateistruktur 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 prüft: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js" FEHLERHAFTER PFAD: 123456789012345678901234 rootFolder.0.1.2.3 FEHLERHAFTER PFAD: 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 von Full Project History auf die Legacy-Historie herabstufen Wenn es ein Projekt gibt, das auf Full Project History migriert wurde, Sie aber zur Legacy-Historie 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://overleaf-pro.ayaka.space/on-premises/de/support/support-guides/full-project-history-migration.md?ask=&goal= ``` `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.