> 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/sv/underhall/data-and-backups.md).

# Data och säkerhetskopior

Ibland behöver vi ändra databasens schema i databasen i takt med att vi utvecklar Overleaf. Migreringsskript används för att automatisera denna process. De kommer att ha körts på [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) först, vilket är den största Overleaf-instansen i världen, så de flesta eventualiteter har redan stötts på, men vi lämnar inga garantier för dina data. Se till att du skapar en **konsistent** säkerhetskopia av dina data **innan** när du uppgraderar din instans.

{% hint style="info" %}
När du uppgraderar till en ny Docker-avbildning kommer alla migreringar som **inte** ännu inte har körts att köras automatiskt. Detta kan ta lite tid beroende på storleken på din datamängd, och om du följer loggarna ser du förloppet. För mer information, se vår [Loggning](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) dokumentationen.
{% endhint %}

### Datalagring

Overleaf Community Edition och Server Pro lagrar sina data på tre separata platser:

* **MongoDB-databas:** Det är här användar- och projektdata finns.
* **Redis:** fungerar som en högpresterande cache för data som är under behandling och lagrar främst information som rör projektredigeringar och samarbete.
* **Overleafs filsystem:** lagrar icke-redigerbara projektfiler (inklusive bilder) och fungerar också som en tillfällig diskcache under projektkompileringar.

{% hint style="info" %}
Detta kan vara `~/sharelatex_data` eller `~/overleaf_data`, beroende på när din instans sattes upp.
{% endhint %}

{% hint style="success" %}
För projektfiler och fullständig projekthistorik stöder vi även S3-kompatibla lagringsbackend-system.
{% endhint %}

Se Mappar i detalj för mer information om mappstrukturen på disken.

### Utföra en konsistent säkerhetskopia

Det finns tre lagringsplatser som behöver ingå när man gör en konsistent säkerhetskopia:

* MongoDB
* Redis
* Overleaf-filsystemdata

För att skapa en konsistent säkerhetskopia är det **obligatoriskt** att hindra användare från att skapa nya data medan säkerhetskopieringsprocessen körs. Vi rekommenderar därför att du schemalägger ett underhållsfönster under vilket användarna inte ska kunna komma åt instansen eller redigera sina projekt.

Innan du startar säkerhetskopieringsprocessen måste du ta din instans offline. Med Server Pro `3.5.0` automatiserar avstängningsprocessen stängningen av webbplatsen och frånkopplingen av användare.

För att stänga av din instans behöver du köra `bin/docker-compose stop sharelatex` om du kör en Toolkit-installation eller `docker compose stop sharelatex` om du kör Docker Compose.

När `sharelatex` containern har stoppats kan du starta säkerhetskopieringsprocessen.

När säkerhetskopieringsprocessen har slutförts **framgångsrikt** måste du starta `sharelatex` containern igen. För att göra detta kör `bin/docker-compose start sharelatex` om du kör en Toolkit-installation eller `docker compose start sharelatex` om du kör Docker Compose.

{% hint style="danger" %}

* Säkerhetskopior bör lagras på en separat server från den som din Overleaf-instans körs på, helst på en helt annan plats.
* Att replikera databaser till flera MongoDB-instanser kan ge viss redundans, men det skyddar inte mot korruption.
* Att testa dina säkerhetskopior är det bästa sättet att säkerställa att de är kompletta och fungerar.
  {% endhint %}

### MongoDB

MongoDB levereras med ett kommandoradsverktyg som heter [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) som kan användas för att skapa en säkerhetskopia av användar- och projektdata som lagras i databasen.

### Overleaf-filsystemdata

För Toolkit-installationer anges sökvägen där dina icke-redigerbara filer lagras i `config/overleaf.rc` med hjälp av `OVERLEAF_DATA_PATH` miljövariabeln, men beroende på när din instans skapades kan detta vara `data/sharelatex`.

Att använda ett verktyg som **rsync** för att rekursivt kopiera denna katalog krävs för att säkerställa att en fullständig säkerhetskopia skapas.

### Redis

Redis lagrar användarsessioner och väntande dokumentuppdateringar innan de töms till MongoDB.

Append Only File (AOF)-persistens är den rekommenderade konfigurationen för Redis-persistens.

Toolkit-användare har AOF-persistens aktiverat som standard för **nya** installationer. Befintliga användare kan hitta mer information om hur man aktiverar AOF [här](/on-premises/sv/konfiguration/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

Om du väljer att fortsätta använda RDB-snapshots tillsammans med AOF-persistens kan du kopiera RDB-filen till en säker plats som en säkerhetskopia.

### Migrera data mellan servrar

I bästa fall har du ännu inga värdefulla data i den nya instansen. Vi har ingen process för att slå samman instansers data.

Om vi antar att den nya instansen ännu inte har några data, här är några steg du kan följa. På hög nivå skapar vi ett tar-arkiv av `mongo`, `redis` och `overleaf` volymerna, kopierar det till den nya servern och packar upp det där igen.

#### Toolkit

```bash
# Stäng den gamla instansen på ett korrekt sätt
old-server$ bin/stop

# Skapa tar-arkivet
old-server$ tar --create --file backup-old-server.tar config/ data/

# Kopiera filen backup-old-server.tar från old-server till
# new-server med valfri metod som passar

# Stäng den nya instansen på ett korrekt sätt (om den redan har startats)
new-server$ bin/stop

# Flytta de nya data, du kan också ta bort dem
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

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

# Starta containrarna
new-server$ bin/up
```

#### Docker Compose

```bash
# Stäng den gamla instansen på ett korrekt sätt
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Skapa tar-arkivet
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Kopiera filen backup-old-server.tar från old-server till
# new-server med valfri metod som passar

# Stäng den nya instansen på ett korrekt sätt (om den redan har startats)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Flytta de nya data, du kan också ta bort dem
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Fyll på datakatalogerna igen
new-server$ tar --extract --file backup-old-server.tar

# Starta containrarna
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

Beroende på din **docker-compose.yml** fil kan du behöva justera sökvägarna för `mongo`, `redis`, `overleaf` volymerna.

{% hint style="info" %}
När du kör som root-användare (eller med sudo) behåller tar filens ägare/grupp och behörigheter, vilket är avgörande när säkerhetskopian återställs.
{% endhint %}

### Mappar i detalj

{% hint style="info" %}
Följande mappar har ytterligare förklaringar:

* (b) ingår i säkerhetskopior, bäst när instansen är stoppad för att säkerställa konsistens
* (d) kan raderas
* (e) tillfälliga filer, kan raderas när instansen är stoppad
  {% endhint %}

1. `~/mongo_data` (b)
   * mongodb-datakatalog
2. `~/redis_data` (b)
   * redis db-datakatalog
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * används inte i den senaste versionen, tidigare användes en anpassad synctex-binärfil (synctex används för källmappning mellan .tex-filer och pdf:en)
   2. data
      1. cache (e)
         * binär filcache för kompileringar
      2. kompileringar (e)
         * latex-kompileringen sker här
      3. db.sqlite (d)
         * används inte i den senaste versionen, lagrade tidigare detaljer om clsi-cachen (antingen har de flyttats till enkla minnesbaserade mappar eller så skannar vi disken)
      4. db.sqlite-wal (d)
         * används inte i den senaste versionen, se db.sqlite
      5. output (e)
         * lagring av latex-kompileringsutdata för leverans till klienten
      6. template\_files (b)
         * förhandsvisningar av mallfilssystemets bilder (endast Server Pro)
      7. user\_files (b)
         * projektens binärfiler
      8. history (b)
         * fullständiga projektets historikfiler
   3. tmp
      1. dumpFolder (e)
         * tillfälliga filer från hantering av zip-filer
      2. uploads (e)
         * buffring av filuppladdningar (binär fil/nytt-projekt-från-zip-uppladdning)
      3. projectHistories (e)
         * tillfälliga filer för migreringar av fullständig 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/sv/underhall/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.
