¿Por qué Remote Sync vuelve a copiar toda una carpeta después de reconectarse?

La sincronización remota vuelve a copiar una carpeta completa cuando el cliente ya no puede demostrar que los archivos locales y remotos son los mismos.

Después de que una laptop, NAS, recurso compartido montado o par remoto se reconecte, el motor de sincronización puede reconstruir su índice, ver una identidad de sistema de archivos diferente, perder hashes almacenados, detectar marcas de tiempo cambiadas, tratar archivos renombrados como objetos nuevos o comparar contra una base de datos desactualizada. El diagnóstico correcto protege ambas copias primero y luego determina si el cliente está reescanneando, rehaseando, volviendo a descargar o realmente retransfiriendo datos antes de restablecer cualquier biblioteca.

Confirme si el Cliente Está Escaneando, Calculando Hashes o Transfiriendo

Registre el rendimiento de la red, lecturas de disco, uso de CPU, estado del cliente y mensajes de registro durante la aparente recopia. Un escaneo completo o una pasada de suma de verificación puede parecer ocupado durante horas sin enviar la carpeta completa a través de internet.

Una discusión sobre rclone describe cómo el modo de suma de verificación puede repetir el procesamiento de sumas de verificación en cada ejecución. Ese comportamiento consume almacenamiento y CPU, pero difiere de una verdadera retransmisión por red.

Use contadores de transferencia por archivo o totales de paquetes para clasificar el evento. Si solo se leen metadatos y hashes, optimice el estado del escaneo; si se mueven nuevamente bytes completos de carga útil, continúe con pruebas de identidad, índice, marca de tiempo y renombrado.

Verifique si la Base de Datos o el Índice de Sincronización Fueron Reconstruidos

Inspeccione los registros del cliente alrededor de la reconexión para mensajes de migración de base de datos, corrupción, índice faltante, restablecimiento, reescanneado o primera ejecución. Compare el directorio de configuración del cliente y la marca de tiempo de la base de datos con la última sincronización exitosa.

Un caso de soporte de Syncthing explica que una base de datos de índice corrupta puede necesitar ser reconstruida, haciendo que el dispositivo se comporte como si las carpetas fueran recién agregadas y potencialmente causando un reescanneado inicial grande.

Haga una copia de seguridad de la base de datos antes de eliminarla o restablecerla. Si la recopia comenzó inmediatamente después de reinstalar la aplicación, recrear un contenedor, restablecer el perfil o perder la base de datos, preserve los datos buenos y use el flujo de trabajo soportado por el cliente para reconectar a una carpeta existente.

Compare la Identidad del Archivo Más Allá del Nombre de Archivo

Seleccione varios archivos que el cliente quiera recopiar y compare tamaño, hora de modificación, suma de verificación, permisos, propiedad, mayúsculas/minúsculas, atributos extendidos y ruta en ambos lados. Registre qué campo difiere.

Los usuarios de FreeFileSync discuten almacenar sumas de verificación porque solo el tamaño y las marcas de tiempo pueden no siempre demostrar que los archivos emparejados siguen siendo idénticos, mientras que las bases de datos de suma de verificación agregan sus propios requisitos de estado. Esto ilustra por qué los metadatos de comparación de archivos importan después de reconectar.

Si los hashes de contenido coinciden pero las marcas de tiempo o permisos difieren, corrija la configuración de reloj, preservación de metadatos o comparación en lugar de retransmitir contenido. Si los hashes difieren, identifique qué lado es el autorizado antes de permitir la sobrescritura automática.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique si la Carpeta se Reconectó Bajo una Identidad Diferente

Compare la ruta montada, UUID del sistema de archivos, nombre del recurso compartido en red, letra de unidad, identificador de volumen, montaje de contenedor o sensibilidad a mayúsculas/minúsculas antes y después de la desconexión. Una ruta de carpeta familiar puede apuntar a un montaje diferente o a un directorio local vacío.

Las herramientas de sincronización a menudo almacenan la identidad de la carpeta en una base de datos local en lugar de confiar solo en la ruta mostrada. Por lo tanto, un recurso compartido NAS remontado, un disco USB reemplazado, un volumen Docker cambiado o un perfil de cliente recreado pueden parecer un destino completamente nuevo.

Detenga la sincronización si el montaje esperado está ausente o la carpeta apunta a almacenamiento local de respaldo. Restaure el montaje original y verifique archivos de muestra antes de reconectar la biblioteca para evitar eliminaciones o descargas duplicadas.

Pruebe si se Detectan Movimientos y Cambios de Nombre

Elija una carpeta pequeña, cámbiele el nombre mientras ambos pares están conectados y observe si el cliente realiza un movimiento de metadatos o sube cada archivo como contenido nuevo. Repita después de una desconexión y reconexión.

Una discusión sobre una función de Syncthing señala que los movimientos o cambios de nombre pueden tratarse como nuevas transferencias cuando la herramienta no puede coincidir las rutas cambiadas a través de su índice existente, produciendo un comportamiento de eliminar y volver a subir.

Si la recopia sigue a un cambio de nombre de carpeta a nivel superior, deje que el cliente complete su intercambio de índice antes de hacer más cambios. Para bibliotecas grandes, evite cambios masivos simultáneos en múltiples pares y mantenga habilitada la versión o protección de respaldo.

Reconecte de Forma Segura Sin Restablecer la Copia Buena

Haga una copia de seguridad o instantánea del lado autorizado, pause la sincronización y pruebe una subcarpeta pequeña usando la función de carpeta existente o re-vinculación del cliente. No haga clic en un botón genérico de restablecer o resincro antes de entender su dirección.

La guía de ZimaSpace para restaurar una carpeta compartida de forma segura proporciona el mismo principio de contención para proteger datos no afectados.

El problema se resuelve solo cuando la reconexión preserva el índice, compara archivos existentes sin transferencia de carga útil, aplica solo cambios genuinos y sobrevive a otra desconexión. Si la base de datos se corrompe o desaparece repetidamente, solucione el problema de almacenamiento, apagado, persistencia del contenedor o instalación del cliente en lugar de aceptar sincronizaciones completas recurrentes.