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

# (Migracja v5.0.1) Przywracanie wersji dokumentu

{% hint style="info" %}
Jeśli nigdy nie uruchamiałeś wersji Server Pro 5.0.1 ani wersji Community Edition 5.0.1, albo uruchomiłeś zupełnie nową instancję z 5.0.1, nie musisz uruchamiać tego procesu odzyskiwania.
{% endhint %}

**Aktualizacje tej strony:**

* (2024-04-22 13:40 BST): Dodano krok „Zatrzymaj napływ nowych aktualizacji do systemu i opróżnij wszystkie zmiany do MongoDB”.
* (2024-04-23 11:45 BST): Uwzględniono uszkodzone opróżnienia w 5.0.1 i pomijano opróżnienia, gdy uruchomiono 5.0.2.

Czas trwania odzyskiwania będzie zależał od liczby i rozmiaru projektów w Twojej instancji oraz od backendu pamięci masowej używanego przez magazyn historii dla chunków (zgodnie z `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

Proces odzyskiwania opóźni uruchomienie aplikacji wewnątrz kontenera Server Pro. W tym czasie witryna będzie wyglądać na niedostępną. Obsługujemy uruchamianie odzyskiwania tylko z jednej instancji kontenera Server Pro; wszystkie pozostałe procesy poziomego skalowania muszą być wyłączone.

W razie potrzeby możesz zatrzymać i wznowić proces odzyskiwania.

Na podstawie naszych testów wydajności proces odzyskiwania może przetwarzać około 10 tys. małych projektów na minutę na nowoczesnym sprzęcie (zegar CPU 3 GHz i lokalna pamięć NVMe). Na przykład dla instancji z 100 tys. projektów zaplanuj okno serwisowe, które pozwoli na co najmniej 10+2 min przestoju. Użyj następującego zapytania, aby oszacować liczbę projektów w swojej instancji:

{% code overflow="wrap" %}

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

{% endcode %}

Proszę dokładnie przeczytać poniższe kroki odzyskiwania przed rozpoczęciem. Klienci Server Pro mogą śmiało skontaktować się z <support@overleaf.com> w razie jakichkolwiek pytań.

### Proces odzyskiwania

{% stepper %}
{% step %}

#### Pobierz obrazy wydania

Pobierz `5.0.3` obrazy wydania.
{% endstep %}

{% step %}

#### Zidentyfikuj kilka projektów

Zidentyfikuj kilka projektów po identyfikatorze, którym brakuje historii; najlepiej, jeśli masz uprawnienia do wprowadzenia w jednym z nich zmiany.
{% endstep %}

{% step %}

#### Zaplanuj konserwację

Zaplanuj okno serwisowe na czas przestoju.
{% endstep %}

{% step %}

#### Zatrzymaj wszystkich oprócz jednego pracownika

Zatrzymaj wszystkich oprócz jednego pracownika przy użyciu konfiguracji poziomego skalowania.
{% endstep %}

{% step %}

#### Zatrzymaj napływ nowych aktualizacji i opróżnij wszystkie zmiany do MongoDB

Zatrzymaj napływ nowych aktualizacji do systemu i opróżnij wszystkie zmiany do MongoDB:

1. Zamknij edytor i ręcznie rozłącz wszystkich użytkowników za pośrednictwem panelu administracyjnego pod adresem `https://my-server-pro.example.com/admin#open-close-editor` na karcie „Otwórz/Zamknij edytor”.
2. Zatrzymaj usługę Websocket/czasu rzeczywistego.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. Poczekaj, aż usługa czasu rzeczywistego zakończy działanie, co jest wskazywane przez `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   uruchomiono: real-time-sharelatex: (pid 394) 50 s, oczekiwano down, otrzymano TERM
   # poczekaj trochę dłużej...

   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normalnie działa
   ```
4. Zatrzymaj kontener git-bridge, jeśli jest włączony.

   ```bash
   $ docker stop git-bridge
   ```
5. Jeśli nigdy nie uruchomiłeś 5.0.2: wykonaj ręczne opróżnienie dla aktualizacji dokumentów i poczekaj, aż zakończy się powodzeniem.

   Możesz powtórzyć polecenie w razie błędu. Jeśli w kolejnych uruchomieniach zobaczysz niezerową wartość `failureCount` , zatrzymaj migrację (przywróć usługi za pomocą `docker restart git-bridge sharelatex`) i skontaktuj się z pomocą techniczną.

   <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":"zakończono opróżnianie wszystkich projektów","time":"...","v":0}
   Opróżnianie wszystkich projektów zakończone
   </code></pre>
6. Jeśli nigdy nie uruchomiłeś 5.0.2: upewnij się, że wszystkie zmiany zostały opróżnione z redis.

   Jeśli otrzymasz jakikolwiek output z `redis-cli`, zatrzymaj migrację (przywróć usługi za pomocą `docker restart git-bridge sharelatex`) i skontaktuj się z pomocą techniczną.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # brak outputu z redis-cli oznacza sukces, następnie sprawdź kod zakończenia redis-cli, powinien wynosić zero
   $ echo $?
   0
   </code></pre>
7. Spróbuj opróżnić wszelkie oczekujące zmiany historii.

   Będzie to musiało być opróżnienie w trybie best effort, ponieważ niektóre projekty mają uszkodzoną historię z powodu złej migracji bazy danych. Wszelkie niepowodzenia zostaną rozwiązane przez ponowną synchronizację historii na końcu procesu odzyskiwania.

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

#### Wykonaj kopię zapasową

Rozważ wykonanie [spójnej kopii zapasowej](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) instancji.
{% endstep %}

{% step %}

#### Aktualizacja

Zaktualizuj do wersji `5.0.3`.
{% endstep %}

{% step %}

#### Automatyczne odzyskiwanie

Proces odzyskiwania uruchamia się automatycznie przy starcie kontenera.
{% endstep %}

{% step %}

#### Śledzenie postępu

Możesz śledzić postęp skryptu, obserwując plik dziennika `/var/lib/overleaf/data/history/doc-version-recovery.log`. Wyświetli łączną liczbę projektów na początku oraz podsumowanie po każdych 1000 przetworzonych projektach.

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### Poczekaj, aż proces odzyskiwania się zakończy

Poczekaj, aż proces odzyskiwania się zakończy, albo obserwując powyższy plik dziennika, aż zostanie `Gotowe.` wydrukowana linia albo czekając na `Zakończono odzyskiwanie wersji dokumentów.` zostanie wydrukowane na standardowe wyjście kontenera Server Pro.
{% endstep %}

{% step %}

#### Zweryfikuj proces odzyskiwania

Zweryfikuj proces odzyskiwania, otwierając panel historii dla kilku projektów, którym wcześniej brakowało historii.

1. Przyspiesz ponowną synchronizację dla testowanych projektów (zostaną one przetworzone w końcu, ale nie chcemy czekać, aż nadejdzie ich kolej.)

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

   (Powtórz dla każdego identyfikatora projektu do przetestowania, zastępując `000000000000000000000000` jednym identyfikatorem projektu naraz.)
2. Otwórz edytor projektu dla projektów `https://my-server-pro.example.com/project/000000000000000000000000`
3. Otwórz panel „Historia” dla projektu i zobacz najnowszą treść.
4. Opcjonalnie: zamknij ponownie panel „Historia”. Wprowadź zmianę w kodzie, na przykład dodając komentarz do nagłówka.
5. Opcjonalnie: wykonaj ponowne kompilowanie, aby wywołać opróżnienie lokalnej zmiany. Otwórz ponownie panel „Historia” i zobacz zmianę. Po zakończeniu cofnij zmianę.
   {% endstep %}

{% step %}

#### W przypadku poziomego skalowania...

Uruchom ponownie pozostałych pracowników.
{% endstep %}

{% step %}

#### Pozostaw instancję uruchomioną

Proszę pozostawić uruchomioną instancję, która wykonała proces odzyskiwania. Będzie ona ponownie synchronizować historię wszystkich projektów w tle z współbieżnością 1. Spowoduje to nieznacznie zwiększone podstawowe obciążenie. (Możesz zrestartować instancję, ale wtedy będzie musiała zacząć ponowną synchronizację od początku.)
{% endstep %}

{% step %}

#### Daj nam znać, gdy skończysz

Klienci Server Pro: proszę poinformuj zespół wsparcia, gdy zakończysz proces odzyskiwania.
{% 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/pl/wsparcie/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.