> 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/nl/onderhoud/data-and-backups.md).

# Gegevens en back-ups

Soms moeten we het schema van gegevens in de database wijzigen 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) eerst, wat de grootste instantie van Overleaf ter wereld is, dus de meeste eventualiteiten zijn waarschijnlijk al tegengekomen; we geven echter geen garanties over uw gegevens. Zorg ervoor dat u een **consistente** back-up van uw gegevens **voordat** bij het upgraden van uw instantie.

{% hint style="info" %}
Wanneer u upgradet naar een nieuwe Docker-image, worden eventuele migraties die **niet** nog niet zijn uitgevoerd automatisch uitgevoerd; dit kan enige tijd duren, afhankelijk van de grootte van uw dataset, en door de logs te volgen krijgt u inzicht in de voortgang. Voor meer informatie, zie onze [Logregistratie](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:** fungeert als een hoogwaardige cache voor gegevens die nog onderweg zijn en slaat voornamelijk informatie op met betrekking tot projectbewerkingen en samenwerking.
* **Overleaf-bestandssysteem:** slaat niet-bewerkbare projectbestanden (inclusief afbeeldingen) op 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 opslagbackends.
{% endhint %}

Zie Mappen in detail voor meer informatie over de mapindeling op schijf.

### Een consistente back-up uitvoeren

Er zijn drie opslaglocaties 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** gebruikers te verhinderen nieuwe gegevens aan te maken 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 het back-upproces start, 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 uitvoeren `bin/docker-compose stop sharelatex` 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 opnieuw starten. Voer hiervoor uit `bin/docker-compose start sharelatex` 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 andere server dan die waarop uw Overleaf-instantie draait, idealiter zelfs op een volledig andere locatie.
* Het repliceren van databases naar meerdere MongoDB-instanties kan enige redundantie bieden, maar beschermt niet tegen corruptie.
* Het testen van uw back-ups is de beste manier om ervoor te zorgen dat ze volledig en functioneel zijn.
  {% endhint %}

### MongoDB

MongoDB wordt geleverd met een opdrachtregelhulpprogramma genaamd [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) dat kan worden gebruikt om een back-up te maken van gebruikers- en projectgegevens die in de database zijn opgeslagen.

### Overleaf-bestandssysteemgegevens

Voor Toolkit-implementaties is het pad waar uw niet-bewerkbare bestanden worden opgeslagen gespecificeerd in `config/overleaf.rc` met behulp van de `OVERLEAF_DATA_PATH` omgevingsvariabele, maar afhankelijk van wanneer uw instantie is gemaakt, kan dit `data/sharelatex`.

Het gebruik van een hulpmiddel zoals **rsync** om deze map recursief te kopiëren is vereist om ervoor te zorgen dat er een volledige back-up wordt gemaakt.

### Redis

Redis slaat gebruikerssessies en openstaande documentupdates op voordat ze naar MongoDB worden weggeschreven.

Persistentie via Append Only File (AOF) is de aanbevolen configuratie voor Redis-persistentie.

Toolkit-gebruikers hebben AOF-persistentie standaard ingeschakeld voor **nieuwe** installaties; bestaande gebruikers kunnen 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 staan er nog geen waardevolle gegevens in de nieuwe instantie. We hebben geen proces om de gegevens van instanties samen te voegen.

Aangenomen dat de nieuwe instantie nog geen gegevens heeft, volgen 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 tar-ball
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 een methode die past

# 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 de 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 tar-ball
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 een methode die past

# 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 de 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 tar wordt uitgevoerd als root-gebruiker (of met sudo), behoudt tar de eigenaar/groep en machtigingen van het bestand, wat cruciaal is bij het terugzetten van de back-up.
{% endhint %}

### Mappen in detail

{% hint style="info" %}
De volgende mappen hebben aanvullende opmerkingen:

* (b) opnemen in back-ups, het beste wanneer de instantie is gestopt om consistentie te waarborgen
* (d) kan worden verwijderd
* (e) tijdelijke bestanden, kunnen worden verwijderd wanneer de instantie is gestopt
  {% endhint %}

1. `~/mongo_data` (b)
   * mongodb-gegevensmap
2. `~/redis_data` (b)
   * redis-db-gegevensmap
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * niet gebruikt in de nieuwste release; eerder werd een aangepaste synctex-binaire gebruikt (synctex wordt gebruikt voor bronmapping tussen .tex-bestanden en de pdf)
   2. data
      1. cache (e)
         * cache van binaire bestanden voor compilaties
      2. compilaties (e)
         * hier vindt de LaTeX-compilatie plaats
      3. db.sqlite (d)
         * niet gebruikt in de nieuwste release; eerder werden hier clsi-cachedetails opgeslagen (ofwel verplaatst naar eenvoudige in-memory mappen of we scannen de schijf)
      4. db.sqlite-wal (d)
         * niet gebruikt in de nieuwste release, zie db.sqlite
      5. output (e)
         * opslag van uitvoer van LaTeX-compilatie voor levering aan de client
      6. template\_files (b)
         * afbeeldingsvoorvertoningen van het templatesysteem (alleen Server Pro)
      7. user\_files (b)
         * binaire bestanden van projecten
      8. history (b)
         * bestanden van de volledige projectgeschiedenis
   3. tmp
      1. dumpFolder (e)
         * tijdelijke bestanden voor het verwerken van zipbestanden
      2. uploads (e)
         * bufferen van bestandsuploads (upload van binair bestand/nieuw project uit zip)
      3. projectHistories (e)
         * tijdelijke bestanden voor migraties van de volledige projectgeschiedenis


---

# 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/nl/onderhoud/data-and-backups.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.