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

# (Migration v5.0.1) Récupération de la version du document

{% hint style="info" %}
Si vous n’avez jamais exécuté Server Pro version 5.0.1 ou Community Edition version 5.0.1, ou si vous avez démarré une toute nouvelle instance avec la version 5.0.1, vous n’avez pas besoin d’exécuter ce processus de récupération.
{% endhint %}

**Mises à jour de cette page :**

* (2024-04-22 13:40 BST) : Ajout de l’étape « Empêcher les nouvelles mises à jour d’entrer dans le système et vider toutes les modifications vers MongoDB ».
* (2024-04-23 11:45 BST) : Prise en compte des flushs défectueux dans la 5.0.1 et saut des flushs lorsque la 5.0.2 a été démarrée.

La durée de la récupération dépendra du nombre et de la taille des projets dans votre instance ainsi que du backend de stockage utilisé par le stockage d’historique pour les chunks (tel que défini dans `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Le processus de récupération retardera le démarrage de l’application dans le conteneur Server Pro. Le site apparaîtra hors ligne pendant ce temps. Nous ne prenons en charge l’exécution de la récupération qu’à partir d’une seule instance du conteneur Server Pro ; tous les autres workers de mise à l’échelle horizontale doivent être hors ligne.

Vous pouvez arrêter et reprendre le processus de récupération si nécessaire.

D’après nos tests de performance, le processus de récupération peut traiter environ 10 000 petits projets par minute sur du matériel moderne (vitesse d’horloge CPU de 3 GHz et stockage NVMe local). À titre d’exemple, pour une instance avec 100 000 projets, prévoyez une fenêtre de maintenance permettant au moins 10+2 min d’indisponibilité. Utilisez la requête suivante pour estimer le nombre de projets dans votre instance :

{% code overflow="wrap" %}

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

{% endcode %}

Veuillez lire entièrement les étapes de récupération suivantes avant de commencer. Les clients Server Pro sont bien entendu invités à contacter <support@overleaf.com> pour toute question.

### Processus de récupération

{% stepper %}
{% step %}

#### Récupérer les images de version

Récupérez les `5.0.3` images de version.
{% endstep %}

{% step %}

#### Identifier quelques projets

Identifiez quelques projets par identifiant dont l’historique est manquant ; idéalement, vous avez l’autorisation d’apporter une modification à l’un d’eux.
{% endstep %}

{% step %}

#### Planifier la maintenance

Planifiez une fenêtre de maintenance pour l’indisponibilité.
{% endstep %}

{% step %}

#### Arrêter tous les workers sauf un

Arrêtez tous les workers sauf un lors de l’utilisation d’une configuration à mise à l’échelle horizontale.
{% endstep %}

{% step %}

#### Arrêter les nouvelles mises à jour et vider toutes les modifications vers MongoDB

Empêchez les nouvelles mises à jour d’entrer dans le système et videz toutes les modifications vers MongoDB :

1. Fermez l’éditeur et déconnectez manuellement tous les utilisateurs via le panneau d’administration sur `https://my-server-pro.example.com/admin#open-close-editor` dans l’onglet « Ouvrir/Fermer l’éditeur ».
2. Arrêtez le service WebSocket/temps réel.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Attendez que le service temps réel s’arrête, comme indiqué par `down :`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # attendez encore un peu...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normalement up
   ```
4. Arrêtez le conteneur git-bridge s’il est activé.

   ```bash
   $ docker stop git-bridge
   ```
5. Si vous n’avez jamais exécuté la 5.0.2 : lancez un flush manuel pour les mises à jour de documents et attendez qu’il se termine avec succès.

   Vous pouvez répéter la commande en cas d’erreur. Si vous voyez un `failureCount` non nul lors d’exécutions successives, veuillez arrêter la migration (restaurez les services via `docker restart git-bridge sharelatex`) et contactez le 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":"finished flushing all projects","time":"...","v":0}
   Fin du flush de tous les projets
   </code></pre>
6. Si vous n’avez jamais exécuté la 5.0.2 : assurez-vous que toutes les modifications ont été vidées de Redis.

   Si vous obtenez une sortie de `redis-cli`, veuillez arrêter la migration (restaurez les services via `docker restart git-bridge sharelatex`) et contactez le support.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # aucune sortie de redis-cli indique un succès ; vérifiez ensuite le code de sortie de redis-cli, il doit être nul
   $ echo $?
   0
   </code></pre>
7. Essayez de vider toutes les modifications d’historique en attente.

   Cela devra être un flush au mieux, car certains projets ont des historiques cassés en raison de la mauvaise migration de base de données. Toute erreur sera traitée par une resynchronisation de l’historique à la fin du processus de récupération.

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

#### Prendre une sauvegarde

Envisagez de prendre une [sauvegarde cohérente](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) de l’instance.
{% endstep %}

{% step %}

#### Mettre à niveau

Mettez à niveau vers la version `5.0.3`.
{% endstep %}

{% step %}

#### Récupération automatique

Le processus de récupération s’exécute automatiquement au démarrage du conteneur.
{% endstep %}

{% step %}

#### Suivre la progression

Vous pouvez suivre la progression du script en surveillant le fichier journal `/var/lib/overleaf/data/history/doc-version-recovery.log`. Il affichera le nombre total de projets au début, puis un résumé après chaque tranche de 1000 projets traités.

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### Attendre la fin du processus de récupération

Attendez la fin du processus de récupération soit en suivant le fichier journal ci-dessus jusqu’à ce qu’une `Terminé.` ligne ait été affichée, soit en attendant que `Récupération des versions de documents terminée.` soit affiché sur la sortie standard du conteneur Server Pro.
{% endstep %}

{% step %}

#### Valider le processus de récupération

Validez le processus de récupération en ouvrant le panneau d’historique pour quelques projets dont l’historique était auparavant manquant.

1. Accélérez la resynchronisation pour les projets à tester (ils seront traités tôt ou tard, mais nous ne voulons pas attendre leur tour.)

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

   (Répétez avec chacun des identifiants de projet à tester, remplacez `000000000000000000000000` par un identifiant de projet à la fois.)
2. Ouvrez l’éditeur de projet pour les projets `https://my-server-pro.example.com/project/000000000000000000000000`
3. Ouvrez le panneau « Historique » du projet et voyez le contenu le plus récent.
4. Facultatif : fermez à nouveau le panneau « Historique ». Apportez une modification au code, comme l’ajout d’un commentaire à l’en-tête.
5. Facultatif : lancez une recompilation pour déclencher un flush de la modification locale. Ouvrez à nouveau le panneau « Historique » et voyez la modification. Une fois terminé, annulez la modification.
   {% endstep %}

{% step %}

#### Pour la mise à l’échelle horizontale...

Redémarrez les autres workers.
{% endstep %}

{% step %}

#### Laisser l’instance en marche

Veuillez laisser en marche l’instance qui a exécuté le processus de récupération. Elle resynchronisera l’historique de tous les projets en arrière-plan avec une concurrence de 1. Cela entraînera une charge de base légèrement plus élevée. (Vous pouvez redémarrer l’instance, mais elle devra recommencer la resynchronisation depuis le début.)
{% endstep %}

{% step %}

#### Tenez-nous au courant lorsque vous avez terminé

Clients Server Pro : veuillez informer l’équipe support lorsque vous avez terminé le processus de récupération.
{% 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/fr/assistance/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.