> 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/it/manutenzione/data-and-backups.md).

# Dati e backup

A volte è necessario cambiare lo schema dei dati nel database man mano che Overleaf evolve; gli script di migrazione vengono usati per automatizzare questo processo. Saranno stati eseguiti su [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit) per primo, che è la più grande istanza di Overleaf al mondo, quindi la maggior parte delle eventualità sarà già stata incontrata; tuttavia, non forniamo alcuna garanzia sui tuoi dati. Assicurati di creare un **coerente** backup dei tuoi dati **prima di** durante l'aggiornamento della tua istanza.

{% hint style="info" %}
Quando si aggiorna a una nuova immagine Docker, eventuali migrazioni che sono **non** ancora da eseguire verranno eseguite automaticamente; ciò potrebbe richiedere del tempo a seconda delle dimensioni del tuo dataset, seguire i log ti mostrerà l'avanzamento. Per ulteriori informazioni, vedi il nostro [Log](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging) documentazione.
{% endhint %}

### Archiviazione dei dati

Overleaf Community Edition e Server Pro archiviano i propri dati in tre posizioni separate:

* **Database MongoDB:** Qui risiedono i dati degli utenti e dei progetti.
* **Redis:** funge da cache ad alte prestazioni per i dati in transito, memorizzando principalmente informazioni relative alle modifiche ai progetti e alla collaborazione.
* **Filesystem di Overleaf:** memorizza i file di progetto non modificabili (incluse le immagini) e funge anche da cache temporanea su disco durante le compilazioni dei progetti.

{% hint style="info" %}
Potrebbe essere `~/sharelatex_data` o `~/overleaf_data`, a seconda di quando è stata configurata la tua istanza.
{% endhint %}

{% hint style="success" %}
Per i file di progetto e per i dati completi della cronologia del progetto supportiamo anche backend di archiviazione compatibili con S3.
{% endhint %}

Vedi Cartelle in dettaglio per ulteriori informazioni sulla struttura delle cartelle su disco.

### Esecuzione di un backup coerente

Ci sono tre archivi che devono essere inclusi quando si esegue un backup coerente:

* MongoDB
* Redis
* Dati del filesystem di Overleaf

Per produrre un backup coerente è **obbligatorio** impedire agli utenti di produrre nuovi dati mentre il processo di backup è in esecuzione. Per questo motivo consigliamo di pianificare una finestra di manutenzione durante la quale gli utenti non possano accedere all'istanza né modificare i propri progetti.

Prima di avviare il processo di backup dovrai mettere offline la tua istanza. A partire da Server Pro `3.5.0` il processo di arresto automatizza la chiusura del sito e la disconnessione degli utenti.

Per arrestare la tua istanza dovrai eseguire `bin/docker-compose stop sharelatex` se stai eseguendo una distribuzione Toolkit oppure `docker compose stop sharelatex` se stai eseguendo Docker Compose.

Una volta che il `sharelatex` container è stato arrestato puoi avviare il processo di backup.

Una volta che il processo di backup è stato completato **con successo** dovrai avviare il `sharelatex` container. Per farlo esegui `bin/docker-compose start sharelatex` se stai eseguendo una distribuzione Toolkit oppure `docker compose start sharelatex` se stai eseguendo Docker Compose.

{% hint style="danger" %}

* I backup dovrebbero essere archiviati su un server separato da quello su cui è in esecuzione la tua istanza di Overleaf, idealmente in una posizione completamente diversa.
* Replicare i database su più istanze MongoDB potrebbe offrire una certa ridondanza, ma non protegge dalla corruzione.
* Testare i tuoi backup è il modo migliore per assicurarti che siano completi e funzionanti.
  {% endhint %}

### MongoDB

MongoDB include uno strumento da riga di comando chiamato [mongodump](https://docs.mongodb.com/manual/reference/program/mongodump/) che può essere usato per creare un backup dei dati degli utenti e dei progetti archiviati nel database.

### Dati del filesystem di Overleaf

Per le distribuzioni Toolkit, il percorso in cui sono archiviati i tuoi file non modificabili è specificato nella `config/overleaf.rc` usando il `OVERLEAF_DATA_PATH` variabile d'ambiente, ma, a seconda di quando è stata creata la tua istanza, potrebbe essere `data/sharelatex`.

Usare uno strumento come **rsync** per copiare ricorsivamente questa directory è necessario per garantire la creazione di un backup completo.

### Redis

Redis memorizza le sessioni utente e gli aggiornamenti dei documenti in sospeso prima che vengano trasferiti su MongoDB.

La persistenza Append Only File (AOF) è la configurazione consigliata per la persistenza di Redis.

Gli utenti di Toolkit hanno la persistenza AOF abilitata per impostazione predefinita per le **nuove** installazioni; gli utenti esistenti possono trovare ulteriori informazioni sull'abilitazione di AOF [qui](/on-premises/it/configurazione/overleaf-toolkit/redis.md#enabling-append-only-file-persistence).

Se decidi di continuare a usare gli snapshot RDB insieme alla persistenza AOF, puoi copiare il file RDB in una posizione sicura come backup.

### Migrazione dei dati tra server

Nel migliore dei casi, nella nuova istanza non hai ancora dati preziosi. Non abbiamo un processo per unire i dati delle istanze.

Supponendo che la nuova istanza non abbia ancora dati, ecco alcuni passaggi che potresti seguire. In linea generale, produciamo un archivio tar dei `mongo`, `redis` e `Overleaf` volumi, lo copiamo sul nuovo server e lo estraiamo di nuovo lì.

#### Toolkit

```bash
# Arresta in modo corretto la vecchia istanza
old-server$ bin/stop

# Crea l'archivio tar
old-server$ tar --create --file backup-old-server.tar config/ data/

# Copia il file backup-old-server.tar dal vecchio server al
# nuovo server usando qualsiasi metodo adatto

# Arresta in modo corretto la nuova istanza (se è già stata avviata)
new-server$ bin/stop

# Sposta i nuovi dati, puoi anche eliminarli
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# Popola di nuovo la directory config/data
new-server$ tar --extract --file backup-old-server.tar

# Avvia i container
new-server$ bin/up
```

#### Docker Compose

```bash
# Arresta in modo corretto la vecchia istanza
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Crea l'archivio tar
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Copia il file backup-old-server.tar dal vecchio server al
# nuovo server usando qualsiasi metodo adatto

# Arresta in modo corretto la nuova istanza (se è già stata avviata)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Sposta i nuovi dati, puoi anche eliminarli
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Popola di nuovo le directory dei dati
new-server$ tar --extract --file backup-old-server.tar

# Avvia i container
new-server$ docker start mongo redis
new-server$ docker start sharelatex
```

A seconda del tuo **docker-compose.yml** file, potrebbe essere necessario adattare i percorsi dei `mongo`, `redis`, `Overleaf` volumi.

{% hint style="info" %}
Quando viene eseguito come utente root (o con sudo), tar conserverà il proprietario/gruppo e i permessi del file, il che è fondamentale al momento del ripristino del backup.
{% endhint %}

### Cartelle in dettaglio

{% hint style="info" %}
Le cartelle seguenti hanno ulteriori indicazioni:

* (b) includere nei backup; meglio quando l'istanza è arrestata per garantirne la coerenza
* (d) può essere eliminata
* (e) file effimeri, possono essere eliminati quando l'istanza è arrestata
  {% endhint %}

1. `~/mongo_data` (b)
   * directory dati di mongodb
2. `~/redis_data` (b)
   * directory dati del database Redis
3. `~/overleaf_data`
   1. bin
      1. synctex (d)
         * non usato nell'ultima release, in precedenza veniva usato un binario synctex personalizzato (synctex viene usato per la mappatura tra i file .tex e il pdf)
   2. data
      1. cache (e)
         * cache di file binari per le compilazioni
      2. compilazioni (e)
         * qui avviene la compilazione LaTeX
      3. db.sqlite (d)
         * non usato nell'ultima release, in precedenza memorizzava i dettagli della cache clsi (sia spostati in semplici mappe in memoria sia scansionando il disco)
      4. db.sqlite-wal (d)
         * non usato nell'ultima release, vedi db.sqlite
      5. output (e)
         * archiviazione dell'output delle compilazioni LaTeX da servire al client
      6. template\_files (b)
         * anteprime immagini del sistema di template (solo Server Pro)
      7. user\_files (b)
         * file binari dei progetti
      8. history (b)
         * file completi della cronologia del progetto
   3. tmp
      1. dumpFolder (e)
         * file temporanei derivati dalla gestione dei file zip
      2. uploads (e)
         * buffering dei caricamenti dei file (caricamento di file binari/nuovo progetto da zip)
      3. projectHistories (e)
         * file temporanei per le migrazioni della cronologia completa del progetto


---

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