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

# Data og sikkerhetskopier

Noen ganger må vi endre skjemaet for dataene i databasen når vi videreutvikler Overleaf. Migrasjonsskript 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 situasjoner vil allerede ha blitt håndtert, men vi gir ingen garantier for dataene dine. Sørg for at du oppretter en **konsistent** sikkerhetskopi av dataene dine **før** oppgraderer instansen din.

{% hint style="info" %}
Når du oppgraderer til et nytt Docker-bilde, vil eventuelle migreringer som har **ikke** ennå ikke har blitt kjørt, bli utført automatisk. Dette kan ta litt tid avhengig av størrelsen på datasettet ditt. Ved å følge loggene kan du se fremdriften. For mer informasjon, se vår [logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) dokumentasjonen.
{% 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øyytelsesbuffer for data under behandling, og lagrer primært informasjon knyttet til prosjektredigeringer og samarbeid.
* **Overleaf-filsystemet:** lagrer ikke-redigerbare prosjektfiler (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 prosjekthistorikkdata 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 man 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 brukerne ikke skal ha tilgang til instansen eller kunne redigere prosjektene sine.

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

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 egen server, adskilt fra den Overleaf-instansen din kjører på, helst på et helt annet sted.
* Replikering av databaser til flere MongoDB-instanser kan gi en viss redundans, men det beskytter ikke mot korrupsjon.
* Å teste sikkerhetskopiene dine er den beste måten å sikre at de er komplette og fungerer.
  {% endhint %}

### MongoDB

MongoDB leveres 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, angitt 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 å kopiere denne katalogen rekursivt, er nødvendig for å sikre at en fullstendig sikkerhetskopi blir opprettet.

### Redis

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

Append Only File (AOF)-persistens 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/on-premises-no/konfigurasjon/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

Hvis du velger å fortsette å bruke RDB-snapshots 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å ingen verdifulle data i den nye instansen. Vi har ikke en prosess for å slå sammen data fra instanser.

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

#### Toolkit

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

# Opprett tar-ballen
old-server$ tar --create --file backup-old-server.tar config/ data/

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

# Slå av den nye instansen på en skånsom 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 på nytt
new-server$ tar --extract --file backup-old-server.tar

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

#### Docker Compose

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

# Opprett tar-ballen
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
# den nye serveren ved å bruke en hvilken som helst metode som passer

# Slå av den nye instansen på en skånsom 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 på nytt
new-server$ tar --extract --file backup-old-server.tar

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

Avhengig av **docker-compose.yml** filen, kan det hende du må justere stiene 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 avgjørende når sikkerhetskopien gjenopprettes.
{% endhint %}

### Mapper i detalj

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

* (b) skal tas med 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)
         * ubrukt i siste versjon, tidligere ble en egendefinert 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)
         * ubrukt i siste versjon, tidligere lagret detaljer om clsi-bufferen (enten flyttet til enkle minnekart, eller så skanner vi disken)
      4. db.sqlite-wal (d)
         * ubrukt i siste versjon, se db.sqlite
      5. utdata (e)
         * lagring av LaTeX-kompileringsutdata for levering til klienten
      6. template\_files (b)
         * forhåndsvisninger av bilder i malssystemet (kun Server Pro)
      7. user\_files (b)
         * binærfiler fra 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 migrering av full 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://overleaf-pro.ayaka.space/on-premises/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.