> 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/it/supporto/support-guides/full-project-history-migration.md).

# (Migrazione v3.5.13) Migrazione della cronologia completa del progetto

## Migrazione completa della cronologia del progetto

Il `3.5.x` il rilascio della Community Edition include la [funzionalità Full Project History](https://www.overleaf.com/learn/latex/Using_the_History_feature) che è già disponibile nella nostra offerta SaaS, [overleaf.com](http://overleaf.com/)

Dopo aver aggiornato la tua istanza a Overleaf CE `3.5.13`, tutti i nuovi progetti useranno Full Project History per impostazione predefinita. I progetti esistenti continueranno a usare il sistema History legacy, finché non saranno migrati.

{% hint style="info" %}
Se aggiorni a `3.5.13` e decidi di eseguire il downgrade a una versione precedente, allora dovresti ripristinare da un backup completo del sistema. La cronologia dei progetti creati in `3.5.13` non è compatibile con le versioni precedenti di Overleaf CE.
{% endhint %}

La nuova Full Project History apporta diversi miglioramenti per gli utenti:

* Tiene traccia delle modifiche nei file binari, cosa non supportata nel sistema legacy.
* È supportato l'uso di versioni con etichetta.
* Il sistema è in generale più robusto, c'è meno rischio di perdita di dati.

Consulta [la documentazione di Full Project History](https://www.overleaf.com/learn/latex/Using_the_History_feature) per ulteriori informazioni sulla cronologia completa del progetto.

### Migrazione dei progetti esistenti

{% stepper %}
{% step %}

#### Crea un backup

Crea un [backup](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) completo della tua istanza con uno snapshot coerente delle **mongo**, **redis** e **sharelatex** directory.
{% endstep %}

{% step %}

#### Aggiorna

Aggiorna la versione dell'immagine sharelatex/sharelatex alla 3.5.13.

Toolkit: usa il `$ bin/upgrade` script per aggiornare il toolkit all'ultima versione e modifica **config/version** a 3.5.13.
{% endstep %}

{% step %}

#### Avvia l'istanza

Idealmente, vorresti impedire agli utenti di accedere alla tua istanza mentre la migrazione è in corso, per evitare la perdita di dati nel caso in cui tu debba ripristinare il backup. Vedi [Migrazione offline](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) per ulteriori informazioni su come farlo.
{% endstep %}

{% step %}

#### Attendi finché tutti i servizi non sono avviati e in esecuzione

Attendi finché tutti i servizi non sono avviati e in esecuzione (vedi il comando qui sotto)

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status"
web sharelatex è attivo (api)%
```

{% endcode %}
{% endstep %}

{% step %}

#### Esegui lo script di migrazione

{% code overflow="wrap" %}

```bash
# Utenti di Overleaf Toolkit:
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"

# utenti legacy di docker-compose.yml:
$ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"
```

{% endcode %}

`--force-clean` elimina i dati della cronologia dei progetti parzialmente migrati nel nuovo sistema; questo consente di riprovare la migrazione per singoli progetti che erano falliti nei tentativi precedenti;

`--fix-invalid-characters` sostituisce i caratteri non stampabili che non sono supportati dal nuovo sistema di cronologia;

`--convert-large-docs-to-file` converte i documenti che superano la soglia di dimensione modificabile di 2 MB in un file non modificabile)

L'output dovrebbe essere simile a questo:

```bash
Progetti migrati  :  1
Progetti totali     :  51
Progetti rimanenti :  51
Record di cronologia totali da migrare: 98
Avvio della migrazione...
Migrazione del progetto: 63d29b5772dd80015a81bffe
risultato della migrazione { upgraded: true, historyType: 'NoneWithoutConversion' }
Migrazione del progetto: 63d29c2e72dd80015a81c0a2
risultato della migrazione { upgraded: true, historyType: 'NoneWithoutConversion' }

// …

Migrazione completata
==================
Progetti migrati:  51
Progetti falliti:  0
Fatto.
```

Se la migrazione ha successo, otterrai un codice di uscita pari a `0`, e le ultime righe indicheranno che non ci sono stati fallimenti:

```bash
Progetti falliti:  0
Fatto.
```

Puoi riaprire l'accesso ai tuoi utenti (vedi il passaggio successivo). Se ci sono fallimenti, consulta la sezione di risoluzione dei problemi qui sotto. Puoi comunque riaprire il sito se i problemi non vengono risolti immediatamente, e i progetti non migrati rimarranno sul sistema legacy di cronologia.
{% endstep %}

{% step %}

#### Riapri il sito

Se avevi scelto di eseguire una migrazione offline, dovrai riaprire il sito. Se sei ancora connesso dovrai:

1. Fai clic su **Amministratore** pulsante e scegli **Gestisci sito**
2. Fai clic sul **Apri/chiudi editor** scheda
3. Fai clic sul **Riapri editor** pulsante

Se hai chiuso il browser, dovrai riavviare il sito con `$ bin/up`.
{% endstep %}
{% endstepper %}

#### Migrazione offline

Per impedire agli utenti di accedere mentre lo script di migrazione della cronologia è in esecuzione, segui questi passaggi:

* Accedi alla tua istanza Overleaf con un account amministratore
* Fai clic su **Amministratore** pulsante e scegli **Gestisci sito**
* Fai clic sul **Apri/chiudi editor** scheda
* Fai clic su **Chiudi editor** pulsante
* Fai clic su **Disconnetti tutti gli utenti** pulsante

Una volta fatto questo, se ci sono utenti connessi verranno reindirizzati alla pagina di manutenzione, e qualsiasi nuovo utente che visiti la pagina di accesso vedrà la pagina di manutenzione e **non** potrà accedere.

#### Migrazione online

È possibile eseguire gli script di migrazione mentre l'applicazione è ancora in esecuzione. Ci sono alcune considerazioni da tenere presenti:

* Il processo di migrazione è intensivo in termini di CPU; dovresti monitorare l'utilizzo delle risorse mentre lo script è in esecuzione.
* Con un `--concurrency` valore elevato, l'event loop in alcuni servizi (`track-changes` in particolare) potrebbe subire alcuni blocchi, il che porterebbe a un'esperienza UX degradata. Consigliamo di iniziare con il valore predefinito `--concurrency=1` valore.
* Puoi interrompere lo script in qualsiasi momento. Riavviarlo riprenderà la migrazione dal punto in cui l'avevi lasciata. Questo è utile nel caso in cui preferisca eseguire la migrazione nelle ore meno trafficate (ad esempio di notte).

La nostra raccomandazione è di chiudere il sito ed eseguire la migrazione offline in una finestra di manutenzione quando il numero dei tuoi progetti è inferiore a 1000 progetti (`db.projects.count()`). Se il numero di progetti è elevato, puoi eseguire lo script e monitorarne l'avanzamento, quindi decidere se continuare a eseguirlo online o offline in base al tuo caso specifico.

#### Pulisci i dati della cronologia legacy

Uno script per ripulire i dati della cronologia legacy è stato aggiunto in Server Pro `3.5.6`, `4.0.6` e `4.1.0`.

{% code overflow="wrap" %}

```bash
bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/history/clean_sl_history_data.js"
```

{% endcode %}

Lo script può essere eseguito dopo che tutti i progetti sono stati migrati. Può anche essere usato per liberare un po' di spazio durante l'esecuzione di una migrazione online.

{% hint style="info" %}
In Server Pro prima della versione 3.5.13, lo script elimina il contenuto di `docHistory` e `docHistoryIndex` collezioni. MongoDB non libera spazio su disco dopo l'eliminazione dei documenti; invece, riutilizzerà quello spazio per documenti futuri nella stessa collezione. Nulla scriverà di nuovo in queste collezioni dopo la migrazione della cronologia, quindi lo spazio su disco rimarrà inutilizzato.

Se vuoi rendere nuovamente disponibile lo spazio su disco, puoi aggiornare a Server Pro 3.5.13 (quando usi ancora la release 3.x) oppure a Server Pro 4.2.5 (quando usi la release 4.x) ed eseguire di nuovo lo script di pulizia.

Lo script di pulizia incluso in Server Pro nelle ultime release patch di `3.5.x` e le ultime `4.x.x` eliminano le collezioni come passaggio finale.

È sicuro rieseguire lo script di pulizia.
{% endhint %}

### Risoluzione dei problemi

Aggiungeremo qui i consigli per la risoluzione dei problemi. Tieni presente che, sebbene di norma offriamo supporto solo ai clienti Server Pro, data la natura di questa migrazione, faremo anche il possibile per supportare i clienti CE che riscontrano problemi specifici della migrazione completa della cronologia del progetto.

Se lo script di migrazione della cronologia completa del progetto fallisce (cioè termina con un errore o stampa un numero diverso da zero di progetti falliti), invia i seguenti dettagli al nostro team di supporto via email [support+historymigration@overleaf.com](mailto:support+historymigration@overleaf.com?subject=Full%20project%20history%20migration%20problem\&body=Instance%20Type%3A%20CE%20or%20Server%20Pro%20%28delete%20as%20appropriate%29%0A%0AInstallation%20Type%3A%20Overleaf%20toolkit%20or%20docker-compose.yml%20or%20other%20%28delete%20as%20appropriate%29%0A%0AScript%20output%3A%0A%0Abin%2Fdoctor%20output%20%28if%20using%20toolkit%29%3A%0A), specificando:

Oggetto: problema di migrazione della cronologia completa del progetto

* Tipo di istanza: CE o Server Pro (elimina se appropriato)
* Tipo di installazione: Overleaf Toolkit o `docker-compose.yml` o altro (elimina se appropriato)
* Versione: 3.5.x (Toolkit: `$ cat config/version`)
* Output dello script di migrazione (che dovrebbe trovarsi nel container in `/overleaf/services/web`)
* Progetti migrati: (come da output dello script di migrazione)
* Progetti totali: (come da output dello script di migrazione)
* Progetti rimanenti: (come da output dello script di migrazione)
* Durata della migrazione:
* `bin/doctor` output (quando si usa il Toolkit)
* Versione del Toolkit: `$ git rev-parse HEAD` (quando si usa il Toolkit)

Considera di allegare i file di log dei `history-v1`, `project-history` e `track-changes` servizi all'email. Puoi trovarli in `/var/log/sharelatex` all'interno del `sharelatex` container ed esportarli in questo modo:

```bash
$ docker cp sharelatex:/var/log/sharelatex/history-v1.log history-v1.log
$ docker cp sharelatex:/var/log/sharelatex/project-history.log project-history.log
$ docker cp sharelatex:/var/log/sharelatex/track-changes.log track-changes.log
```

Rimuovi qualsiasi informazione sensibile dai file di log prima di allegarli.

#### Individuare alberi di file danneggiati

La migrazione potrebbe fallire per progetti che hanno un albero dei file malformato (ad esempio, quando i nomi dei file sono vuoti). Puoi trovare un elenco di questi problemi usando lo `find_malformed_filetrees` script che controlla tutti i progetti nel database:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js"
PERCORSO ERRATO: 123456789012345678901234 rootFolder.0.1.2.3
PERCORSO ERRATO: 123456789012345678901234 rootFolder.0.4.5.6
...
```

{% endcode %}

Per correggere i percorsi non validi, usa lo `fix_malformed_filetree` script, eseguendo il comando una volta per ogni percorso errato:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.1.2.3"
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.4.5.6"
...
```

{% endcode %}

#### Downgrade dei progetti dalla cronologia completa del progetto alla cronologia legacy

Se c'è un progetto che è stato migrato alla cronologia completa del progetto ma vuoi tornare alla cronologia legacy, usa lo `downgrade_project` script come segue:

{% code overflow="wrap" %}

```bash
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=YOUR
```

{% endcode %}


---

# 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/it/supporto/support-guides/full-project-history-migration.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.
