Gegevens en back-ups

Soms moeten we, naarmate Overleaf zich ontwikkelt, het schema van de gegevens in de database wijzigen; migratiescripts worden gebruikt om dit proces te automatiseren. Deze zijn eerst uitgevoerd op overleaf.com, de grootste Overleaf-instantie ter wereld, dus de meeste situaties zijn daar al voorgekomen. We geven echter geen garanties voor uw gegevens. Zorg ervoor dat u vóór het upgraden van uw instantie een consistente back-up van uw gegevens maakt.

Bij het upgraden naar een nieuwe Docker-image worden alle migraties die nog niet zijn uitgevoerd automatisch uitgevoerd. Dit kan enige tijd duren, afhankelijk van de grootte van uw dataset; door de logs te volgen ziet u de voortgang. Zie voor meer informatie onze documentatie over Logging.

​

Gegevensopslag

Overleaf Community Edition en Server Pro slaan hun gegevens op drie afzonderlijke plaatsen op:

• MongoDB-database: hier bevinden zich de gebruikers- en projectgegevens.
• Redis: dient als krachtige cache voor gegevens die in behandeling zijn, en slaat voornamelijk informatie op over projectbewerkingen en samenwerking.
• Overleaf-bestandssysteem: slaat niet-bewerkbare projectbestanden op (inclusief afbeeldingen) en fungeert ook als tijdelijke schijfcache tijdens projectcompilaties.

Dit kan ~/sharelatex_data of ~/overleaf_data zijn, afhankelijk van wanneer uw instantie is ingericht.

Voor projectbestanden en de volledige projectgeschiedenis ondersteunen we ook S3-compatibele opslagbackends.

Zie Mappen in detail voor meer informatie over de mappenstructuur op schijf.

​

Een consistente back-up maken

Er zijn drie opslagplaatsen die moeten worden meegenomen bij het maken van een consistente back-up:

• MongoDB
• Redis
• Gegevens van het Overleaf-bestandssysteem

Om een consistente back-up te maken, is het verplicht om te voorkomen dat gebruikers nieuwe gegevens aanmaken terwijl het back-upproces loopt. We raden daarom aan een onderhoudsvenster in te plannen waarin gebruikers geen toegang hebben tot de instantie en hun projecten niet kunnen bewerken.

Voordat u het back-upproces start, moet u uw instantie offline halen. Vanaf Server Pro 3.5.0 automatiseert het afsluitproces het sluiten van de site en het verbreken van de verbinding met gebruikers.

Om uw instantie af te sluiten, voert u bin/docker-compose stop sharelatex uit als u een Toolkit-implementatie gebruikt, of docker compose stop sharelatex als u Docker Compose gebruikt.

Zodra de container sharelatex is gestopt, kunt u het back-upproces starten.

Zodra het back-upproces succesvol is voltooid, moet u de container sharelatex weer starten. Voer hiervoor bin/docker-compose start sharelatex uit als u een Toolkit-implementatie gebruikt, of docker compose start sharelatex als u Docker Compose gebruikt.

• Back-ups moeten worden opgeslagen op een andere server dan die waarop uw Overleaf-instantie draait, idealiter op een geheel andere locatie.
• Het repliceren van databases naar meerdere MongoDB-instanties kan enige redundantie bieden, maar beschermt niet tegen corruptie.
• Het testen van uw back-ups is de beste manier om te garanderen dat ze volledig en bruikbaar zijn.

​

MongoDB

MongoDB wordt geleverd met een opdrachtregelprogramma genaamd mongodump, waarmee u een back-up kunt maken van de gebruikers- en projectgegevens in de database.

​

Gegevens van het Overleaf-bestandssysteem

Bij Toolkit-implementaties wordt het pad waar uw niet-bewerkbare bestanden worden opgeslagen opgegeven in config/overleaf.rc met de omgevingsvariabele OVERLEAF_DATA_PATH, maar afhankelijk van wanneer uw instantie is aangemaakt, kan dit data/sharelatex zijn.

Het is noodzakelijk om met een hulpmiddel zoals rsync deze map recursief te kopiëren, zodat er een volledige back-up wordt gemaakt.

​

Redis

Redis slaat gebruikerssessies en openstaande documentupdates op voordat deze naar MongoDB worden weggeschreven.

Append Only File (AOF)-persistentie is de aanbevolen configuratie voor Redis-persistentie.

Voor Toolkit-gebruikers is AOF-persistentie standaard ingeschakeld bij nieuwe installaties; bestaande gebruikers vinden hier meer informatie over het inschakelen van AOF.

Als u besluit RDB-snapshots te blijven gebruiken naast AOF-persistentie, kunt u het RDB-bestand als back-up naar een veilige locatie kopiëren.

​

Gegevens migreren tussen servers

In het beste geval staan er nog geen waardevolle gegevens op de nieuwe instantie. We hebben geen proces voor het samenvoegen van gegevens van instanties.

Ervan uitgaande dat de nieuwe instantie nog geen gegevens bevat, zijn hier enkele stappen die u kunt volgen. Globaal gezien maken we een tarball van de volumes mongo, redis en overleaf, kopiëren we die naar de nieuwe server en pakken we die daar weer uit.

​

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

Afhankelijk van uw docker-compose.yml-bestand moet u mogelijk de paden van de volumes mongo, redis en overleaf aanpassen.

Wanneer tar als root-gebruiker (of met sudo) wordt uitgevoerd, behoudt het de eigenaar/groep en rechten van de bestanden, wat essentieel is bij het terugzetten van de back-up.

​

Mappen in detail

De volgende mappen hebben aanvullende aanduidingen:

• (b) opnemen in back-ups, bij voorkeur wanneer de instantie is gestopt om consistentie te garanderen
• (d) kan worden verwijderd
• (e) tijdelijke bestanden, kunnen worden verwijderd wanneer de instantie is gestopt

1. ~/mongo_data (b)
   • datamap van mongodb
2. ~/redis_data (b)
   • datamap van de redis-database
3. ~/overleaf_data
   1. bin
      1. synctex (d)
         • niet gebruikt in de nieuwste release; voorheen werd een aangepaste synctex-binary gebruikt (synctex wordt gebruikt voor de koppeling tussen .tex-bestanden en de pdf)
   2. data
      1. cache (e)
         • cache van binaire bestanden voor compilaties
      2. compiles (e)
         • hier vindt de LaTeX-compilatie plaats
      3. db.sqlite (d)
         • niet gebruikt in de nieuwste release; sloeg voorheen clsi-cachegegevens op (nu verplaatst naar eenvoudige in-memory maps of we scannen de schijf)
      4. db.sqlite-wal (d)
         • niet gebruikt in de nieuwste release, zie db.sqlite
      5. output (e)
         • opslag van LaTeX-compilatie-uitvoer om aan de client te leveren
      6. template_files (b)
         • afbeeldingsvoorbeelden van het sjabloonsysteem (alleen Server Pro)
      7. user_files (b)
         • binaire bestanden van projecten
      8. history (b)
         • bestanden van de volledige projectgeschiedenis
   3. tmp
      1. dumpFolder (e)
         • tijdelijke bestanden van het verwerken van zipbestanden
      2. uploads (e)
         • buffering van bestandsuploads (upload van binaire bestanden/nieuw project vanuit zip)
      3. projectHistories (e)
         • tijdelijke bestanden voor migraties van de volledige projectgeschiedenis