> 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/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 Community Edition 5.0.1 albo uruchomiłeś zupełnie nową instancję z 5.0.1, nie musisz przeprowadzać tego procesu odzyskiwania.
{% endhint %}

**Aktualizacje tej strony:**

* (2024-04-22 13:40 BST): Dodano krok „Zatrzymaj nowe aktualizacje, zanim trafią do systemu, i zapisz 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 procesu odzyskiwania będzie zależał od liczby i rozmiaru projektów w Twojej instancji oraz od zaplecza pamięci masowej używanego przez magazyn historii dla fragmentów (jak zdefiniowano w `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

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

Możesz w razie potrzeby 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 (taktowanie 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 %}

Prosimy o dokładne przeczytanie poniższych kroków odzyskiwania przed rozpoczęciem. Klienci Server Pro są jak najbardziej zachęcani do kontaktu z <support@overleaf.com> w razie jakichkolwiek pytań.

### Proces odzyskiwania

{% stepper %}
{% step %}

#### Pobierz obrazy wydań

Pobierz `5.0.3` obrazy wydań.
{% endstep %}

{% step %}

#### Zidentyfikuj kilka projektów

Zidentyfikuj kilka projektów po identyfikatorze, którym brakuje historii; najlepiej jeśli masz uprawnienia, aby wprowadzić zmianę w jednym z nich.
{% endstep %}

{% step %}

#### Zaplanuj prace serwisowe

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

{% step %}

#### Zatrzymaj wszystkie procesy robocze oprócz jednego

Zatrzymaj wszystkie procesy robocze oprócz jednego podczas korzystania z konfiguracji skalowania poziomego.
{% endstep %}

{% step %}

#### Zatrzymaj nowe aktualizacje i zapisz wszystkie zmiany do MongoDB

Zatrzymaj nowe aktualizacje, zanim trafią do systemu, i zapisz wszystkie zmiany do MongoDB:

1. Zamknij edytor i ręcznie rozłącz wszystkich użytkowników za pomocą panelu administracyjnego pod adresem `https://my-server-pro.example.com/admin#open-close-editor` w zakładce „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 zostanie oznaczone przez `down:`.

   ```bash
   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got 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 uruchamiałeś 5.0.2: wykonaj ręczne opróżnienie aktualizacji dokumentów i poczekaj, aż zakończy się powodzeniem.

   Możesz powtórzyć polecenie w przypadku błędu. Jeśli zobaczysz niezerowy `failureCount` w kolejnych uruchomieniach, prosimy zatrzymać 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":"finished flushing all projects","time":"...","v":0}
   Zakończono opróżnianie wszystkich projektów
   </code></pre>
6. Jeśli nigdy nie uruchamiałeś 5.0.2: upewnij się, że wszystkie zmiany zostały opróżnione z Redis.

   Jeśli otrzymasz jakiekolwiek dane wyjściowe z `redis-cli`, prosimy zatrzymać 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 danych wyjściowych z redis-cli oznacza powodzenie; sprawdź następnie kod wyjścia 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 typu best effort, ponieważ niektóre projekty mają uszkodzoną historię z powodu błędnej migracji bazy danych. Wszelkie niepowodzenia zostaną obsłużone 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ójną kopię zapasową](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) kopii zapasowej instancji.
{% endstep %}

{% step %}

#### Aktualizacja

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

{% step %}

#### Automatyczne odzyskiwanie

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

{% step %}

#### Śledź postęp

Możesz śledzić postęp skryptu, obserwując końcówkę pliku logów `/var/lib/overleaf/data/history/doc-version-recovery.log`. Na początku wyświetli łączną liczbę projektów, a po każdych 1000 przetworzonych projektach wyświetli podsumowanie.

{% 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 na zakończenie procesu odzyskiwania, albo śledząc powyższy plik logów, aż do momentu, gdy `Gotowe.` zostanie wypisana linia lub czekając na `Zakończono odzyskiwanie wersji dokumentów.` zostanie wypisane do standardowego wyjścia 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ę projektów do testu (i tak zostaną przetworzone, 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 testu, zamień `000000000000000000000000` na jeden identyfikator 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ą zawartość.
4. Opcjonalnie: ponownie zamknij panel „Historia”. Wprowadź zmianę w kodzie, np. dodaj komentarz do nagłówka.
5. Opcjonalnie: wykonaj ponowną kompilację, aby wywołać opróżnienie lokalnej zmiany. Ponownie otwórz panel „Historia” i zobacz zmianę. Po zakończeniu cofnij zmianę.
   {% endstep %}

{% step %}

#### W przypadku skalowania poziomego...

Uruchom ponownie pozostałe procesy robocze.
{% endstep %}

{% step %}

#### Pozostaw instancję uruchomioną

Prosimy, aby instancja, która wykonała proces odzyskiwania, pozostała uruchomiona. W tle ponownie zsynchronizuje historię wszystkich projektów z współbieżnością równą 1. Spowoduje to nieco wyższe bazowe obciążenie. (Możesz uruchomić instancję ponownie, ale będzie musiała zacząć synchronizację od początku.)
{% endstep %}

{% step %}

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

Klienci Server Pro: prosimy poinformować zespół wsparcia, gdy zakończycie 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://overleaf-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.