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

# (Migration v5.0.1) Restauration 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) : Prendre en compte les vidages défectueux dans la version 5.0.1 et ignorer les vidages lorsque la version 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 dépôt d'historique pour les chunks (comme défini dans `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Le processus de récupération retardera le démarrage de l'application à l'intérieur du 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 travailleurs 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). Par 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 l'intégralité des étapes de récupération suivantes avant de commencer. Les clients Server Pro sont plus que bienvenus pour 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 ID 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'interruption.
{% endstep %}

{% step %}

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

Arrêtez tous les travailleurs sauf un lorsque vous utilisez une configuration de mise à l'échelle horizontale.
{% endstep %}

{% step %}

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

Arrêtez 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 se termine, 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 un peu plus longtemps...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normalement en cours d'exécution
   ```
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 version 5.0.2 : lancez un vidage manuel pour les mises à jour de documents et attendez qu'il se termine avec succès.

   Vous pouvez relancer la commande en cas d'erreur. Si vous observez une `failureCount` non nulle 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":"vidage de tous les projets terminé","time":"...","v":0}
   Vidage de tous les projets terminé
   </code></pre>
6. Si vous n'avez jamais exécuté la version 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:*'
   # l'absence de sortie de redis-cli indique le succès ; vérifiez ensuite le code de retour de redis-cli, il devrait être nul
   $ echo $?
   0
   </code></pre>
7. Essayez de vider toutes les modifications d'historique en attente.

   Cela devra être un vidage au mieux, car certains projets ont des historiques corrompus en raison de la mauvaise migration de base de données. Tout échec sera traité 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 %}

#### Sauvegarder

Envisagez d'effectuer 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

Mettre à 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 et un résumé après chaque 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 que le processus de récupération se termine

Attendez que le processus de récupération se termine, soit en surveillant 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 volet d'historique pour quelques-uns des projets dont l'historique était auparavant manquant.

1. Accélérez la resynchronisation pour les projets à tester (ils seront traités à terme, 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 IDs de projet à tester, remplacez `000000000000000000000000` par un seul ID de projet à la fois.)
2. Ouvrez l'éditeur de projet pour les projets `https://my-server-pro.example.com/project/000000000000000000000000`
3. Ouvrez le volet « Historique » du projet et affichez le contenu le plus récent.
4. Facultatif : refermez le volet « Historique ». Apportez une modification au code, par exemple en ajoutant un commentaire à l'en-tête.
5. Facultatif : lancez une recompilation pour déclencher un vidage de la modification locale. Ouvrez à nouveau le volet « Historique » et voyez la modification. Une fois terminé, annulez la modification.
   {% endstep %}

{% step %}

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

Relancez les autres travailleurs.
{% endstep %}

{% step %}

#### Gardez l'instance en cours d'exécution

Veuillez laisser en cours d'exécution 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 les resynchronisations depuis le début.)
{% endstep %}

{% step %}

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

Clients Server Pro : veuillez informer l'équipe d'assistance lorsque vous aurez 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://overleaf-pro.ayaka.space/on-premises/fr/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.