Données et sauvegardes

Il arrive que nous devions modifier le schéma des données de la base au fil de l’évolution d’Overleaf ; des scripts de migration servent à automatiser ce processus. Ils auront d’abord été exécutés sur overleaf.com, la plus grande instance d’Overleaf au monde, de sorte que la plupart des cas de figure auront déjà été rencontrés ; nous n’offrons toutefois aucune garantie quant à vos données. Veillez à effectuer une sauvegarde cohérente de vos données avant de mettre à niveau votre instance.

Lors de la mise à niveau vers une nouvelle image Docker, toutes les migrations qui n’ont pas encore été exécutées le seront automatiquement. Cela peut prendre un certain temps selon la taille de vos données ; suivre les journaux vous permettra de connaître la progression. Pour plus d’informations, consultez notre documentation sur la journalisation.

​

Stockage des données

Overleaf Community Edition et Server Pro stockent leurs données à trois endroits distincts :

• Base de données MongoDB : c’est là que résident les données des utilisateurs et des projets.
• Redis : sert de cache haute performance pour les données en cours de traitement, en stockant principalement les informations liées aux modifications des projets et à la collaboration.
• Système de fichiers Overleaf : stocke les fichiers de projet non modifiables (y compris les images) et sert également de cache disque temporaire lors des compilations.

Il peut s’agir de ~/sharelatex_data ou de ~/overleaf_data, selon la date de mise en place de votre instance.

Pour les fichiers de projet et les données d’historique complet des projets, nous prenons également en charge les backends de stockage compatibles S3.

Consultez la section « Dossiers en détail » pour plus d’informations sur l’organisation des dossiers sur le disque.

​

Effectuer une sauvegarde cohérente

Trois stockages doivent être inclus pour réaliser une sauvegarde cohérente :

• MongoDB
• Redis
• Les données du système de fichiers Overleaf

Pour obtenir une sauvegarde cohérente, il est impératif d’empêcher les utilisateurs de produire de nouvelles données pendant la sauvegarde. Nous vous conseillons donc de planifier une fenêtre de maintenance pendant laquelle les utilisateurs ne pourront ni accéder à l’instance ni modifier leurs projets.

Avant de lancer la sauvegarde, vous devez mettre votre instance hors ligne. À partir de Server Pro 3.5.0, le processus d’arrêt automatise la fermeture du site et la déconnexion des utilisateurs.

Pour arrêter votre instance, exécutez bin/docker-compose stop sharelatex si vous utilisez un déploiement Toolkit, ou docker compose stop sharelatex si vous utilisez Docker Compose.

Une fois le conteneur sharelatex arrêté, vous pouvez lancer la sauvegarde.

Une fois la sauvegarde terminée avec succès, vous devez redémarrer le conteneur sharelatex. Pour cela, exécutez bin/docker-compose start sharelatex si vous utilisez un déploiement Toolkit, ou docker compose start sharelatex si vous utilisez Docker Compose.

• Les sauvegardes doivent être stockées sur un serveur distinct de celui qui exécute votre instance Overleaf, idéalement dans un tout autre emplacement.
• Répliquer les bases de données sur plusieurs instances MongoDB peut offrir une certaine redondance, mais ne protège pas contre la corruption.
• Tester vos sauvegardes est le meilleur moyen de vous assurer qu’elles sont complètes et fonctionnelles.

​

MongoDB

MongoDB est fourni avec un outil en ligne de commande appelé mongodump, qui permet de sauvegarder les données des utilisateurs et des projets stockées dans la base.

​

Données du système de fichiers Overleaf

Pour les déploiements Toolkit, le chemin de stockage de vos fichiers non modifiables est défini dans config/overleaf.rc via la variable d’environnement OVERLEAF_DATA_PATH ; selon la date de création de votre instance, il peut toutefois s’agir de data/sharelatex.

Il est nécessaire d’utiliser un outil tel que rsync pour copier récursivement ce répertoire afin d’obtenir une sauvegarde complète.

​

Redis

Redis stocke les sessions des utilisateurs et les mises à jour de documents en attente avant leur écriture dans MongoDB.

La persistance Append Only File (AOF) est la configuration recommandée pour Redis.

La persistance AOF est activée par défaut pour les nouvelles installations Toolkit ; les utilisateurs existants trouveront plus d’informations sur l’activation de l’AOF ici.

Si vous décidez de continuer à utiliser les instantanés RDB en plus de la persistance AOF, vous pouvez copier le fichier RDB dans un emplacement sûr à titre de sauvegarde.

​

Migrer des données entre serveurs

Idéalement, la nouvelle instance ne contient encore aucune donnée importante. Nous ne disposons d’aucune procédure pour fusionner les données de plusieurs instances.

En supposant que la nouvelle instance ne contienne encore aucune donnée, voici les étapes que vous pouvez suivre. Dans les grandes lignes, on crée une archive tar des volumes mongo, redis et overleaf, on la copie sur le nouveau serveur, puis on l’y décompresse.

​

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

Selon votre fichier docker-compose.yml, vous devrez peut-être ajuster les chemins des volumes mongo, redis et overleaf.

Lorsqu’il est exécuté en tant que root (ou avec sudo), tar conserve le propriétaire, le groupe et les permissions des fichiers, ce qui est essentiel lors de la restauration de la sauvegarde.

​

Dossiers en détail

Les dossiers suivants sont accompagnés d’indications supplémentaires :

• (b) à inclure dans les sauvegardes, de préférence lorsque l’instance est arrêtée pour garantir la cohérence
• (d) peut être supprimé
• (e) fichiers éphémères, peuvent être supprimés lorsque l’instance est arrêtée

1. ~/mongo_data (b)
   • répertoire de données de MongoDB
2. ~/redis_data (b)
   • répertoire de données de la base Redis
3. ~/overleaf_data
   1. bin
      1. synctex (d)
         • inutilisé dans la dernière version ; auparavant, un binaire synctex personnalisé était utilisé (synctex sert à la correspondance des sources entre les fichiers .tex et le PDF)
   2. data
      1. cache (e)
         • cache des fichiers binaires pour les compilations
      2. compiles (e)
         • c’est ici qu’a lieu la compilation LaTeX
      3. db.sqlite (d)
         • inutilisé dans la dernière version ; stockait auparavant les détails du cache clsi (désormais remplacé par de simples tables en mémoire ou par un parcours du disque)
      4. db.sqlite-wal (d)
         • inutilisé dans la dernière version, voir db.sqlite
      5. output (e)
         • stockage des résultats de compilation LaTeX servis au client
      6. template_files (b)
         • aperçus d’images du système de modèles (Server Pro uniquement)
      7. user_files (b)
         • fichiers binaires des projets
      8. history (b)
         • fichiers de l’historique complet des projets
   3. tmp
      1. dumpFolder (e)
         • fichiers temporaires issus du traitement des fichiers zip
      2. uploads (e)
         • mise en mémoire tampon des fichiers téléversés (fichier binaire / nouveau projet à partir d’un zip)
      3. projectHistories (e)
         • fichiers temporaires pour les migrations de l’historique complet des projets