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, 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.

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.

​

Archiviazione dei dati

Overleaf Community Edition e Server Pro memorizzano 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 dei 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.

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

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

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.

• 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.

​

MongoDB

MongoDB include uno strumento da riga di comando chiamato 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.

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

# 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

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

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

​

Cartelle in dettaglio

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

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