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

# (Migratie v5.0.1) Herstel van documentversie

{% 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 volledig nieuwe instantie met 5.0.1 bent gestart, hoeft u dit herstelproces niet uit te voeren.
{% endhint %}

**Updates voor deze pagina:**

* (2024-04-22 13:40 BST): Toegevoegd: stap "Voorkom dat nieuwe updates in het systeem komen en flush alle wijzigingen naar MongoDB".
* (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 hangt af van het aantal en de grootte van de projecten in uw instantie en van de opslagbackend die door de history store voor chunks wordt gebruikt (zoals gedefinieerd in `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Het herstelproces zal het opstarten van de applicatie binnen de Server Pro-container vertragen. De site zal in die tijd offline lijken. 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 10.000 kleine projecten per minuut verwerken. Als voorbeeld: voor een instantie met 100.000 projecten plant u een onderhoudsvenster dat minstens 10+2 min uitvaltijd 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 eventuele 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 basis van id waarvan de geschiedenis ontbreekt; idealiter hebt u toestemming om in een daarvan 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 komen 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-/realtime-service.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Wacht tot de realtime-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...

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

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

   U kunt het commando herhalen bij een fout. Als u een niet-nul `failureCount` in opeenvolgende uitvoeringen 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":"het flushen van alle projecten is voltooid","time":"...","v":0}
   Het flushen van alle projecten is voltooid
   </code></pre>
6. Als u 5.0.2 nooit 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 hierna de exitcode van redis-cli; die moet nul zijn
   $ echo $?
   0
   </code></pre>
7. Probeer eventuele wachtende geschiedeniswijzigingen te flushen.

   Dit moet een flush op basis van beste inspanning zijn, aangezien sommige projecten kapotte geschiedenissen hebben vanwege de foutieve database-migratie. Eventuele fouten worden aan het einde van het herstelproces verholpen met een resync 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 het nemen van een [consistente back-up](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) van de instantie.
{% endstep %}

{% step %}

#### Upgraden

Upgraden 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 te wachten op `Herstel van doc-versies voltooid.` te worden afgedrukt naar de standaarduitvoer van de Server Pro-container.
{% endstep %}

{% step %}

#### Valideer het herstelproces

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

1. Versnel de resync voor de te testen projecten (ze worden uiteindelijk 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 voor elk van de project-id's om te 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 het toevoegen van een opmerking aan de koptekst.
5. Optioneel: voer een hercompilatie uit om een flush van de lokale wijziging af te dwingen. Open het paneel "Geschiedenis" opnieuw en bekijk de wijziging. Draai de wijziging daarna terug.
   {% 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. De geschiedenis van alle projecten wordt op de achtergrond opnieuw gesynchroniseerd met een gelijktijdigheid van 1. Dit resulteert in een iets hogere basisbelasting. (U kunt de instantie herstarten, maar dan moet u de resync opnieuw vanaf het begin uitvoeren.)
{% endstep %}

{% step %}

#### Laat 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://ayakaleaf-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.