> 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/nl/ondersteuning/support-guides/doc-version-recovery.md).

# (v5.0.1-migratie) Herstel van doc-versie

{% hint style="info" %}
Als u nooit Server Pro versie 5.0.1 of Community Edition versie 5.0.1 hebt uitgevoerd, of als u een gloednieuwe instantie met 5.0.1 hebt gestart, hoeft u dit herstelproces niet uit te voeren.
{% endhint %}

**Updates voor deze pagina:**

* (2024-04-22 13:40 BST): Stap "Voorkom dat nieuwe updates in het systeem terechtkomen en flush alle wijzigingen naar MongoDB" toegevoegd.
* (2024-04-23 11:45 BST): Houd rekening met mislukte flushes in 5.0.1 en sla flushes over wanneer 5.0.2 is gestart.

De duur van het herstel is afhankelijk van het aantal en de grootte van projecten in uw instantie en van de opslag-backend die door de history store voor chunks wordt gebruikt (zoals gedefinieerd in `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Het herstelproces vertraagt het opstarten van de applicatie binnen de Server Pro-container. De site lijkt in die tijd offline. We ondersteunen alleen het uitvoeren van het herstel vanaf één instantie van de Server Pro-container; alle andere workers voor horizontale schaalvergroting moeten offline zijn.

U kunt het herstelproces indien nodig stoppen en hervatten.

Op basis van onze prestatietests kan het herstelproces op moderne hardware (CPU-kloksnelheid van 3 GHz en lokale NVMe-opslag) ongeveer 10k kleine projecten per minuut verwerken. Als voorbeeld: plan voor een instantie met 100k projecten een onderhoudsvenster dat ten minste 10+2 min downtime toestaat. Gebruik de volgende query om het aantal projecten in uw instantie te schatten:

{% code overflow="wrap" %}

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

{% endcode %}

Lees de volgende herstelstappen volledig door voordat u begint. Server Pro-klanten mogen uiteraard contact opnemen met <support@overleaf.com> met vragen.

### Herstelproces

{% stepper %}
{% step %}

#### Release-images ophalen

Haal de `5.0.3` release-images op.
{% endstep %}

{% step %}

#### Identificeer een paar projecten

Identificeer een paar projecten op id waarvan de geschiedenis ontbreekt; bij voorkeur hebt u toestemming om in een van deze een wijziging aan te brengen.
{% endstep %}

{% step %}

#### Plan onderhoud

Plan een onderhoudsvenster voor de downtime.
{% endstep %}

{% step %}

#### Stop alle workers behalve één

Stop alle workers behalve één bij gebruik van een opstelling voor horizontale schaalvergroting.
{% endstep %}

{% step %}

#### Stop nieuwe updates en flush alle wijzigingen naar MongoDB

Voorkom dat nieuwe updates in het systeem terechtkomen en flush alle wijzigingen naar MongoDB:

1. Sluit de editor en koppel alle gebruikers handmatig los via het beheerpaneel op `https://my-server-pro.example.com/admin#open-close-editor` in het tabblad "Editor openen/sluiten".
2. Stop de websocket-/real-time-service.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Wacht tot de real-time service is beëindigd, zoals aangegeven door `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # wacht nog even langer...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normaal gesproken up
   ```
4. Stop de git-bridge-container indien ingeschakeld.

   ```bash
   $ docker stop git-bridge
   ```
5. Als u nooit 5.0.2 hebt uitgevoerd: voer handmatig een flush uit voor documentupdates en wacht tot die succesvol is afgerond.

   U kunt de opdracht herhalen bij een fout. Als u bij opeenvolgende uitvoeringen een niet-nul `failureCount` ziet, stop dan de migratie (herstel de services via `docker restart git-bridge sharelatex`) en neem contact op met 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":"klaar met het flushen van alle projecten","time":"...","v":0}
   Klaar met het flushen van alle projecten
   </code></pre>
6. Als u nooit 5.0.2 hebt uitgevoerd: zorg ervoor dat alle wijzigingen uit Redis zijn geflusht.

   Als u uitvoer krijgt van `redis-cli`, stop dan de migratie (herstel de services via `docker restart git-bridge sharelatex`) en neem contact op met support.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # geen uitvoer van redis-cli betekent succes, controleer daarna de exitcode van redis-cli; die moet nul zijn
   $ echo $?
   0
   </code></pre>
7. Probeer eventuele openstaande geschiedeniswijzigingen te flushen.

   Dit moet een flush-op-basis-van-beste-inspanning zijn, aangezien sommige projecten kapotte geschiedenissen hebben door de foutieve database-migratie. Eventuele mislukkingen worden aan het einde van het herstelproces opgelost met een her-synchronisatie van de geschiedenis.

   <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 %}

#### Maak een back-up

Overweeg om een [consistente back-up](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) van de instantie te maken.
{% endstep %}

{% step %}

#### Upgraden

Upgrade naar versie `5.0.3`.
{% endstep %}

{% step %}

#### Automatisch herstel

Het herstelproces wordt automatisch uitgevoerd bij het opstarten van de container.
{% endstep %}

{% step %}

#### Voortgang volgen

U kunt de voortgang van het script volgen door het logbestand te volgen `/var/lib/overleaf/data/history/doc-version-recovery.log`. Het zal aan het begin het totale aantal projecten afdrukken en na elke 1000 verwerkte projecten een samenvatting.

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### Wacht tot het herstelproces is voltooid

Wacht tot het herstelproces is voltooid door ofwel het bovenstaande logbestand te volgen totdat een `Klaar.` regel is afgedrukt of door te wachten tot `Herstel van doc-versies voltooid.` wordt afgedrukt naar de standaarduitvoer van de Server Pro-container.
{% endstep %}

{% step %}

#### Valideer het herstelproces

Valideer het herstelproces door het geschiedenisvenster te openen voor enkele van de projecten waarvan eerder de geschiedenis ontbrak.

1. Versnel de resynchronisatie voor de projecten die u wilt testen (ze worden uiteindelijk wel verwerkt, maar we willen niet wachten tot hun beurt komt.)

   <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>

   (Herhaal dit met elk van de project-id's die u wilt testen, vervang `000000000000000000000000` door telkens één project-id.)
2. Open de projecteditor voor de projecten `https://my-server-pro.example.com/project/000000000000000000000000`
3. Open het paneel "Geschiedenis" voor het project en bekijk de nieuwste inhoud.
4. Optioneel: sluit het paneel "Geschiedenis" opnieuw. Breng een codewijziging aan, zoals een opmerking toevoegen aan de koptekst.
5. Optioneel: voer een hercompilatie uit om een flush van de lokale wijziging te activeren. Open het paneel "Geschiedenis" opnieuw en bekijk de wijziging. Maak de wijziging daarna ongedaan.
   {% endstep %}

{% step %}

#### Voor horizontale schaalvergroting...

Start de andere workers opnieuw.
{% endstep %}

{% step %}

#### Laat de instantie draaien

Laat de instantie die het herstelproces heeft uitgevoerd draaien. Deze zal de geschiedenis van alle projecten op de achtergrond opnieuw synchroniseren met een gelijktijdigheid van 1. Dit resulteert in een iets hogere basisbelasting. (U kunt de instantie opnieuw opstarten, maar dan moet het opnieuw beginnen met de resynchronisaties.)
{% endstep %}

{% step %}

#### Laat het ons weten wanneer u klaar bent

Server Pro-klanten: laat het supportteam weten wanneer u het herstelproces hebt voltooid.
{% 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/nl/ondersteuning/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.