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

# Data og sikkerhedskopier

Nogle gange er vi nødt til at ændre datastrukturen i databasen, efterhånden som Overleaf udvikler sig. 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 allerede vil være blevet stødt på, men vi giver ingen garantier for dine data. Sørg venligst for, at du opretter en **konsekvent** sikkerhedskopi af dine data **før** opgraderer din instans.

{% hint style="info" %}
Når du opgraderer til et nyt Docker-image, vil eventuelle migreringer, som er **ikke** endnu ikke er blevet kørt, blive udført automatisk. Dette kan tage noget tid afhængigt af størrelsen på dit datasæt, og at følge loggene vil vise dig fremskridtet. For mere information, se vores [Logning](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 projektdataene ligger.
* **Redis:** fungerer som en højtydende cache til data under behandling og gemmer primært oplysninger relateret til projektredigering og samarbejde.
* **Overleaf-filsystem:** gemmer ikke-redigerbare projektfiler (inklusive billeder) og fungerer også som en midlertidig diskcache under projektkompileringer.

{% hint style="info" %}
Dette 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 fuld projekt-historikdata 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 inkluderes, når man tager en konsistent sikkerhedskopi:

* MongoDB
* Redis
* data fra Overleaf-filsystemet

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

Før du starter sikkerhedskopieringsprocessen, skal du tage din instans offline. Begyndende med Server Pro `3.5.0` nedlukningsprocessen automatiserer lukningen af siden og frakoblingen af brugerne.

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

Når først `sharelatex` containeren er blevet stoppet, kan du starte sikkerhedskopieringsprocessen.

Når sikkerhedskopieringsprocessen er blevet gennemført **med succes** 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-udrulning 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 på tværs af flere MongoDB-instanser kan give en vis redundans, men det beskytter ikke mod datakorruption.
* 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 projektdata, der er gemt i databasen.

### data fra Overleaf-filsystemet

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

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

### Redis

Redis gemmer brugersessioner og afventende dokumentopdateringer, før de sendes 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 kan eksisterende brugere finde flere oplysninger om at aktivere 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 en sikker placering som sikkerhedskopi.

### Migrering af data mellem servere

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

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

#### Toolkit

```bash
# Luk den gamle instans ned skånsomt
old-server$ bin/stop

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

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

# Luk den nye instans ned skånsomt (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 containere
new-server$ bin/up
```

#### Docker Compose

```bash
# Luk den gamle instans ned skånsomt
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Opret tar-ballen
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
# new-server ved hjælp af en hvilken som helst metode, der passer

# Luk den nye instans ned skånsomt (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 containere
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 de `mongo`, `redis`, `overleaf` volumenerne.

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

### Mapper i detaljer

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

* (b) skal inkluderes 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-datamappe
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * ikke brugt i den seneste udgivelse, tidligere blev der brugt en brugerdefineret synctex-binærfil (synctex bruges til kildekortlægning mellem .tex-filer og pdf'en)
   2. data
      1. cache (e)
         * binær filcache til kompileringer
      2. kompileringer (e)
         * her foregår LaTeX-kompilering
      3. db.sqlite (d)
         * ikke brugt i den seneste udgivelse, tidligere blev clsi-cacheoplysninger gemt (enten er de flyttet til simple hukommelseskort, eller også scanner vi disken)
      4. db.sqlite-wal (d)
         * ikke brugt i den seneste udgivelse, se db.sqlite
      5. uddata (e)
         * lager til LaTeX-kompileringsoutput til levering til klienten
      6. skabelonfiler (b)
         * billedforhåndsvisninger af skabelonsystemet (kun Server Pro)
      7. brugerfiler (b)
         * binære filer i projekter
      8. historik (b)
         * filer med fuld projekt-historik
   3. tmp
      1. dumpMappe (e)
         * midlertidige filer fra håndtering af zip-filer
      2. uploads (e)
         * mellemlagring af filoverførsler (binær fil/nyt projekt fra zip-upload)
      3. projekthistorikker (e)
         * midlertidige filer til migrering af fuld projekt-historik


---

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