> 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/konserwacja/data-and-backups.md). # Dane i kopie zapasowe Czasami musimy zmieniać schemat danych w bazie danych, gdy rozwijamy Overleaf; skrypty migracyjne służą do automatyzacji tego procesu. Zostaną 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ść ewentualnych przypadków została już napotkana, jednak nie dajemy żadnych gwarancji co do Twoich danych. Upewnij się, że tworzysz **spójną** kopię zapasową swoich danych **przed** przed uaktualnieniem Twojej instancji. {% hint style="info" %} Podczas uaktualniania do nowego obrazu Docker wszelkie migracje, które **nie** nie zostały jeszcze uruchomione, zostaną wykonane automatycznie; może to potrwać jakiś czas w zależności od rozmiaru zestawu danych, obserwowanie logów pokaże Ci postęp. Więcej informacji znajdziesz w naszej [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 wydajna pamięć podręczna dla danych w trakcie przetwarzania, przede wszystkim przechowując informacje związane z edycjami projektów i współpracą. * **System plików Overleaf:** przechowuje niemodyfikowalne pliki projektu (w tym obrazy) i służy także jako tymczasowa pamięć podręczna dyskowa podczas kompilacji projektów. {% hint style="info" %} Może to być `~/sharelatex_data` lub `~/overleaf_data`, w zależności od tego, kiedy Twoja instancja została skonfigurowana. {% endhint %} {% hint style="success" %} W przypadku plików projektu i pełnych danych historii projektu obsługujemy także zaplecza pamięci masowej zgodne z S3. {% endhint %} Zobacz sekcję Foldery szczegółowo, aby uzyskać więcej informacji o układzie folderów na dysku. ### Tworzenie spójnej kopii zapasowej Przy tworzeniu spójnej kopii zapasowej należy uwzględnić trzy magazyny: * MongoDB * Redis * Dane systemu plików Overleaf Aby utworzyć spójną kopię zapasową, **obowiązkowe** jest uniemożliwienie użytkownikom tworzenia nowych danych podczas działania procesu tworzenia kopii zapasowej. Zalecamy więc zaplanowanie okna konserwacyjnego, w trakcie którego użytkownicy nie powinni mieć możliwości dostępu do instancji ani edycji swoich projektów. Zanim rozpoczniesz proces tworzenia kopii zapasowej, będziesz musiał wyłączyć swoją instancję. W Server Pro `3.5.0` proces wyłączania automatyzuje zamknięcie witryny i rozłączenie użytkowników. Aby wyłączyć swoją instancję, musisz uruchomić `bin/docker-compose stop sharelatex` jeśli korzystasz z wdrożenia Toolkit lub `docker compose stop sharelatex` jeśli korzystasz z Docker Compose. Gdy `sharelatex` kontener zostanie zatrzymany, możesz rozpocząć proces tworzenia kopii zapasowej. Gdy proces tworzenia kopii zapasowej zakończy się **pomyślnie** będziesz musiał uruchomić `sharelatex` kontener. Aby to zrobić, uruchom `bin/docker-compose start sharelatex` jeśli korzystasz z wdrożenia Toolkit lub `docker compose start sharelatex` jeśli korzystasz z Docker Compose. {% hint style="danger" %} * Kopie zapasowe powinny być przechowywane na oddzielnym serwerze niż ten, 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ą nadmiarowość, 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óre można wykorzystać 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` używając `OVERLEAF_DATA_PATH` zmiennej środowiskowej, ale w zależności od tego, kiedy Twoja instancja została utworzona, może to być `data/sharelatex`. Korzystanie z narzędzia takiego jak **rsync** do rekurencyjnego skopiowania tego katalogu jest wymagane, aby upewnić się, że powstaje pełna kopia zapasowa. ### Redis Redis przechowuje sesje użytkowników i oczekujące aktualizacje dokumentów, zanim zostaną zapisane do MongoDB. Trwałość typu Append Only File (AOF) jest zalecaną konfiguracją trwałości w Redisie. Użytkownicy Toolkit mają domyślnie włączoną trwałość AOF dla **nowe** 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 używać migawek RDB wraz z trwałością AOF, możesz skopiować plik RDB do bezpiecznej lokalizacji jako kopię zapasową. ### Migrowanie danych między serwerami W najlepszym razie w nowej instancji nie masz jeszcze żadnych wartościowych danych. Nie mamy procesu łączenia danych z instancji. Zakładając, że nowa instancja nie ma jeszcze żadnych danych, oto kilka kroków, które możesz wykonać. Ogólnie rzecz biorąc, tworzymy archiwum tar z `mongo`, `redis` i `Overleaf` woluminów, kopiujemy je na nowy serwer i rozpakowujemy tam ponownie. #### Toolkit ```bash # Płynnie wyłącz starą instancję old-server$ bin/stop # Utwórz archiwum tar old-server$ tar --create --file backup-old-server.tar config/ data/ # Skopiuj plik backup-old-server.tar ze starego-serwera do # nowego-serwera, używając dowolnej metody, która Ci odpowiada # Płynnie wyłącz nową instancję (jeśli jeszcze 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 # Płynnie wyłącz starą instancję old-server$ docker stop sharelatex old-server$ docker stop mongo redis # Utwórz archiwum tar old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data # Skopiuj plik backup-old-server.tar ze starego-serwera do # nowego-serwera, używając dowolnej metody, która Ci odpowiada # Płynnie wyłącz nową instancję (jeśli jeszcze 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` woluminów. {% hint style="info" %} Podczas uruchamiania jako użytkownik root (lub z sudo), tar zachowa właściciela/grupę pliku i uprawnienia, co jest kluczowe podczas przywracania kopii zapasowej. {% endhint %} ### Foldery szczegółowo {% 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 efemeryczne, można 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 binarium synctex (synctex służy do mapowania źródła między plikami .tex a plikiem pdf) 2. data 1. pamięć podręczna (e) * binarna pamięć podręczna plików dla kompilacji 2. kompilacje (e) * tutaj odbywa się kompilacja LaTeX 3. db.sqlite (d) * nieużywane w najnowszym wydaniu, wcześniej przechowywało szczegóły pamięci podręcznej clsi (albo zostały przeniesione 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) * miejsce przechowywania wyników kompilacji LaTeX do udostępnienia klientowi 6. pliki szablonów (b) * podglądy obrazów systemu szablonów (tylko Server Pro) 7. pliki użytkownika (b) * pliki binarne projektów 8. historia (b) * pełne pliki historii projektu 3. tmp 1. folder zrzutu (e) * pliki tymczasowe z obsługi plików zip 2. przesyłki (e) * buforowanie przesyłanych plików (przesyłanie pliku binarnego/nowego projektu z pliku zip) 3. historie projektów (e) * tymczasowe pliki dla pełnych migracji 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://ayakaleaf-pro.ayaka.space/on-premises/pl/konserwacja/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.