> 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/no/vedlikehold/data-and-backups.md).

# Data og sikkerhetskopier

Noen ganger må vi endre skjemaet for dataene i databasen etter hvert som vi videreutvikler Overleaf. Migrasjonsskripter brukes til å automatisere denne prosessen. De vil ha blitt kjørt på [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) først, som er den største Overleaf-instansen i verden, så de fleste eventualiteter vil allerede ha blitt håndtert, men vi gir ingen garantier for dataene dine. Sørg for at du lager en **konsistent** sikkerhetskopi av dataene dine **før** du oppgraderer instansen din.

{% hint style="info" %}
Når du oppgraderer til et nytt Docker-bilde, vil eventuelle migreringer som har **ikke** ennå blitt kjørt, bli utført automatisk. Dette kan ta litt tid avhengig av størrelsen på datasettet ditt; å følge loggene vil fortelle deg fremdriften. For mer informasjon, se vår [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) dokumentasjon.
{% endhint %}

### Datalagring

Overleaf Community Edition og Server Pro lagrer dataene sine på tre separate steder:

* **MongoDB-database:** Det er her bruker- og prosjektdataene ligger.
* **Redis:** fungerer som en høyytelses hurtigbuffer for data under behandling, og lagrer hovedsakelig informasjon knyttet til prosjektredigeringer og samarbeid.
* **Overleaf-filsystemet:** lagrer prosjektfiler som ikke kan redigeres (inkludert bilder) og fungerer også som en midlertidig diskbuffer under prosjektkompileringer.

{% hint style="info" %}
Dette kan være `~/sharelatex_data` eller `~/overleaf_data`, avhengig av når instansen din ble satt opp.
{% endhint %}

{% hint style="success" %}
For prosjektfiler og fullstendige data for prosjekthistorikk støtter vi også S3-kompatible lagringsløsninger.
{% endhint %}

Se Mapper i detalj for mer informasjon om mappestrukturen på disken.

### Utføre en konsistent sikkerhetskopi

Det er tre lagringssteder som må inkluderes når du tar en konsistent sikkerhetskopi:

* MongoDB
* Redis
* Overleaf-filsystemdata

For å lage en konsistent sikkerhetskopi er det **obligatorisk** å hindre brukere i å produsere nye data mens sikkerhetskopieringsprosessen kjører. Vi anbefaler derfor å planlegge et vedlikeholdsvindu der brukere ikke skal kunne få tilgang til instansen eller redigere prosjektene sine.

Før du starter sikkerhetskopieringsprosessen må du ta instansen din offline. Med Server Pro `3.5.0` nedstengingsprosessen automatiserer stengingen av nettstedet og frakoblingen av brukere.

For å slå av instansen din må du kjøre `bin/docker-compose stop sharelatex` hvis du kjører en Toolkit-distribusjon, eller `docker compose stop sharelatex` hvis du kjører Docker Compose.

Når `sharelatex` containeren er stoppet, kan du starte sikkerhetskopieringsprosessen.

Når sikkerhetskopieringsprosessen er fullført **vellykket** må du starte `sharelatex` containeren. For å gjøre dette, kjør `bin/docker-compose start sharelatex` hvis du kjører en Toolkit-distribusjon, eller `docker compose start sharelatex` hvis du kjører Docker Compose.

{% hint style="danger" %}

* Sikkerhetskopier bør lagres på en separat server fra den Overleaf-instansen din kjører på, ideelt sett på et helt annet sted.
* Å replikere databaser til flere MongoDB-installer kan gi litt redundans, men det beskytter ikke mot datakorrupsjon.
* Å teste sikkerhetskopiene dine er den beste måten å sikre at de er fullstendige og fungerer.
  {% endhint %}

### MongoDB

MongoDB kommer med et kommandolinjeverktøy kalt [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) som kan brukes til å lage en sikkerhetskopi av bruker- og prosjektdata lagret i databasen.

### Overleaf-filsystemdata

For Toolkit-distribusjoner er banen der de ikke-redigerbare filene dine lagres spesifisert i `config/overleaf.rc` ved å bruke `OVERLEAF_DATA_PATH` miljøvariabelen, men avhengig av når instansen din ble opprettet, kan dette være `data/sharelatex`.

Ved å bruke et verktøy som **rsync** for rekursivt å kopiere denne katalogen, kreves det for å sikre at en fullstendig sikkerhetskopi blir opprettet.

### Redis

Redis lagrer brukersesjoner og ventende dokumentoppdateringer før de skrives til MongoDB.

Persistens med Append Only File (AOF) er den anbefalte konfigurasjonen for Redis-persistens.

Toolkit-brukere har AOF-persistens aktivert som standard for **nye** installasjoner, eksisterende brukere kan finne mer informasjon om å aktivere AOF [her](/on-premises/no/konfigurasjon/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

Hvis du bestemmer deg for å fortsette å bruke RDB-øyeblikksbilder sammen med AOF-persistens, kan du kopiere RDB-filen til et sikkert sted som en sikkerhetskopi.

### Migrering av data mellom servere

I beste fall har du ennå ikke noen verdifulle data i den nye instansen. Vi har ingen prosess for å slå sammen dataene til instanser.

Forutsatt at den nye instansen ikke har data ennå, er her noen trinn du kan følge. På et overordnet nivå lager vi en tar-fil av `mongo`, `redis` og `overleaf` volumene, kopierer den over til den nye serveren og pakker den ut der igjen.

#### Toolkit

```bash
# Slå av den gamle instansen på en kontrollert måte
old-server$ bin/stop

# Lag tar-filen
old-server$ tar --create --file backup-old-server.tar config/ data/

# Kopier filen backup-old-server.tar fra old-server til
# new-server ved hjelp av en hvilken som helst metode som passer

# Slå av den nye instansen på en kontrollert måte (hvis den allerede er startet)
new-server$ bin/stop

# Flytt de nye dataene, du kan også slette dem
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# Fyll config/data-katalogen igjen
new-server$ tar --extract --file backup-old-server.tar

# Start containere
new-server$ bin/up
```

#### Docker Compose

{% code overflow="wrap" %}

```bash
# Slå av den gamle instansen på en kontrollert måte
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Lag tar-filen
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Kopier filen backup-old-server.tar fra old-server til
# new-server ved hjelp av en hvilken som helst metode som passer

# Slå av den nye instansen på en kontrollert måte (hvis den allerede er startet)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Flytt de nye dataene, du kan også slette dem
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Fyll datakatalogene igjen
new-server$ tar --extract --file backup-old-server.tar

# Start containere
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

{% endcode %}

Avhengig av din **docker-compose.yml** fil, kan det hende du må justere banene til `mongo`, `redis`, `overleaf` volumene.

{% hint style="info" %}
Når du kjører som root-bruker (eller med sudo), vil tar beholde filens eier/gruppe og tillatelser, noe som er kritisk når sikkerhetskopien gjenopprettes.
{% endhint %}

### Mapper i detalj

{% hint style="info" %}
Følgende mapper har ytterligere hint:

* (b) inkluderes i sikkerhetskopier, best når instansen er stoppet for å sikre konsistens
* (d) kan slettes
* (e) flyktige filer, kan slettes når instansen er stoppet
  {% endhint %}

1. `~/mongo_data` (b)
   * mongodb-datakatalog
2. `~/redis_data` (b)
   * redis db-datakatalog
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * brukt ikke i den nyeste utgivelsen, tidligere ble en tilpasset synctex-binær brukt (synctex brukes til kildemapping mellom .tex-filer og pdf-en)
   2. data
      1. buffer (e)
         * buffer for binærfiler for kompileringer
      2. kompileringer (e)
         * latex-kompilering skjer her
      3. db.sqlite (d)
         * brukt ikke i den nyeste utgivelsen, tidligere lagret clsi-bufferdetaljer (enten flyttet til enkle minnebaserte kart eller så skanner vi disken)
      4. db.sqlite-wal (d)
         * brukt ikke i den nyeste utgivelsen, se db.sqlite
      5. output (e)
         * lagring av latex-kompileringsutdata for å servere til klienten
      6. template\_files (b)
         * forhåndsvisninger av bilder for mal-systemet (kun Server Pro)
      7. user\_files (b)
         * binærfiler i prosjekter
      8. history (b)
         * fullstendige prosjekthistorikkfiler
   3. tmp
      1. dumpFolder (e)
         * midlertidige filer fra håndtering av zip-filer
      2. uploads (e)
         * buffering av filopplastinger (binærfil/opplasting av nytt prosjekt fra zip)
      3. projectHistories (e)
         * midlertidige filer for migreringer av fullstendig prosjekthistorikk


---

# 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/no/vedlikehold/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.