> ## 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. # (v5.0.1-Migration) Wiederherstellung von Dokumentversionen Wenn Sie nie Server Pro Version 5.0.1 oder Community Edition Version 5.0.1 betrieben haben oder eine komplett neue Instanz mit 5.0.1 gestartet haben, müssen Sie diesen Wiederherstellungsprozess nicht ausführen. Aktualisierungen dieser Seite: * (2024-04-22 13:40 BST): Schritt „Neue Updates am Eindringen in das System hindern und alle Änderungen nach MongoDB flushen" hinzugefügt. * (2024-04-23 11:45 BST): Fehlerhafte Flushes in 5.0.1 berücksichtigt und Flushes übersprungen, wenn 5.0.2 gestartet wurde. Die Dauer der Wiederherstellung hängt von der Anzahl und Größe der Projekte in Ihrer Instanz sowie vom Speicher-Backend ab, das der History Store für Chunks verwendet (wie in `OVERLEAF_HISTORY_CHUNKS_BUCKET` definiert). Der Wiederherstellungsprozess verzögert den Anwendungsstart im Server-Pro-Container. Die Website erscheint in dieser Zeit offline. Wir unterstützen die Wiederherstellung nur aus einer einzigen Instanz des Server-Pro-Containers; alle anderen Worker für horizontale Skalierung müssen offline sein. Sie können den Wiederherstellungsprozess bei Bedarf anhalten und fortsetzen. Laut unseren Performance-Tests kann der Wiederherstellungsprozess auf moderner Hardware (3 GHz CPU-Takt und lokaler NVMe-Speicher) etwa 10.000 kleine Projekte pro Minute verarbeiten. Planen Sie beispielsweise für eine Instanz mit 100.000 Projekten ein Wartungsfenster mit mindestens 10+2 Minuten Ausfallzeit ein. Mit der folgenden Abfrage können Sie die Anzahl der Projekte in Ihrer Instanz schätzen: ```bash wrap theme={null} $ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()' ``` Bitte lesen Sie die folgenden Wiederherstellungsschritte vollständig durch, bevor Sie beginnen. Server-Pro-Kunden können sich bei Fragen jederzeit gerne an [support@overleaf.com](mailto:support@overleaf.com) wenden. ### Wiederherstellungsprozess Laden Sie die Release-Images `5.0.3` herunter. Identifizieren Sie anhand ihrer ID einige Projekte, denen der Verlauf fehlt; idealerweise haben Sie die Berechtigung, an einem davon eine Änderung vorzunehmen. Planen Sie ein Wartungsfenster für die Ausfallzeit ein. Stoppen Sie bei einem Setup mit horizontaler Skalierung alle Worker bis auf einen. Verhindern Sie, dass neue Updates in das System gelangen, und flushen Sie alle Änderungen nach MongoDB: 1. Schließen Sie den Editor und trennen Sie alle Benutzer manuell über das Admin-Panel unter `https://my-server-pro.example.com/admin#open-close-editor` im Tab „Open/Close Editor". 2. Stoppen Sie den Websocket-/Echtzeitdienst. ```bash theme={null} $ docker exec sharelatex sv stop real-time-overleaf ``` 3. Warten Sie, bis der Echtzeitdienst beendet ist, erkennbar an `down:`. ```bash theme={null} $ docker exec sharelatex sv status real-time-overleaf run: real-time-sharelatex: (pid 394) 50s, want down, got TERM # wait a little longer... $ docker exec sharelatex sv status real-time-overleaf down: real-time-sharelatex: 7s, normally up ``` 4. Stoppen Sie den git-bridge-Container, falls aktiviert. ```bash theme={null} $ docker stop git-bridge ``` 5. Falls Sie nie 5.0.2 betrieben haben: Lösen Sie einen manuellen Flush der Dokumentaktualisierungen aus und warten Sie, bis er erfolgreich abgeschlossen ist. Bei einem Fehler können Sie den Befehl wiederholen. Wenn Sie bei aufeinanderfolgenden Durchläufen einen `failureCount` ungleich null sehen, brechen Sie die Migration bitte ab (stellen Sie die Dienste mit `docker restart git-bridge sharelatex` wieder her) und wenden Sie sich an den Support. ```bash wrap theme={null} $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /etc/overleaf/env.sh && cd services/document-updater && LOG_LEVEL=info node scripts/flush_all.js' ... {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"finished flushing all projects","time":"...","v":0} Done flushing all projects ``` 6. Falls Sie nie 5.0.2 betrieben haben: Stellen Sie sicher, dass alle Änderungen aus Redis geflusht wurden. Wenn `redis-cli` eine Ausgabe liefert, brechen Sie die Migration bitte ab (stellen Sie die Dienste mit `docker restart git-bridge sharelatex` wieder her) und wenden Sie sich an den Support. ```bash wrap theme={null} $ docker exec redis redis-cli --scan --pattern 'DocVersion:*' # no output from redis-cli indicates success, check exit code of redis-cli next, it should be zero $ echo $? 0 ``` 7. Versuchen Sie, alle ausstehenden Verlaufsänderungen zu flushen. Dies ist ein Best-Effort-Flush, da einige Projekte aufgrund der fehlerhaften Datenbankmigration einen beschädigten Verlauf haben. Alle Fehler werden am Ende des Wiederherstellungsprozesses durch eine erneute Synchronisierung des Verlaufs behoben. ```bash wrap theme={null} $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source / ``` Erwägen Sie, ein [konsistentes Backup](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) der Instanz zu erstellen. Führen Sie ein Upgrade auf Version `5.0.3` durch. Der Wiederherstellungsprozess wird beim Start des Containers automatisch ausgeführt. Sie können den Fortschritt des Skripts verfolgen, indem Sie die Logdatei `/var/lib/overleaf/data/history/doc-version-recovery.log` mit tail beobachten. Zu Beginn wird die Gesamtzahl der Projekte ausgegeben und danach nach jeweils 1000 verarbeiteten Projekten eine Zusammenfassung. ```bash wrap theme={null} $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers ``` Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist – entweder indem Sie die obige Logdatei verfolgen, bis eine Zeile `Done.` ausgegeben wird, oder indem Sie warten, bis `Finished recovery of doc versions.` in der Standardausgabe des Server-Pro-Containers erscheint. Überprüfen Sie den Wiederherstellungsprozess, indem Sie den Verlaufsbereich für einige der Projekte öffnen, denen zuvor der Verlauf fehlte. 1. Beschleunigen Sie die erneute Synchronisierung der zu testenden Projekte. (Sie werden irgendwann ohnehin verarbeitet, aber wir möchten nicht warten, bis sie an der Reihe sind.) ```bash wrap theme={null} $ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true" ``` (Wiederholen Sie dies für jede zu testende Projekt-ID und ersetzen Sie `000000000000000000000000` jeweils durch eine Projekt-ID.) 2. Öffnen Sie den Projekteditor für die Projekte unter `https://my-server-pro.example.com/project/000000000000000000000000`. 3. Öffnen Sie den Bereich „History" des Projekts und prüfen Sie den neuesten Inhalt. 4. Optional: Schließen Sie den Bereich „History" wieder. Nehmen Sie eine Codeänderung vor, etwa indem Sie im Header einen Kommentar hinzufügen. 5. Optional: Lösen Sie eine erneute Kompilierung aus, um einen Flush der lokalen Änderung anzustoßen. Öffnen Sie den Bereich „History" erneut und prüfen Sie die Änderung. Machen Sie die Änderung anschließend rückgängig. Starten Sie die anderen Worker wieder. Lassen Sie die Instanz, die den Wiederherstellungsprozess ausgeführt hat, bitte weiterlaufen. Sie synchronisiert den Verlauf aller Projekte im Hintergrund mit einer Parallelität von 1 neu. Dies führt zu einer leicht erhöhten Grundlast. (Sie können die Instanz neu starten, die erneuten Synchronisierungen beginnen dann jedoch von vorn.) Server-Pro-Kunden: Bitte informieren Sie das Support-Team, sobald Sie den Wiederherstellungsprozess abgeschlossen haben. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.