> 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/da/vedligeholdelse/data-and-backups.md).

# Data og sikkerhedskopier

Nogle gange er vi nødt til at ændre databaseskemaet, efterhånden som vi udvikler Overleaf. Migreringsscripts bruges til at automatisere denne proces. De vil være blevet kørt på [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) først, som er den største Overleaf-instans i verden, så de fleste eventualiteter vil allerede være blevet mødt; vi giver dog ingen garantier for dine data. Sørg for, at du opretter en **konsistent** sikkerhedskopi af dine data **før** når du opgraderer din instans.

{% hint style="info" %}
Når du opgraderer til et nyt Docker-image, vil eventuelle migrationer, der har **ikke** endnu ikke er blevet kørt, blive udført automatisk. Dette kan tage noget tid afhængigt af størrelsen af dit datasæt; ved at følge loggene kan du se fremskridtet. For mere information, se vores [Logføring](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) dokumentationen.
{% endhint %}

### Datalagring

Overleaf Community Edition og Server Pro gemmer deres data tre forskellige steder:

* **MongoDB-database:** Det er her bruger- og projektdata ligger.
* **Redis:** fungerer som en højtydende cache for data under behandling og gemmer primært oplysninger om projektredigeringer og samarbejde.
* **Overleaf-filsystem:** gemmer ikke-redigerbare projektfiler (herunder billeder) og fungerer også som en midlertidig diskcache under projektkompileringer.

{% hint style="info" %}
Det kan være `~/sharelatex_data` eller `~/overleaf_data`, afhængigt af hvornår din instans blev sat op.
{% endhint %}

{% hint style="success" %}
For projektfiler og fulde projekthistorikdata understøtter vi også S3-kompatible lagringsbackends.
{% endhint %}

Se Mapper i detaljer for mere information om mappestrukturen på disken.

### Udførelse af en konsistent sikkerhedskopi

Der er tre lagre, som skal medtages, når der tages en konsistent sikkerhedskopi:

* MongoDB
* Redis
* Overleaf-filsystemdata

For at lave en konsistent sikkerhedskopi er det **obligatorisk** at forhindre brugere i at oprette nye data, mens backup-processen kører. Vi anbefaler derfor at planlægge et vedligeholdelsesvindue, hvor brugerne ikke bør kunne få adgang til instansen eller redigere deres projekter.

Før du starter backup-processen, skal du tage din instans offline. Med Server Pro starter `3.5.0` automatiserer nedlukningsprocessen lukningen af siden og frakoblingen af brugere.

For at lukke din instans ned skal du køre `bin/docker-compose stop sharelatex` hvis du kører en Toolkit-implementering, eller `docker compose stop sharelatex` hvis du kører Docker Compose.

Når `sharelatex` containeren er stoppet, kan du starte backup-processen.

Når backup-processen er gennemført **succesfuldt** skal du starte `sharelatex` containeren. For at gøre dette skal du køre `bin/docker-compose start sharelatex` hvis du kører en Toolkit-implementering, eller `docker compose start sharelatex` hvis du kører Docker Compose.

{% hint style="danger" %}

* Sikkerhedskopier bør gemmes på en separat server fra den, din Overleaf-instans kører på, helst et helt andet sted.
* Replikering af databaser til flere MongoDB-instanser kan give en vis redundans, men det beskytter ikke mod korruption.
* At teste dine sikkerhedskopier er den bedste måde at sikre, at de er komplette og fungerer.
  {% endhint %}

### MongoDB

MongoDB leveres med et kommandolinjeværktøj kaldet [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) som kan bruges til at oprette en sikkerhedskopi af bruger- og projekdata, der er gemt i databasen.

### Overleaf-filsystemdata

For Toolkit-implementeringer er stien, hvor dine ikke-redigerbare filer gemmes, angivet i `config/overleaf.rc` ved hjælp af `OVERLEAF_DATA_PATH` miljøvariabel, men afhængigt af hvornår din instans blev oprettet, kan dette være `data/sharelatex`.

Ved at bruge et værktøj såsom **rsync** til rekursivt at kopiere denne mappe er det nødvendigt for at sikre, at en fuldstændig sikkerhedskopi oprettes.

### Redis

Redis gemmer brugersessioner og afventende dokumentopdateringer, før de flushes til MongoDB.

Append Only File (AOF)-persistens er den anbefalede konfiguration til Redis-persistens.

Toolkit-brugere har AOF-persistens aktiveret som standard for **nye** installationer; eksisterende brugere kan finde mere information om aktivering af AOF [her](/on-premises/da/konfiguration/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

Hvis du beslutter at fortsætte med at bruge RDB-snapshots sammen med AOF-persistens, kan du kopiere RDB-filen til et sikkert sted som en sikkerhedskopi.

### Migrering af data mellem servere

I bedste fald har du endnu ingen værdifulde data i den nye instans. Vi har ikke en proces til at sammenflette data fra instanser.

Forudsat at den nye instans endnu ikke har data, er her nogle trin, du kan følge. Overordnet set laver vi en tar-fil af `mongo`, `redis` og `overleaf` volumenerne, kopierer den til den nye server og pakker den ud igen der.

#### Toolkit

```bash
# Luk den gamle instans ned på en ordentlig måde
old-server$ bin/stop

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

# Kopiér filen backup-old-server.tar fra old-server til
# new-server ved hjælp af en hvilken som helst metode, der passer

# Luk den nye instans ned på en ordentlig måde (hvis den allerede er startet)
new-server$ bin/stop

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

# Udfyld config/data-mappen igen
new-server$ tar --extract --file backup-old-server.tar

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

#### Docker Compose

```bash
# Luk den gamle instans ned på en ordentlig måde
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

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

# Kopiér filen backup-old-server.tar fra old-server til
# den nye server ved hjælp af en hvilken som helst metode, der passer

# Luk den nye instans ned på en ordentlig måde (hvis den allerede er startet)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

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

# Udfyld datamapperne igen
new-server$ tar --extract --file backup-old-server.tar

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

Afhængigt af din **docker-compose.yml** fil kan du være nødt til at justere stierne for `mongo`, `redis`, `overleaf` volumenerne.

{% hint style="info" %}
Når tar køres som root-bruger (eller med sudo), bevarer den filens ejer/gruppe og tilladelser, hvilket er afgørende, når sikkerhedskopien gendannes.
{% endhint %}

### Mapper i detaljer

{% hint style="info" %}
Følgende mapper har yderligere bemærkninger:

* (b) medtages i sikkerhedskopier, bedst når instansen er stoppet for at sikre konsistens
* (d) kan slettes
* (e) flygtige filer, kan slettes når instansen er stoppet
  {% endhint %}

1. `~/mongo_data` (b)
   * MongoDB-datamappe
2. `~/redis_data` (b)
   * Redis-db-datamappe
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * ubrugt i den seneste version, tidligere blev der brugt en brugerdefineret synctex-binær (synctex bruges til kildemapping mellem .tex-filer og pdf'en)
   2. data
      1. cache (e)
         * cache til binære filer til kompileringer
      2. kompileringer (e)
         * LaTeX-kompilering sker her
      3. db.sqlite (d)
         * ubrugt i den seneste version, tidligere blev CLSI-cacheoplysninger gemt her (enten flyttet til simple kort i hukommelsen, eller også scanner vi disken)
      4. db.sqlite-wal (d)
         * ubrugt i den seneste version, se db.sqlite
      5. output (e)
         * lagring af LaTeX-kompileringens output til levering til klienten
      6. template\_files (b)
         * billedforhåndsvisninger af skabelonsystemet (kun Server Pro)
      7. user\_files (b)
         * projekternes binære filer
      8. history (b)
         * filer med fuld projekthistorik
   3. tmp
      1. dumpFolder (e)
         * midlertidige filer fra håndtering af zip-filer
      2. uploads (e)
         * buffering af filuploads (upload af binær fil/nyt-projekt-fra-zip)
      3. projectHistories (e)
         * midlertidige filer til migreringer af fuld projekthistorik


---

# 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/da/vedligeholdelse/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.