> 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/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 começou uma nova instância com a 5.0.1, não precisa de executar este processo de recuperação.
{% endhint %}

**Atualizações a esta página:**

* (2024-04-22 13:40 BST): Adicionado o passo "Impedir que novas atualizações entrem no sistema e esvaziar todas as alterações para o MongoDB".
* (2024-04-23 11:45 BST): Contabilizar esvaziamentos com falha na 5.0.1 e ignorar esvaziamentos 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 usado pela history store para os chunks (conforme definido em `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

O processo de recuperação atrasará o arranque da aplicação dentro do contentor Server Pro. O site parecerá 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 escalabilidade horizontal precisam de estar offline.

Pode parar e retomar o processo de recuperação, se necessário.

Com base nos nossos testes de desempenho, o processo de recuperação pode processar aproximadamente 10 mil pequenos projetos por minuto em hardware moderno (clock da CPU de 3 GHz e armazenamento NVMe local). Por 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 %}

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

### Processo de recuperação

{% stepper %}
{% step %}

#### Fazer pull das imagens da release

Faça pull das `5.0.3` imagens da release.
{% endstep %}

{% step %}

#### Identificar alguns projetos

Identifique alguns projetos pelo 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 %}

#### Parar todos, exceto um worker

Pare todos, exceto um worker, ao usar uma configuração de escalabilidade horizontal.
{% endstep %}

{% step %}

#### Parar novas atualizações e esvaziar todas as alterações para o MongoDB

Impeça que novas atualizações entrem no sistema e esvazie todas as alterações para o 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/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 mais um pouco...

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

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

   Pode repetir o comando em caso de erro. Se vir um `failureCount` diferente de zero em execuções sucessivas, pare a migração (restaure os serviços via `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 limpeza de todos os projetos
   </code></pre>
6. Se nunca executou a 5.0.2: garanta que todas as alterações foram esvaziadas do redis.

   Se obtiver qualquer saída de `redis-cli`, pare a migração (restaure os serviços via `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:*'
   # nenhuma saída do redis-cli indica sucesso; verifique de seguida o código de saída do redis-cli, deve ser zero
   $ echo $?
   0
   </code></pre>
7. Tente esvaziar quaisquer alterações pendentes do histórico.

   Isto terá de ser um esvaziamento de melhor esforço, uma vez que alguns projetos têm históricos corrompidos devido à má migração da base de dados. Quaisquer falhas serão resolvidas com uma nova sincronização do histórico no fim 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 [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 %}

#### Atualizar

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

{% step %}

#### Recuperação automática

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

{% step %}

#### Acompanhar o progresso

Pode acompanhar o progresso do script consultando o ficheiro de registo `/var/lib/overleaf/data/history/doc-version-recovery.log`. Irá imprimir 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 consultando o ficheiro de registo acima até ser `Concluído.` impressa uma linha ou aguardando que `Recuperação das versões dos documentos concluída.` seja 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 para alguns dos projetos que anteriormente não tinham 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, substituindo `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 "History" do projeto e veja o conteúdo mais recente.
4. Opcional: feche novamente o painel "History". Faça uma alteração de código, como adicionar um comentário ao cabeçalho.
5. Opcional: execute uma nova compilação para desencadear um esvaziamento da alteração local. Abra novamente o painel "History" e veja a alteração. Quando terminar, reverta a alteração.
   {% endstep %}

{% step %}

#### Para escalabilidade horizontal...

Volte a iniciar os outros workers.
{% endstep %}

{% step %}

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

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

{% step %}

#### Avise-nos quando terminar

Clientes do Server Pro: por favor, 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://ayakaleaf-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.