> 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/doc-version-recovery.md).

# (Migration v5.0.1) Wiederherstellung der Dokumentversion

{% hint style="info" %}
Wenn Sie Server Pro Version 5.0.1 oder Community Edition Version 5.0.1 nie ausgeführt haben oder mit 5.0.1 eine brandneue Instanz gestartet haben, müssen Sie diesen Wiederherstellungsprozess nicht ausführen.
{% endhint %}

**Aktualisierungen dieser Seite:**

* (2024-04-22 13:40 BST): Schritt „Neue Aktualisierungen daran hindern, ins System zu gelangen, und alle Änderungen in 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 verwendeten Speicher-Backend des History-Store für Chunks ab (wie definiert in `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Der Wiederherstellungsprozess verzögert den Anwendungsstart im Server-Pro-Container. Die Site wird in dieser Zeit offline erscheinen. Wir unterstützen die Ausführung der Wiederherstellung nur von einer einzelnen Instanz des Server-Pro-Containers aus; alle anderen Worker für horizontale Skalierung müssen offline sein.

Sie können den Wiederherstellungsprozess bei Bedarf anhalten und fortsetzen.

Basierend auf unseren Leistungstests kann der Wiederherstellungsprozess auf moderner Hardware (3-GHz-CPU-Takt und lokaler NVMe-Speicher) ungefähr 10.000 kleine Projekte pro Minute verarbeiten. Zum Beispiel sollten Sie für eine Instanz mit 100.000 Projekten ein Wartungsfenster planen, das mindestens 10+2 Min. Ausfallzeit zulässt. Verwenden Sie die folgende Abfrage, um die Anzahl der Projekte in Ihrer Instanz zu schätzen:

{% code overflow="wrap" %}

```bash
$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'
```

{% endcode %}

Bitte lesen Sie die folgenden Wiederherstellungsschritte vollständig durch, bevor Sie beginnen. Server-Pro-Kunden können sich bei Fragen jederzeit an <support@overleaf.com> wenden.

### Wiederherstellungsprozess

{% stepper %}
{% step %}

#### Release-Images ziehen

Ziehen Sie die `5.0.3` Release-Images.
{% endstep %}

{% step %}

#### Einige Projekte identifizieren

Identifizieren Sie einige Projekte anhand ihrer ID, deren Verlauf fehlt; idealerweise haben Sie die Berechtigung, an einem davon eine Änderung vorzunehmen.
{% endstep %}

{% step %}

#### Wartung planen

Planen Sie ein Wartungsfenster für die Ausfallzeit.
{% endstep %}

{% step %}

#### Alle bis auf einen Worker stoppen

Stoppen Sie bei einem Setup mit horizontaler Skalierung alle bis auf einen Worker.
{% endstep %}

{% step %}

#### Neue Aktualisierungen stoppen und alle Änderungen in MongoDB flushen

Verhindern Sie, dass neue Aktualisierungen ins System gelangen, und flushen Sie alle Änderungen in MongoDB:

1. Schließen Sie den Editor und trennen Sie alle Benutzer manuell über das Admin-Panel auf `https://my-server-pro.example.com/admin#open-close-editor` im Tab „Editor öffnen/schließen“.
2. Stoppen Sie den Websocket-/Echtzeitdienst.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Warten Sie, bis der Echtzeitdienst beendet ist, erkennbar an `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # etwas länger warten...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normalerweise aktiv
   ```
4. Stoppen Sie den git-bridge-Container, falls aktiviert.

   ```bash
   $ docker stop git-bridge
   ```
5. Wenn Sie 5.0.2 nie ausgeführt haben: Führen Sie einen manuellen Flush für Dokumentaktualisierungen aus und warten Sie, bis er erfolgreich abgeschlossen ist.

   Sie können den Befehl bei einem Fehler wiederholen. Falls Sie in aufeinanderfolgenden Ausführungen einen von null verschiedenen `failureCount` sehen, stoppen Sie bitte die Migration (stellen Sie die Dienste wieder her über `docker restart git-bridge sharelatex`) und wenden Sie sich an den Support.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /etc/overleaf/env.sh &#x26;&#x26; cd services/document-updater &#x26;&#x26; LOG_LEVEL=info node scripts/flush_all.js'
   ...
   {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"alle Projekte erfolgreich geflusht","time":"...","v":0}
   Leeren aller Projekte abgeschlossen
   </code></pre>
6. Wenn Sie 5.0.2 nie ausgeführt haben: Stellen Sie sicher, dass alle Änderungen aus Redis herausgeflusht wurden.

   Wenn Sie irgendeine Ausgabe von `redis-cli`, stoppen Sie bitte die Migration (stellen Sie die Dienste wieder her über `docker restart git-bridge sharelatex`) und wenden Sie sich an den Support.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # Keine Ausgabe von redis-cli bedeutet Erfolg; prüfen Sie als Nächstes den Exit-Code von redis-cli, er sollte null sein
   $ echo $?
   0
   </code></pre>
7. Versuchen Sie, ausstehende Verlaufsänderungen zu flushen.

   Dies muss ein Flush nach bestem Bemühen sein, da einige Projekte aufgrund der fehlerhaften Datenbankmigration defekte Verläufe haben. Etwaige Fehler werden am Ende des Wiederherstellungsprozesses durch eine erneute Synchronisierung des Verlaufs behoben.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /
   </code></pre>

{% endstep %}

{% step %}

#### Ein Backup erstellen

Erwägen Sie, ein [konsistentes Backup](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) Backup der Instanz zu erstellen.
{% endstep %}

{% step %}

#### Aktualisieren

Auf Version aktualisieren `5.0.3`.
{% endstep %}

{% step %}

#### Automatische Wiederherstellung

Der Wiederherstellungsprozess wird beim Start des Containers automatisch ausgeführt.
{% endstep %}

{% step %}

#### Fortschritt verfolgen

Sie können den Fortschritt des Skripts verfolgen, indem Sie die Logdatei `/var/lib/overleaf/data/history/doc-version-recovery.log`. Sie gibt zu Beginn die Gesamtzahl der Projekte aus und nach jeweils 1000 verarbeiteten Projekten eine Zusammenfassung.

{% code overflow="wrap" %}

```bash
$ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
```

{% endcode %}
{% endstep %}

{% step %}

#### Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist

Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist, indem Sie entweder die obige Logdatei verfolgen, bis eine `Zeile ausgegeben wurde, oder warten Sie darauf` dass `Wiederherstellung der Dokumentversionen abgeschlossen.` auf der Standardausgabe des Server-Pro-Containers ausgegeben zu werden.
{% endstep %}

{% step %}

#### Validieren Sie den Wiederherstellungsprozess

Validieren Sie den Wiederherstellungsprozess, indem Sie das Verlaufsfenster für einige der Projekte öffnen, bei denen zuvor der Verlauf fehlte.

1. Beschleunigen Sie die Resynchronisierung für die zu testenden Projekte. (Sie werden irgendwann verarbeitet, aber wir wollen nicht warten, bis sie an der Reihe sind.)

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
   </code></pre>

   (Wiederholen Sie dies für jede der zu testenden Projekt-IDs, ersetzen Sie `000000000000000000000000` jeweils nur eine Projekt-ID.)
2. Öffnen Sie den Projekteditor für die Projekte `https://my-server-pro.example.com/project/000000000000000000000000`
3. Öffnen Sie das Fenster „Verlauf“ für das Projekt und sehen Sie sich den neuesten Inhalt an.
4. Optional: Schließen Sie das Fenster „Verlauf“ erneut. Nehmen Sie eine Codeänderung vor, z. B. indem Sie einen Kommentar zum Header hinzufügen.
5. Optional: Führen Sie einen erneuten Kompiliervorgang aus, um das Flushen der lokalen Änderung auszulösen. Öffnen Sie das Fenster „Verlauf“ erneut und sehen Sie sich die Änderung an. Wenn Sie fertig sind, machen Sie die Änderung rückgängig.
   {% endstep %}

{% step %}

#### Für horizontale Skalierung...

Starten Sie die anderen Worker erneut.
{% endstep %}

{% step %}

#### Lassen Sie die Instanz weiterlaufen

Bitte lassen Sie die Instanz, die den Wiederherstellungsprozess ausgeführt hat, weiterlaufen. Dadurch wird der Verlauf aller Projekte im Hintergrund mit einer Parallelität von 1 erneut synchronisiert. Dies führt zu einer leicht erhöhten Grundlast. (Sie können die Instanz neu starten, aber dann muss sie die Resynchronisierung von vorne beginnen.)
{% endstep %}

{% step %}

#### Lassen Sie uns wissen, wenn Sie fertig sind

Server-Pro-Kunden: Bitte informieren Sie das Support-Team, wenn Sie den Wiederherstellungsprozess abgeschlossen haben.
{% endstep %}
{% endstepper %}


---

# 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/doc-version-recovery.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.