> 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/nl/onderhoud/data-and-backups.md). # Gegevens en back-ups Soms moeten we het dataschema in de database aanpassen naarmate we Overleaf verder ontwikkelen; migratiescripts worden gebruikt om dit proces te automatiseren. Ze zullen zijn uitgevoerd op [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) de eerste, de grootste Overleaf-instantie ter wereld, dus de meeste scenario's zullen al zijn tegengekomen; we geven echter geen garanties over uw gegevens. Zorg ervoor dat u een **consistent** back-up van uw gegevens **voordat** uw instantie upgradet. {% hint style="info" %} Wanneer u upgradet naar een nieuw Docker-image, worden eventuele migraties die **nog** niet zijn uitgevoerd automatisch uitgevoerd; dit kan enige tijd duren, afhankelijk van de grootte van uw dataset. Door de logs te volgen, ziet u de voortgang. Voor meer informatie, zie onze [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) documentatie. {% endhint %} ### Gegevensopslag Overleaf Community Edition en Server Pro slaan hun gegevens op drie afzonderlijke plaatsen op: * **MongoDB-database:** Hier bevinden zich gebruikers- en projectgegevens. * **Redis:** dient als een cache met hoge prestaties voor gegevens in gebruik, en slaat voornamelijk informatie op die verband houdt met projectbewerkingen en samenwerking. * **Overleaf-bestandssysteem:** slaat niet-bewerkbare projectbestanden op (inclusief afbeeldingen) en fungeert ook als tijdelijke schijfcache tijdens projectcompilaties. {% hint style="info" %} Dit kan zijn `~/sharelatex_data` of `~/overleaf_data`, afhankelijk van wanneer uw instantie is ingesteld. {% endhint %} {% hint style="success" %} Voor projectbestanden en volledige projectgeschiedenisgegevens ondersteunen we ook S3-compatibele opslagback-ends. {% endhint %} Zie Mappen in detail voor meer informatie over de mapindeling op schijf. ### Een consistente back-up maken Er zijn drie opslagplaatsen die moeten worden meegenomen bij het maken van een consistente back-up: * MongoDB * Redis * Overleaf-bestandssysteemgegevens Om een consistente back-up te maken is het **verplicht** om te voorkomen dat gebruikers nieuwe gegevens aanmaken terwijl het back-upproces draait. We adviseren daarom een onderhoudsvenster in te plannen waarin gebruikers geen toegang hebben tot de instantie of hun projecten kunnen bewerken. Voordat u begint met het back-upproces, moet u uw instantie offline halen. Vanaf Server Pro `3.5.0` automatiseert het afsluitproces het sluiten van de site en het verbreken van de verbinding van gebruikers. Om uw instantie af te sluiten moet u `bin/docker-compose stop sharelatex` uitvoeren als u een Toolkit-implementatie gebruikt of `docker compose stop sharelatex` als u Docker Compose gebruikt. Zodra de `sharelatex` container is gestopt, kunt u het back-upproces starten. Zodra het back-upproces **succesvol** is voltooid, moet u de `sharelatex` container starten. Voer hiervoor uit `bin/docker-compose start sharelatex` uitvoeren als u een Toolkit-implementatie gebruikt of `docker compose start sharelatex` als u Docker Compose gebruikt. {% hint style="danger" %} * Back-ups moeten worden opgeslagen op een aparte server van die waarop uw Overleaf-instantie draait, bij voorkeur zelfs op een volledig andere locatie. * Databases repliceren naar meerdere MongoDB-instanties kan enige redundantie bieden, maar beschermt niet tegen beschadiging. * Uw back-ups testen is de beste manier om ervoor te zorgen dat ze volledig en functioneel zijn. {% endhint %} ### MongoDB MongoDB wordt geleverd met een command-linehulpmiddel genaamd [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) dat gebruikt kan worden om een back-up te maken van gebruikers- en projectgegevens die in de database zijn opgeslagen. ### Overleaf-bestandssysteemgegevens Voor Toolkit-implementaties wordt het pad waar uw niet-bewerkbare bestanden zijn opgeslagen gespecificeerd in `config/overleaf.rc` met de `OVERLEAF_DATA_PATH` omgevingsvariabele, maar afhankelijk van wanneer uw instantie is aangemaakt, kan dit zijn `data/sharelatex`. Het gebruik van een hulpmiddel zoals **rsync** om deze map recursief te kopiëren is vereist om ervoor te zorgen dat een volledige back-up wordt gemaakt. ### Redis Redis slaat gebruikerssessies en openstaande documentwijzigingen op voordat ze naar MongoDB worden weggeschreven. Append Only File (AOF)-persistentie is de aanbevolen configuratie voor Redis-persistentie. Toolkit-gebruikers hebben AOF-persistentie standaard ingeschakeld voor **nieuwe** installaties; bestaande gebruikers kunnen hier meer informatie vinden over het inschakelen van AOF [hier](/on-premises/nl/configuratie/overleaf-toolkit/redis.md#enabling-append-only-file-persistence). Als u besluit RDB-snapshots samen met AOF-persistentie te blijven gebruiken, kunt u het RDB-bestand als back-up naar een veilige locatie kopiëren. ### Gegevens migreren tussen servers In het beste geval heeft u nog geen waardevolle gegevens in de nieuwe instantie. We hebben geen proces om de gegevens van instanties samen te voegen. Ervan uitgaande dat de nieuwe instantie nog geen gegevens heeft, zijn hier enkele stappen die u kunt volgen. Op hoofdlijnen maken we een tarball van de `mongo`, `redis` en `overleaf` volumes, kopiëren we die naar de nieuwe server en pakken we die daar opnieuw uit. #### Toolkit ```bash # Sluit de oude instantie netjes af old-server$ bin/stop # Maak de tarball old-server$ tar --create --file backup-old-server.tar config/ data/ # Kopieer het bestand backup-old-server.tar van de old-server naar de # new-server met elke methode die geschikt is # Sluit de nieuwe instantie netjes af (indien al gestart) new-server$ bin/stop # Verplaats de nieuwe gegevens; u kunt ze ook verwijderen new-server$ mkdir backup-new-server new-server$ mv config/ data/ backup-new-server/ # Vul de config/data-map opnieuw new-server$ tar --extract --file backup-old-server.tar # Start containers new-server$ bin/up ``` #### Docker Compose ```bash # Sluit de oude instantie netjes af old-server$ docker stop sharelatex old-server$ docker stop mongo redis # Maak de tarball old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data # Kopieer het bestand backup-old-server.tar van de old-server naar # de new-server met elke methode die geschikt is # Sluit de nieuwe instantie netjes af (indien al gestart) new-server$ docker stop sharelatex new-server$ docker stop mongo redis # Verplaats de nieuwe gegevens; u kunt ze ook verwijderen new-server$ mkdir backup-new-server new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/ # Vul de gegevensmappen opnieuw new-server$ tar --extract --file backup-old-server.tar # Start containers new-server$ docker start mongo redis new-server$ docker start sharelatex ``` Afhankelijk van uw **docker-compose.yml** bestand moet u mogelijk de paden van de `mongo`, `redis`, `overleaf` volumes aanpassen. {% hint style="info" %} Wanneer u als root-gebruiker (of met sudo) draait, behoudt tar de bestandseigenaar/-groep en rechten, wat van cruciaal belang is bij het herstellen van de back-up. {% endhint %} ### Mappen in detail {% hint style="info" %} De volgende mappen hebben aanvullende aanwijzingen: * (b) opnemen in back-ups, het beste wanneer de instantie is gestopt om consistentie te garanderen * (d) kan worden verwijderd * (e) tijdelijke bestanden, kunnen worden verwijderd wanneer de instantie is gestopt {% endhint %} 1. `~/mongo_data` (b) * mongodb-datamap 2. `~/redis_data` (b) * redis db-datamap 3. `~/overleaf_data` 1. bin 1. synctex (d) * niet gebruikt in de laatste release; eerder werd een aangepaste synctex-binary gebruikt (synctex wordt gebruikt voor bronmapping tussen .tex-bestanden en de pdf) 2. data 1. cache (e) * binaire bestandscache voor compiles 2. compiles (e) * hier vindt de latex-compiler plaats 3. db.sqlite (d) * niet gebruikt in de laatste release, eerder opgeslagen cls-cachedetails (verplaatst naar eenvoudige in-memory maps of we scannen de schijf) 4. db.sqlite-wal (d) * niet gebruikt in de laatste release, zie db.sqlite 5. output (e) * opslag van output van latex-compilatie voor het serveren aan de client 6. template\_files (b) * afbeeldingsvoorvertoningen van het sjabloonsysteem (alleen Server Pro) 7. user\_files (b) * binaire bestanden van projecten 8. history (b) * volledige bestanden van projectgeschiedenis 3. tmp 1. dumpFolder (e) * tijdelijke bestanden van het verwerken van zipbestanden 2. uploads (e) * buffering van bestandsuploads (upload van binair bestand/nieuw-project-uit-zip) 3. projectHistories (e) * tijdelijke bestanden voor migraties van volledige projectgeschiedenissen --- # 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/nl/onderhoud/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.