> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Dati e backup

A volte, con l'evoluzione di Overleaf, è necessario modificare lo schema dei dati nel database; per automatizzare questo processo si usano script di migrazione. Questi vengono eseguiti prima su [overleaf.com](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit), la più grande istanza di Overleaf al mondo, quindi la maggior parte delle eventualità sarà già stata riscontrata; tuttavia non offriamo alcuna garanzia sui tuoi dati. Assicurati di creare un backup **coerente** dei tuoi dati **prima** di aggiornare la tua istanza.

<Info>
  Quando esegui l'aggiornamento a una nuova immagine Docker, tutte le migrazioni **non** ancora eseguite verranno eseguite automaticamente; l'operazione può richiedere del tempo a seconda delle dimensioni del tuo set di dati e seguendo i log potrai monitorarne l'avanzamento. Per maggiori informazioni, consulta la nostra documentazione sul [Logging](https://docs.overleaf.com/on-premises/configuration/overleaf-toolkit/logging).
</Info>

### Archiviazione dei dati

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

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

<Info>
  Potrebbe trattarsi di `~/sharelatex_data` o `~/overleaf_data`, a seconda di quando è stata configurata la tua istanza.
</Info>

<Check>
  Per i file di progetto e i dati della cronologia completa dei progetti supportiamo anche backend di archiviazione compatibili con S3.
</Check>

Consulta Cartelle in dettaglio per maggiori informazioni sulla struttura delle cartelle su disco.

### Eseguire un backup coerente

Per eseguire un backup coerente è necessario includere tre archivi:

* MongoDB
* Redis
* Dati del filesystem di Overleaf

Per ottenere un backup coerente è **obbligatorio** impedire agli utenti di produrre nuovi dati durante il processo di backup. Consigliamo quindi 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 usi una distribuzione con il Toolkit, oppure `docker compose stop sharelatex` se usi Docker Compose.

Una volta arrestato il container `sharelatex`, puoi avviare il processo di backup.

Una volta completato **correttamente** il processo di backup, dovrai avviare il container `sharelatex`. Per farlo esegui `bin/docker-compose start sharelatex` se usi una distribuzione con il Toolkit, oppure `docker compose start sharelatex` se usi Docker Compose.

<Danger>
  * I backup dovrebbero essere conservati su un server diverso da quello su cui è in esecuzione la tua istanza di Overleaf, idealmente in una sede completamente diversa.
  * Replicare i database su più istanze di MongoDB può offrire una certa ridondanza, ma non protegge dalla corruzione dei dati.
  * Testare i backup è il modo migliore per assicurarsi che siano completi e funzionanti.
</Danger>

### 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 memorizzati nel database.

### Dati del filesystem di Overleaf

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

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

### Redis

Redis memorizza le sessioni degli utenti e gli aggiornamenti dei documenti in sospeso prima che vengano scritti su MongoDB.

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

Per gli utenti del Toolkit la persistenza AOF è abilitata per impostazione predefinita nelle **nuove** installazioni; gli utenti esistenti possono trovare maggiori informazioni sull'abilitazione di AOF [qui](/it/on-premises/configuration/overleaf-toolkit/redis#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.

### Migrare i dati tra server

Idealmente, la nuova istanza non contiene ancora dati di valore. Non disponiamo di un processo per unire i dati di più istanze.

Supponendo che la nuova istanza non contenga ancora dati, ecco alcuni passaggi che puoi seguire. In sintesi, si crea un archivio tar dei volumi `mongo`, `redis` e `overleaf`, lo si copia sul nuovo server e lo si estrae nuovamente lì.

#### Toolkit

```bash theme={null}
# Gracefully shutdown the old instance
old-server$ bin/stop

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar config/ data/

# Copy the backup-old-server.tar file from the old-server to the
# new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ bin/stop

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv config/ data/ backup-new-server/

# Populate config/data dir again
new-server$ tar --extract --file backup-old-server.tar

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

#### Docker Compose

```bash wrap theme={null}
# Gracefully shutdown the old instance
old-server$ docker stop sharelatex
old-server$ docker stop mongo redis

# Create the tar-ball
old-server$ tar --create --file backup-old-server.tar ~/OVERLEAF_data ~/mongo_data ~/redis_data

# Copy the backup-old-server.tar file from the old-server to
# the new-server using any method that fits

# Gracefully shutdown new instance (if started yet)
new-server$ docker stop sharelatex
new-server$ docker stop mongo redis

# Move new data, you can delete it too
new-server$ mkdir backup-new-server
new-server$ mv ~/OVERLEAF_data ~/mongo_data ~/redis_data backup-new-server/

# Populate data dirs again
new-server$ tar --extract --file backup-old-server.tar

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

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

<Info>
  Quando viene eseguito come utente root (o con sudo), tar conserva proprietario/gruppo e permessi dei file, aspetto fondamentale durante il ripristino del backup.
</Info>

### Cartelle in dettaglio

<Info>
  Le cartelle seguenti sono contrassegnate da indicazioni aggiuntive:

  * (b) da includere nei backup, preferibilmente con l'istanza arrestata per garantire la coerenza
  * (d) può essere eliminata
  * (e) file temporanei, possono essere eliminati quando l'istanza è arrestata
</Info>

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.