> 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/utrzymanie/data-and-backups.md). # Dane i kopie zapasowe Czasami musimy zmienić schemat danych w bazie danych, gdy rozwijamy Overleaf; do automatyzacji tego procesu używa się skryptów migracyjnych. Zostaną one uruchomione na [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) najpierw, która jest największą instancją Overleaf na świecie, więc większość możliwych sytuacji została już napotkana, jednak nie dajemy żadnych gwarancji dotyczących twoich danych. Upewnij się, że tworzysz **spójną** kopię zapasową swoich danych **przed** aktualizujesz swoją instancję. {% hint style="info" %} Podczas aktualizacji do nowego obrazu Dockera wszelkie migracje, które **nie** nie zostały jeszcze uruchomione, zostaną automatycznie wykonane; może to trochę potrwać w zależności od rozmiaru zestawu danych, śledzenie logów pokaże ci postęp. Więcej informacji znajdziesz w naszym [Logowanie](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) dokumentacji. {% endhint %} ### Przechowywanie danych Overleaf Community Edition i Server Pro przechowują swoje dane w trzech oddzielnych miejscach: * **Baza danych MongoDB:** To tutaj znajdują się dane użytkowników i projektów. * **Redis:** służy jako wysokowydajna pamięć podręczna dla danych w trakcie przetwarzania, przechowując głównie informacje związane z edycjami projektu i współpracą. * **System plików Overleaf:** przechowuje niemodyfikowalne pliki projektu (w tym obrazy), a także działa jako tymczasowa pamięć podręczna dysku podczas kompilacji projektu. {% hint style="info" %} Może to być `~/sharelatex_data` lub `~/overleaf_data`, w zależności od tego, kiedy została skonfigurowana twoja instancja. {% endhint %} {% hint style="success" %} Dla plików projektu i pełnych danych historii projektu obsługujemy również magazyny zgodne z S3. {% endhint %} Zobacz szczegóły dotyczące Folderów, aby uzyskać więcej informacji o układzie folderów na dysku. ### Wykonywanie spójnej kopii zapasowej Istnieją trzy zasoby, które należy uwzględnić podczas tworzenia spójnej kopii zapasowej: * MongoDB * Redis * Dane systemu plików Overleaf Aby utworzyć spójną kopię zapasową, jest to **obowiązkowe** uniemożliwić użytkownikom tworzenie nowych danych podczas działania procesu tworzenia kopii zapasowej. Dlatego zalecamy zaplanowanie okna serwisowego, podczas którego użytkownicy nie powinni mieć dostępu do instancji ani edytować swoich projektów. Przed rozpoczęciem procesu tworzenia kopii zapasowej musisz wyłączyć swoją instancję. W przypadku Server Pro `3.5.0` proces zamykania automatyzuje zamknięcie witryny i rozłączenie użytkowników. Aby wyłączyć swoją instancję, musisz uruchomić `bin/docker-compose stop sharelatex` jeśli uruchamiasz wdrożenie Toolkit, lub `docker compose stop sharelatex` jeśli uruchamiasz Docker Compose. Gdy `sharelatex` kontener zostanie zatrzymany, możesz rozpocząć proces tworzenia kopii zapasowej. Gdy proces tworzenia kopii zapasowej zostanie zakończony **pomyślnie** musisz uruchomić `sharelatex` kontener. Aby to zrobić, uruchom `bin/docker-compose start sharelatex` jeśli uruchamiasz wdrożenie Toolkit, lub `docker compose start sharelatex` jeśli uruchamiasz Docker Compose. {% hint style="danger" %} * Kopie zapasowe powinny być przechowywane na oddzielnym serwerze od tego, na którym działa twoja instancja Overleaf, najlepiej w zupełnie innej lokalizacji. * Replikowanie baz danych na wielu instancjach MongoDB może zapewnić pewną redundancję, ale nie chroni przed uszkodzeniem. * Testowanie kopii zapasowych to najlepszy sposób, aby upewnić się, że są kompletne i działają poprawnie. {% endhint %} ### MongoDB MongoDB zawiera narzędzie wiersza poleceń o nazwie [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) którego można użyć do utworzenia kopii zapasowej danych użytkowników i projektów przechowywanych w bazie danych. ### Dane systemu plików Overleaf W przypadku wdrożeń Toolkit ścieżka, w której przechowywane są twoje niemodyfikowalne pliki, jest określona w `config/overleaf.rc` za pomocą `OVERLEAF_DATA_PATH` zmiennej środowiskowej, ale w zależności od tego, kiedy została utworzona twoja instancja, może to być `data/sharelatex`. Użycie narzędzia takiego jak **rsync** do rekurencyjnego skopiowania tego katalogu jest wymagane, aby zapewnić utworzenie pełnej kopii zapasowej. ### Redis Redis przechowuje sesje użytkowników i oczekujące aktualizacje dokumentów, zanim zostaną zapisane w MongoDB. Trwałość typu Append Only File (AOF) jest zalecaną konfiguracją trwałości Redis. Użytkownicy Toolkit mają domyślnie włączoną trwałość AOF dla **nowych** instalacji; istniejący użytkownicy mogą znaleźć więcej informacji na temat włączania AOF [tutaj](/on-premises/pl/konfiguracja/overleaf-toolkit/redis.md#enabling-append-only-file-persistence). Jeśli zdecydujesz się nadal korzystać z migawek RDB razem z trwałością AOF, możesz skopiować plik RDB w bezpieczne miejsce jako kopię zapasową. ### Migracja danych między serwerami W najlepszym razie w nowej instancji nie masz jeszcze żadnych wartościowych danych. Nie mamy procesu łączenia danych instancji. Zakładając, że nowa instancja nie ma jeszcze danych, oto kilka kroków, które możesz wykonać. W skrócie tworzymy archiwum tar-ball zawierające `mongo`, `redis` i `overleaf` wolumenów, kopiujemy je na nowy serwer i rozpakowujemy tam ponownie. #### Toolkit ```bash # Bezpiecznie wyłącz starą instancję old-server$ bin/stop # Utwórz archiwum tar-ball old-server$ tar --create --file backup-old-server.tar config/ data/ # Skopiuj plik backup-old-server.tar ze starego serwera na # nowy serwer dowolną odpowiednią metodą # Bezpiecznie wyłącz nową instancję (jeśli została już uruchomiona) new-server$ bin/stop # Przenieś nowe dane, możesz je też usunąć new-server$ mkdir backup-new-server new-server$ mv config/ data/ backup-new-server/ # Ponownie wypełnij katalog config/data new-server$ tar --extract --file backup-old-server.tar # Uruchom kontenery new-server$ bin/up ``` #### Docker Compose ```bash # Bezpiecznie wyłącz starą instancję old-server$ docker stop sharelatex old-server$ docker stop mongo redis # Utwórz archiwum tar-ball old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data # Skopiuj plik backup-old-server.tar ze starego serwera na # nowy serwer dowolną odpowiednią metodą # Bezpiecznie wyłącz nową instancję (jeśli została już uruchomiona) new-server$ docker stop sharelatex new-server$ docker stop mongo redis # Przenieś nowe dane, możesz je też usunąć new-server$ mkdir backup-new-server new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/ # Ponownie wypełnij katalogi danych new-server$ tar --extract --file backup-old-server.tar # Uruchom kontenery new-server$ docker start mongo redis new-server$ docker start sharelatex ``` W zależności od twojego **docker-compose.yml** pliku, może być konieczne dostosowanie ścieżek `mongo`, `redis`, `overleaf` wolumenów. {% hint style="info" %} Podczas uruchamiania jako użytkownik root (lub z sudo) tar zachowa właściciela/grupę pliku oraz uprawnienia, co jest kluczowe podczas przywracania kopii zapasowej. {% endhint %} ### Szczegółowy opis folderów {% hint style="info" %} Poniższe foldery mają dodatkowe wskazówki: * (b) uwzględniać w kopiach zapasowych, najlepiej gdy instancja jest zatrzymana, aby zapewnić spójność * (d) można usunąć * (e) pliki ulotne, można je usunąć, gdy instancja jest zatrzymana {% endhint %} 1. `~/mongo_data` (b) * katalog danych MongoDB 2. `~/redis_data` (b) * katalog danych bazy Redis 3. `~/overleaf_data` 1. bin 1. synctex (d) * nieużywane w najnowszym wydaniu, wcześniej używano niestandardowego binarnego pliku synctex (synctex służy do mapowania źródeł między plikami .tex a plikiem PDF) 2. dane 1. pamięć podręczna (e) * pamięć podręczna plików binarnych dla kompilacji 2. kompilacje (e) * tutaj odbywa się kompilacja LaTeX 3. db.sqlite (d) * nieużywane w najnowszym wydaniu, wcześniej przechowywano szczegóły pamięci podręcznej clsi (albo przeniesiono je do prostych map w pamięci, albo skanujemy dysk) 4. db.sqlite-wal (d) * nieużywane w najnowszym wydaniu, zobacz db.sqlite 5. wynik (e) * magazyn wyników kompilacji LaTeX do udostępniania klientowi 6. template\_files (b) * podglądy obrazów systemu szablonów (tylko Server Pro) 7. user\_files (b) * pliki binarne projektów 8. history (b) * pliki pełnej historii projektu 3. tmp 1. folder zrzutu (e) * pliki tymczasowe z obsługi plików zip 2. przesłane pliki (e) * buforowanie przesyłanych plików (wysyłanie pliku binarnego / nowego projektu z archiwum ZIP) 3. historie projektów (e) * pliki tymczasowe do migracji pełnej historii projektu --- # 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/utrzymanie/data-and-backups.md?ask=&goal= ``` `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.