Skip to main content

Migración a S3

Estas instrucciones son para la v5.x y posteriores. Si sigues esta guía para una versión anterior, usa sharelatex en lugar de overleaf en los nombres de ruta y el prefijo SHARELATEX_ en lugar de OVERLEAF_ para las variables de entorno. Para la v6 y posteriores, omite los comandos heredados de user_files.
¡Nos encantaría saber de ti! Si quieres contarnos cuántos archivos migraste, su volumen total y cuánto tardó la migración, escribe a ayaka-notes@outlook.com.
Esta guía te acompañará en la migración del almacenamiento en disco a un almacenamiento de objetos compatible con S3. Hace referencia a secciones del documento introductorio sobre la configuración de S3.

Requisitos

  • Un almacenamiento de objetos compatible con S3 con el que comunicarse; consulta #s3-setup para ver las opciones
  • Espacio libre en disco para migrar los datos existentes, aproximadamente el tamaño actual en disco
  • Una ventana de mantenimiento para realizar la migración propiamente dicha
  • Una copia de seguridad completa, incluida la configuración, para poder restaurarla

Estimar el espacio en disco necesario para la migración

Podemos usar du para calcular el uso actual del disco:
Si no tienes suficiente espacio en disco disponible en el servidor actual, prueba a conectar otro disco al servidor.
Los directorios del historial ya tienen la estructura correcta. Puedes subirlos directamente desde la carpeta de origen montada (bind-mount), lo que no requiere espacio en disco adicional.

Pasos de la migración

Paso 0: detener la instancia

Debemos asegurarnos de que se migren todos los archivos de usuario y de plantillas. Lo mejor es detener la instancia para no perder archivos subidos recientemente. Consulta nuestra guía sobre cómo realizar una copia de seguridad coherente para conocer el procedimiento de detención.

Paso 1: reescribir la estructura de directorios

Debemos reescribir la estructura de directorios de los archivos de proyecto para subirlos a S3. La estructura de directorios del almacenamiento local en filestore es <project-id>_<file-id> y la estructura de directorios en S3 es <project-id>/<file-id>. A continuación, se usa /srv/overleaf-s3-migration para almacenar los archivos con la nueva estructura de directorios. Sustituye /srv/overleaf-bind-mount por el directorio del host montado en /var/lib/overleaf. Ejecuta los comandos de copia en el host con permisos de lectura y escritura sobre estos directorios; el contenedor permanece detenido. Podemos usar tar para reescribir la estructura:

Paso 2: subir los archivos

Según tus preferencias, puedes usar el cliente S3 minio mc o la aws cli para subir los archivos a tu almacenamiento de objetos compatible con S3. aws cli
  • Aquí debes sustituir overleaf-user-files, overleaf-template-files, overleaf-project-blobs y overleaf-chunks por los nombres de tus buckets de S3.
  • Sustituye también /srv/overleaf-bind-mount por la ruta local del bind-mount de /var/lib/overleaf. De forma predeterminada, es ~/overleaf_data en un despliegue con docker-compose.yml y <toolkit-checkout>/data/overleaf al usar el Toolkit.
minio mc Aquí usamos el alias de servidor “s3”; es posible que tú hayas elegido otro nombre.

Paso 3: iniciar la instancia apuntando a S3

Añade todas las variables relacionadas con S3 a tu configuración, tal como se detalla en la sección Resumen de variables de la guía de configuración de S3. Mantén el bind-mount del directorio de datos: también puede contener claves de cifrado de Zotero o Mendeley que no se migran a S3. Ahora puedes iniciar la instancia y validar la migración:
  • se pueden previsualizar archivos binarios en el editor
  • se puede compilar un PDF con imágenes
  • se pueden subir archivos nuevos

Revertir la migración

Puedes revertir la migración de forma ordenada invirtiendo los pasos:
  1. Detén la instancia
  2. Vuelve a reflejar los archivos invirtiendo el orden de origen/destino
  3. Vuelve a escribir los archivos nuevos en el directorio local usando una transform inversa
  4. Reinicia la instancia con la configuración anterior
La primera transformación elimina la carpeta de nivel superior. La segunda transformación cambia la estructura de directorios a una estructura plana. Los comodines garantizan que solo se extraigan los archivos, no sus carpetas padre (de proyecto).
Última modificación el 5 de octubre de 2026