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

# (Migrering v5.0.1) Återställning av dokumentversion

{% hint style="info" %}
Om du aldrig körde Server Pro version 5.0.1 eller Community Edition version 5.0.1, eller om du startade en helt ny instans med 5.0.1, behöver du inte köra den här återställningsprocessen.
{% endhint %}

**Uppdateringar på den här sidan:**

* (2024-04-22 13:40 BST): Lade till steget "Stoppa nya uppdateringar från att komma in i systemet och flusha alla ändringar till MongoDB".
* (2024-04-23 11:45 BST): Ta hänsyn till trasiga flushningar i 5.0.1 och hoppa över flushningar när 5.0.2 hade startats.

Återställningens varaktighet beror på antalet och storleken på projekten i din instans och lagringsbackend som används av historiklagringen för chunks (enligt definitionen i `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Återställningsprocessen kommer att fördröja att applikationen startar inne i Server Pro-containern. Webbplatsen kommer att verka offline under den tiden. Vi stöder endast att återställningen körs från en enda instans av Server Pro-containern; alla andra workers för horisontell skalning måste vara offline.

Du kan stoppa och återuppta återställningsprocessen vid behov.

Baserat på våra prestandatester kan återställningsprocessen bearbeta cirka 10 000 små projekt per minut på modern hårdvara (3 GHz CPU-klockfrekvens och lokal NVMe-lagring). Som exempel, för en instans med 100 000 projekt, schemalägg ett underhållsfönster som medger minst 10+2 minuters driftstopp. Använd följande fråga för att uppskatta antalet projekt i din instans:

{% code overflow="wrap" %}

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

{% endcode %}

Läs igenom följande återställningssteg i sin helhet innan du börjar. Kunder med Server Pro är mer än välkomna att kontakta <support@overleaf.com> vid eventuella frågor.

### Återställningsprocess

{% stepper %}
{% step %}

#### Hämta releasebilderna

Hämta `5.0.3` releasebilderna.
{% endstep %}

{% step %}

#### Identifiera några projekt

Identifiera några projekt med id som saknar historik; helst har du behörighet att göra en ändring i ett av dem.
{% endstep %}

{% step %}

#### Schemalägg underhåll

Schemalägg ett underhållsfönster för driftstoppet.
{% endstep %}

{% step %}

#### Stoppa alla utom en worker

Stoppa alla utom en worker när du använder en horisontell skalningskonfiguration.
{% endstep %}

{% step %}

#### Stoppa nya uppdateringar och flusha alla ändringar till MongoDB

Stoppa nya uppdateringar från att komma in i systemet och flusha alla ändringar till MongoDB:

1. Stäng editorn och koppla manuellt bort alla användare via adminpanelen på `https://my-server-pro.example.com/admin#open-close-editor` på fliken "Öppna/Stäng editor".
2. Stoppa Websocket-/realtidstjänsten.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Vänta på att realtidstjänsten avslutas, vilket indikeras av `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # vänta lite längre...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normally up
   ```
4. Stoppa git-bridge-containern om den är aktiverad.

   ```bash
   $ docker stop git-bridge
   ```
5. Om du aldrig körde 5.0.2: Utför en manuell flush för dokumentuppdateringar och vänta tills den slutförs med framgång.

   Du kan upprepa kommandot vid fel. Om du ser ett icke-noll `failureCount` i på varandra följande körningar, stoppa migreringen (återställ tjänsterna via `docker restart git-bridge sharelatex`) och kontakta supporten.

   <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}
   Klart med flushningen av alla projekt
   </code></pre>
6. Om du aldrig körde 5.0.2: Se till att alla ändringar har flushats ut ur redis.

   Om du får någon utdata från `redis-cli`, stoppa migreringen (återställ tjänsterna via `docker restart git-bridge sharelatex`) och kontakta supporten.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # ingen utdata från redis-cli indikerar framgång; kontrollera sedan returvärdet från redis-cli, det ska vara noll
   $ echo $?
   0
   </code></pre>
7. Försök att flusha alla väntande historikändringar.

   Detta måste göras så gott det går, eftersom vissa projekt har trasiga historiker på grund av den felaktiga databasmigrationen. Alla fel kommer att åtgärdas med en omsynkronisering av historiken i slutet av återställningsprocessen.

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

#### Ta en säkerhetskopia

Överväg att ta en [konsistent säkerhetskopia](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) av instansen.
{% endstep %}

{% step %}

#### Uppgradera

Uppgradera till version `5.0.3`.
{% endstep %}

{% step %}

#### Automatisk återställning

Återställningsprocessen körs automatiskt när containern startar.
{% endstep %}

{% step %}

#### Följ förloppet

Du kan följa skriptets förlopp genom att följa loggfilen `/var/lib/overleaf/data/history/doc-version-recovery.log`. Den skriver ut det totala antalet projekt i början och en sammanfattning efter varje 1000 bearbetade projekt.

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### Vänta tills återställningsprocessen är klar

Vänta tills återställningsprocessen är klar genom att antingen följa loggfilen ovan tills en `Klart.` rad har skrivits ut eller genom att vänta på `Återställningen av dokumentversioner slutförd.` att skrivas ut till standardutmatningen i Server Pro-containern.
{% endstep %}

{% step %}

#### Validera återställningsprocessen

Validera återställningsprocessen genom att öppna historikpanelen för några av projekten som tidigare saknade historik.

1. Påskynda omsynkroniseringen för projekten som ska testas (De kommer så småningom att bearbetas, men vi vill inte vänta på att de ska få sin tur.)

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

   (Upprepa med varje projekt-id som ska testas, ersätt `000000000000000000000000` med ett projekt-id åt gången.)
2. Öppna projektredigeraren för projekten `https://my-server-pro.example.com/project/000000000000000000000000`
3. Öppna panelen "Historik" för projektet och se det senaste innehållet.
4. Valfritt: Stäng panelen "Historik" igen. Gör en kodändring, till exempel genom att lägga till en kommentar i rubriken.
5. Valfritt: Kör en omkompilering för att trigga en flush av den lokala ändringen. Öppna panelen "Historik" igen och se ändringen. När du är klar, ångra ändringen.
   {% endstep %}

{% step %}

#### För horisontell skalning...

Starta de andra worker-processerna igen.
{% endstep %}

{% step %}

#### Låt instansen fortsätta köra

Behåll instansen som körde återställningsprocessen igång. Den kommer att omsynkronisera historiken för alla projekt i bakgrunden med en samtidighet på 1. Detta kommer att resultera i något högre basbelastning. (Du kan starta om instansen, men då måste den börja om med omsynkroniseringarna.)
{% endstep %}

{% step %}

#### Meddela oss när du är klar

Kunder med Server Pro: Vänligen låt supportteamet veta när du har slutfört återställningsprocessen.
{% 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/sv/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.