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

# (Migração v5.0.1) Recuperação da versão do documento

{% hint style="info" %}
Se nunca executou a versão 5.0.1 do Server Pro ou a versão 5.0.1 da Community Edition, ou se iniciou uma instância totalmente nova com a 5.0.1, não precisa de executar este processo de recuperação.
{% endhint %}

**Atualizações desta página:**

* (2024-04-22 13:40 BST): Adicionado o passo "Impeça que novas atualizações entrem no sistema e grave todas as alterações no MongoDB".
* (2024-04-23 11:45 BST): Considere os flushes com falha na 5.0.1 e ignore os flushes quando a 5.0.2 foi iniciada.

A duração da recuperação dependerá do número e do tamanho dos projetos na sua instância e do backend de armazenamento utilizado pelo history store para os chunks (tal como definido em `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

O processo de recuperação atrasará o início da aplicação dentro do contentor Server Pro. O site aparecerá offline durante esse período. Só suportamos a execução da recuperação a partir de uma única instância do contentor Server Pro; todos os outros workers de escalamento horizontal precisam de estar offline.

Se necessário, pode interromper e retomar o processo de recuperação.

Com base nos nossos testes de desempenho, o processo de recuperação pode processar aproximadamente 10 mil projetos pequenos por minuto em hardware moderno (clock de CPU de 3 GHz e armazenamento NVMe local). Como exemplo, para uma instância com 100 mil projetos, agende uma janela de manutenção que permita pelo menos 10+2 min de indisponibilidade. Use a seguinte consulta para estimar o número de projetos na sua instância:

{% code overflow="wrap" %}

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

{% endcode %}

Leia integralmente os seguintes passos de recuperação antes de começar. Os clientes do Server Pro são mais do que bem-vindos a contactar <support@overleaf.com> com quaisquer dúvidas.

### Processo de recuperação

{% stepper %}
{% step %}

#### Obtenha as imagens da release

Obtenha as `5.0.3` imagens da release.
{% endstep %}

{% step %}

#### Identificar alguns projetos

Identifique alguns projetos por id que estejam sem histórico; idealmente, tem permissão para fazer uma alteração num deles.
{% endstep %}

{% step %}

#### Agendar manutenção

Agende uma janela de manutenção para a indisponibilidade.
{% endstep %}

{% step %}

#### Pare todos os workers, exceto um

Pare todos os workers, exceto um, ao usar uma configuração de escalamento horizontal.
{% endstep %}

{% step %}

#### Impeça novas atualizações e grave todas as alterações no MongoDB

Impeça que novas atualizações entrem no sistema e grave todas as alterações no MongoDB:

1. Feche o editor e desconecte manualmente todos os utilizadores através do painel de administração em `https://my-server-pro.example.com/admin#open-close-editor` no separador "Open/Close Editor".
2. Pare o serviço Websocket/em tempo real.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Aguarde que o serviço de tempo real termine, conforme indicado por `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # espere um pouco mais...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normalmente ativo
   ```
4. Pare o contentor git-bridge, se estiver ativado.

   ```bash
   $ docker stop git-bridge
   ```
5. Se nunca executou a 5.0.2: execute um flush manual para as atualizações de documentos e aguarde que termine com sucesso.

   Pode repetir o comando em caso de erro. Caso veja um `failureCount` diferente de zero em execuções sucessivas, pare a migração (restaure os serviços através de `docker restart git-bridge sharelatex`) e contacte o suporte.

   <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}
   Concluída a gravação de todos os projetos
   </code></pre>
6. Se nunca executou a 5.0.2: certifique-se de que todas as alterações foram descarregadas do redis.

   Se obtiver qualquer saída de `redis-cli`, pare a migração (restaure os serviços através de `docker restart git-bridge sharelatex`) e contacte o suporte.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # a ausência de saída do redis-cli indica sucesso; verifique a seguir o código de saída do redis-cli, que deve ser zero
   $ echo $?
   0
   </code></pre>
7. Tente gravar quaisquer alterações pendentes no histórico.

   Isto terá de ser um flush de melhor esforço, uma vez que alguns projetos têm históricos danificados devido à má migração da base de dados. Quaisquer falhas serão tratadas com uma ressинcronização do histórico no final do processo de recuperação.

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

#### Faça uma cópia de segurança

Considere fazer uma [cópia de segurança consistente](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) da instância.
{% endstep %}

{% step %}

#### Atualização

Atualize para a versão `5.0.3`.
{% endstep %}

{% step %}

#### Recuperação automática

O processo de recuperação é executado automaticamente ao iniciar o contentor.
{% endstep %}

{% step %}

#### Acompanhar o progresso

Pode acompanhar o progresso do script seguindo o ficheiro de registo `/var/lib/overleaf/data/history/doc-version-recovery.log`. Irá apresentar o número total de projetos no início e um resumo após cada 1000 projetos processados.

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### Aguarde que o processo de recuperação termine

Aguarde que o processo de recuperação termine, seja seguindo o ficheiro de registo acima até que uma `Concluído.` linha tenha sido apresentada ou aguardando por `Recuperação das versões dos documentos concluída.` ser impresso na saída padrão do contentor Server Pro.
{% endstep %}

{% step %}

#### Validar o processo de recuperação

Valide o processo de recuperação abrindo o painel de histórico de alguns dos projetos que anteriormente estavam sem histórico.

1. Acelere a ressincronização dos projetos a testar (eles serão processados eventualmente, mas não queremos esperar pela vez deles.)

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

   (Repita com cada um dos ids de projeto a testar, substitua `000000000000000000000000` por um id de projeto de cada vez.)
2. Abra o editor do projeto para os projetos `https://my-server-pro.example.com/project/000000000000000000000000`
3. Abra o painel "Histórico" do projeto e veja o conteúdo mais recente.
4. Opcional: feche novamente o painel "Histórico". Faça uma alteração no código, como adicionar um comentário ao cabeçalho.
5. Opcional: execute uma recompilação para acionar um flush da alteração local. Abra novamente o painel "Histórico" e veja a alteração. Quando terminar, desfaça a alteração.
   {% endstep %}

{% step %}

#### Para escalamento horizontal...

Inicie novamente os outros workers.
{% endstep %}

{% step %}

#### Mantenha a instância em execução

Por favor, mantenha a instância que executou o processo de recuperação em execução. Ela voltará a sincronizar o histórico de todos os projetos em segundo plano com uma concorrência de 1. Isto resultará numa carga base ligeiramente superior. (Pode reiniciar a instância, mas ela terá de recomeçar do zero com as ressincronizações.)
{% endstep %}

{% step %}

#### Avise-nos quando terminar

Clientes do Server Pro: informe a equipa de suporte quando tiver concluído o processo de recuperação.
{% 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/pt/suporte/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.