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

# Data och säkerhetskopior

Ibland behöver vi ändra dataschemat i databasen när vi vidareutvecklar Overleaf, migrationsskript 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å. Vi lämnar dock 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 migrationer som har **inte** ännu inte har körts att köras automatiskt. Det kan ta lite tid beroende på storleken på din datamängd; om du följer loggarna kan du se 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 olika platser:

* **MongoDB-databas:** Här finns användar- och projektdata.
* **Redis:** fungerar som cache med hög prestanda för data under bearbetning 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 konfigurerades.
{% endhint %}

{% hint style="success" %}
För projektfiler och data om fullständig projekthistorik stöder vi också S3-kompatibla lagringsbackends.
{% endhint %}

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

### Att göra en konsistent säkerhetskopia

Det finns tre lagringsplatser som måste ingå när du tar en konsistent säkerhetskopia:

* MongoDB
* Redis
* data i Overleafs filsystem

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 planerar ett underhållsfönster under vilket användare inte ska kunna komma åt instansen eller redigera sina projekt.

Innan du startar säkerhetskopieringsprocessen måste du göra din instans offline. För Server Pro börjar `3.5.0` avstängningsprocessen automatiserar stängningen av webbplatsen och frånkopplingen av användare.

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

När `sharelatex` behållaren har stoppats kan du starta säkerhetskopieringsprocessen.

När säkerhetskopieringsprocessen har slutförts **framgångsrikt** behöver du starta `sharelatex` behållaren. Kör följande för att göra detta `bin/docker-compose start sharelatex` om du kör en Toolkit-distribution 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 där din Overleaf-instans körs, 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.

### data i Overleafs filsystem

För Toolkit-distributioner 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`.

Genom att använda ett verktyg som **rsync** för att rekursivt kopiera den här katalogen 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 skrivs till MongoDB.

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

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

Om du bestämmer dig för att fortsätta använda RDB-snapshots tillsammans med AOF-persistens kan du kopiera RDB-filen till en säker plats som 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 data från instanser.

Om vi antar att den nya instansen ännu inte har några data, här är några steg du kan följa. Övergripande skapar vi en tarball av `mongo`, `redis` och `overleaf` volymerna, kopierar den till den nya servern och packar upp den där igen.

#### Toolkit

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

# Skapa tarballen
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 ner den nya instansen på ett kontrollerat sätt (om den redan har startats)
new-server$ bin/stop

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

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

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

#### Docker Compose

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

# Skapa tarballen
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 ner den nya instansen på ett kontrollerat sätt (om den redan har startats)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Flytta 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 datakatalogerna igen
new-server$ tar --extract --file backup-old-server.tar

# Starta containrar
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 noteringar:

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

1. `~/mongo_data` (b)
   * mongodb:s datakatalog
2. `~/redis_data` (b)
   * redis db-datakatalog
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * oanvänd i den senaste versionen, tidigare användes en anpassad synctex-binär (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-kompilering sker här
      3. db.sqlite (d)
         * oanvänd i den senaste versionen, tidigare lagrades CLSI-cachedetaljer här (antingen har de flyttats till enkla minneskartor eller så genomsöker vi disken)
      4. db.sqlite-wal (d)
         * oanvänd i den senaste versionen, se db.sqlite
      5. output (e)
         * lagring av utdata från latex-kompilering för leverans till klienten
      6. template\_files (b)
         * bildförhandsvisningar av mallsystemet (endast Server Pro)
      7. user\_files (b)
         * binära filer för projekt
      8. historik (b)
         * filer för fullständig projekthistorik
   3. tmp
      1. dumpFolder (e)
         * tillfälliga filer från hantering av zip-filer
      2. uppladdningar (e)
         * buffring av filuppladdningar (binär fil/uppladdning av nytt projekt från zip)
      3. projectHistories (e)
         * tillfälliga filer för migrationer 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://ayakaleaf-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.