Sincronizar archivos STL entre PC y NAS

Casi toda sincronización de modelos que falla es una herramienta de un solo sentido a la que se le pide trabajar en dos. rsync desde el PC es de fiar hasta el día en que editas un archivo en el NAS y el siguiente envío restaura sin avisar la versión antigua encima. Así que la primera decisión no es qué herramienta usar, sino si los archivos cambian en un sitio o en dos.

Si diseñas en el PC y el NAS es almacenamiento, envía en un sentido y no sincronices de vuelta nunca. Si de verdad trabajas desde dos equipos, usa una herramienta pensada para dos sentidos y activa su versionado. Y si preferirías no tener dos copias, monta el recurso compartido y trabaja directamente sobre él. Esos son los tres montajes que aguantan: cualquier mezcla de ellos es el montaje que acaba comiéndose un archivo.

Trabaja directamente sobre el montaje si puedes

El montaje fiable más simple es no sincronizar. Monta el recurso compartido, apunta ahí el diálogo de abrir del slicer y solo habrá una copia sobre la que equivocarse.

# NFS, in /etc/fstab
192.168.1.10:/volume1/3dprints  /mnt/nas/3d  nfs  defaults,_netdev,soft  0  0

# SMB / CIFS, in /etc/fstab
//192.168.1.10/3dprints  /mnt/nas/3d  cifs  credentials=/root/.nas-creds,uid=1000,gid=1000,iocharset=utf8,_netdev  0  0

_netdev evita que el sistema intente el montaje antes de que exista la red, y soft en NFS hace que un servidor que no responde te devuelva un error de E/S en lugar de dejar un proceso colgado en espera ininterrumpible. Guarda las credenciales en un archivo con chmod 600 en lugar de ponerlas en la línea de fstab, donde cualquier usuario de la máquina puede leerlas.

Lo que pierdes es trabajar sin red y la agilidad del slicer con mallas grandes, porque cada carga de malla pasa por la red. Un conjunto STEP de 200 MB por Wi-Fi va bastante peor que el mismo archivo en un NVMe local. Si eso molesta, copia al PC los pocos archivos que estés tocando y deja el archivo histórico en el montaje.

Envía en un solo sentido con rsync

Cuando los archivos cambian en el PC, un solo sentido es todo lo que necesitas y lo único que hay que acertar es no borrar el lado equivocado.

rsync -a --dry-run --delete-after ~/3d-models/ /mnt/nas/3d/

Lánzalo primero con --dry-run, lee la lista de borrados y vuelve a lanzarlo sin él. La barra final en el origen significa “el contenido de este directorio”: si la omites, copias el directorio en sí dentro del destino y acabas con /mnt/nas/3d/3d-models/. Ese error se te presenta luego como un fallo de sincronización. --delete-after borra en el NAS los archivos que ya no existen en el PC, que es lo que convierte la copia en un espejo y también lo que hace destructiva una ruta equivocada. Si no lo tienes claro, deja --delete-after fuera: un STL viejo de más no cuesta nada al lado de una carpeta borrada.

-a conserva las fechas de modificación, y eso importa más de lo que parece. Las marcas de tiempo son la forma en que tanto rsync como la mayoría de los indexadores deciden que un archivo no ha cambiado, así que un espejo con las fechas intactas se salta casi todo en la segunda pasada en lugar de volver a calcular el hash de toda tu biblioteca.

Otros dos parámetros se ganan su sitio. -n es lo mismo que --dry-run cuando lo quieres corto, y -c compara por suma de verificación en lugar de por tamaño y fecha. Es lento, y pasarlo una vez al trimestre confirma que los dos lados coinciden de verdad. La degradación de bits y una transferencia truncada son idénticas para una comparación por tamaño y fecha.

Por omisión, rsync escribe cada archivo con un nombre temporal y lo renombra a su sitio cuando la transferencia termina, así que nada llega a ver un STL a medio escribir. --inplace desactiva eso y escribe directamente en el archivo de destino. Ahorra espacio con archivos enormes y aquí es la opción equivocada, porque cualquier cosa que vigile esa carpeta puede leer una malla incompleta.

En un PC con Windows, el equivalente es robocopy con /MIR, con el mismo aviso pegado a la misma función.

Usa Syncthing cuando cambian los dos lados

La sincronización en dos sentidos necesita una herramienta que guarde estado sobre lo que ha visto cada lado, y Syncthing es la respuesta autoalojada habitual: lo instalas en el PC y en el NAS, compartes una carpeta entre los dos dispositivos y reconcilia de forma continua sin una cuenta en la nube por medio.

Activa el versionado de archivos antes de confiarle nada. Syncthing viene sin versionado, lo que significa que un borrado o una sobreescritura en un equipo se propaga al otro sin dejar copia. El versionado escalonado es una opción razonable, porque conserva más versiones recientes que antiguas. Comprobado el 19 de agosto de 2026.

Cuando los dos lados cambian de verdad el mismo archivo, Syncthing conserva los dos. La copia con la marca de tiempo más antigua se renombra a <name>.sync-conflict-<date>-<time>-<device>.<ext>. Ese es el comportamiento que quieres, porque tener dos archivos que comparar es mejor que tener uno elegido por ti en silencio.

Si quieres la forma de un envío en un solo sentido pero ejecutado por Syncthing, pon la carpeta del PC en Send Only y la del NAS en Receive Only. Los tipos de carpeta hacen lo que dicen sus nombres: una carpeta Send Only ignora los cambios entrantes, y una Receive Only se guarda los cambios locales en lugar de distribuirlos. Ojo con lo que eso implica más abajo, porque una biblioteca que escribe revisiones nuevas en una carpeta Receive Only está haciendo exactamente el tipo de cambio local que ese modo existe para frenar.

Cuando PrintStash indexa la carpeta

Nada de lo anterior tiene que ver con PrintStash, y es a propósito: la sincronización es un problema del sistema de archivos y la biblioteca lee el resultado. Añade la carpeta del NAS como volumen compartido y PrintStash indexa los archivos donde ya están, guardando solo los metadatos que extrae y una miniatura generada. La carpeta sigue siendo la fuente de verdad, y tu política de instantáneas del NAS sigue cubriendo los bytes reales.

Hay cuatro comportamientos que importan antes de apuntarlo a una carpeta en la que también escribe una herramienta de sincronización.

La vigilancia en tiempo real no funciona en montajes de red. PrintStash usa eventos del sistema de archivos en rutas locales, y el núcleo no los entrega para NFS ni SMB, así que un volumen compartido sobre una carpeta de red recurre a su calendario de escaneo. Cada hora es un punto de partida razonable. Puedes forzar la vigilancia, que en su lugar consulta con stat, y para la mayoría de bibliotecas cuesta más trabajo del que ahorra.

Un escaneo lee primero el tamaño y la fecha de modificación y solo recalcula el hash cuando uno de los dos se ha movido, con dos segundos de holgura en la marca de tiempo para absorber el redondeo que aplican FAT y SMB. Un espejo de rsync que conserva las fechas produce por tanto un escaneo casi gratis. Una herramienta de sincronización que reescribe las marcas de tiempo produce un recálculo completo en cada pasada.

Un recurso compartido sin montar no borra tu biblioteca. Si el punto de montaje falta, no se puede leer o está vacío mientras el volumen todavía tiene archivos indexados, el escaneo se aborta y se marca como erróneo en lugar de tirar todo a la basura. Ese accidente concreto es el que la regla existe para evitar. Vuelve a montar y escanea otra vez.

La escritura de vuelta va a la misma carpeta. Subir un archivo o añadir una revisión desde la interfaz web a un modelo que pertenece a un volumen compartido escribe el archivo nuevo en esa carpeta y no en el almacenamiento propio de PrintStash, y solo añade archivos, nunca sobreescribe. Con una carpeta Send and Receive, ese archivo nuevo aparece en tu PC en la siguiente pasada, que suele ser lo que quieres. Con el lado del NAS en Receive Only, no: Syncthing lo cuenta como un cambio local, lo retiene y te ofrece revertirlo. Elige una cosa o la otra a conciencia. Si prefieres que PrintStash no escriba nunca en la carpeta, monta la ruta con :ro en Docker y acepta que las subidas y las revisiones de los modelos de ese volumen fallarán.

El detalle que hay que prever

Un escaneo recorre todos los subdirectorios e indexa cualquier cosa con una extensión admitida, incluidos los directorios cuyo nombre empieza por un punto. Las copias versionadas de Syncthing viven por omisión en .stversions dentro de la carpeta compartida, así que activar el versionado y apuntar un volumen compartido a esa misma carpeta te deja cada revisión antigua de cada malla como un modelo propio en la biblioteca.

Hay dos salidas. Mueve el directorio de versiones fuera de la carpeta sincronizada, algo que Syncthing admite siempre que se quede en el mismo sistema de archivos, o apunta el volumen compartido a una subcarpeta que solo contenga tus modelos. La primera es más limpia si ya tienes la estructura de carpetas.

Las copias de conflicto también acaban en la biblioteca, por el mismo motivo: bracket.sync-conflict-20260819-101500-K7QX3RN.stl sigue terminando en .stl. Eso se puede defender como una ventaja, porque un conflicto que ves es mejor que uno que no ves, pero saberlo por adelantado te ahorra diagnosticar un duplicado como un fallo de indexación.

Las transferencias a medias no son un problema del mismo tipo. Los archivos temporales de Syncthing se llaman .syncthing.<name>.tmp y los nombres temporales por omisión de rsync terminan en un sufijo aleatorio y no en una extensión de modelo, así que ninguno se indexa mientras aún se está escribiendo.

Preguntas que suelen surgir

¿Qué método elijo al final?

Monta el recurso compartido si tus modelos son grandes y tu red es buena, porque una sola copia no puede contradecirse a sí misma. Envía en un solo sentido con rsync si diseñas en un PC y quieres el NAS como archivo histórico, porque es lo menos sorprendente que le puede pasar a tus archivos. Usa Syncthing solo si de verdad editas desde dos equipos, y activa el versionado en el mismo momento en que activas Syncthing. Los montajes que fallan son casi siempre un espejo de rsync usado como si fuera bidireccional.

¿Sigo necesitando copias de seguridad si el NAS tiene mis archivos y PrintStash los indexa?

Sí, y el motivo es concreto. El archivo de copia de seguridad propio de PrintStash cubre su base de datos, los archivos que le pertenecen, las miniaturas y un manifiesto. Los archivos indexados desde un volumen compartido no son bytes de PrintStash, así que no están en ese archivo, y tienen que cubrirlos tu instantánea del NAS o tu copia fuera de casa. Una sincronización tampoco es una copia de seguridad: una sincronización en dos sentidos propaga un borrado con toda fidelidad, que es justo lo que no quieres después de una mala tarde. Copias de seguridad que sí se restauran explica la frontera en detalle.

¿Cuánto tarda en aparecer en la biblioteca un archivo que llega al NAS?

En un montaje de red, hasta un intervalo de escaneo, porque la vigilancia en tiempo real necesita eventos del sistema de archivos del núcleo que NFS y SMB no entregan. Elige un calendario con el que puedas vivir, pulsa Scan now cuando te impacientes y cuenta con que el primer escaneo de una carpeta grande tarde, porque calcula el hash y analiza todo. Los escaneos posteriores solo tocan los archivos cuyo tamaño o marca de tiempo cambió, así que un espejo que conserva las fechas sigue siendo barato.

¿Sincronizar la misma carpeta desde dos PC corrompe algo?

Corromper no, pero puede perder una edición si la herramienta no está pensada para eso. Syncthing detecta el caso y conserva las dos copias, renombrando la de marca de tiempo más antigua para incluir sync-conflict y la fecha. Un espejo de rsync no tiene el concepto de conflicto: gana el lado que hayas nombrado como origen, y el archivo más nuevo del otro lado se sobreescribe sin decir nada. Si dos equipos editan de verdad los mismos modelos, esa es la situación para la que existe la sincronización en dos sentidos.

¿Deberían ser el mismo sitio la carpeta sincronizada y la bóveda de PrintStash?

No, y PrintStash los mantiene separados a propósito. La bóveda guarda los archivos que PrintStash posee y ha copiado, mientras que un volumen compartido indexa archivos que no le pertenecen y que nunca borra. Mezclar los dos significaría que una herramienta de sincronización reescribe archivos que PrintStash considera suyos, con los hashes y los metadatos separándose de lo que hay en disco. Deja tu biblioteca sincronizada como volumen compartido y que las subidas desde la interfaz web escriban de vuelta en ella.

Fuentes

• Documentación de Syncthing sobre file versioning, folder types y temporary and conflicting files para los valores por omisión y los nombres de archivo exactos. Comprobado el 19 de agosto de 2026.
• La página de manual de rsync para --inplace, --delete-after, -c y el comportamiento por omisión con los archivos temporales.
• El escaneo de bibliotecas externas de PrintStash en la versión publicada v0.11.4, en el repositorio, para el filtro de extensiones, la tolerancia de dos segundos en la marca de tiempo y el aborto cuando la raíz está vacía.
• La guía de volúmenes compartidos de PrintStash para montar una ruta del NAS en el contenedor y los modos de vigilancia.