¿Por qué un trabajo de sincronización en la nube vuelve a cargar archivos eliminados anteriormente después de restaurar su base de datos de estado?
Una base de datos de sincronización restaurada puede volver a cargar archivos eliminados cuando ya no contiene los registros de eliminación que distinguían entre una eliminación intencionada y datos locales recién descubiertos.
La sincronización bidireccional depende de algo más que de los archivos visibles actualmente. Mantiene un índice o una base de datos con rutas anteriores, versiones, ID de dispositivos, marcadores de eliminación y el estado de sincronización. Restaurar una base de datos antigua mientras se conservan archivos locales más recientes o el estado actual de la nube crea un desfase temporal: el cliente puede analizar una copia local superviviente como si fuera nueva o interpretar la eliminación remota como un conflicto. Pausa todos los participantes de la sincronización antes de decidir qué línea temporal es la autorizada.
Confirma qué base de datos y árbol de archivos se restauraron
Registra la hora de la copia de seguridad de la base de datos, la hora del árbol de archivos local, el estado de la nube, la configuración del cliente, la identidad del dispositivo y el primer evento de nueva carga. Comprueba si la base de datos y los archivos proceden del mismo punto de recuperación.
El procedimiento de restauración de Nextcloud requiere restaurar la base de datos y el directorio de datos como un sistema coherente, porque restaurar solo una capa crea metadatos que ya no coinciden con los archivos almacenados.
Si la base de datos es anterior a la eliminación, pero el árbol local contiene una copia antigua superviviente, la nueva carga es predecible. Conserva los tres estados antes de permitir otra pasada de sincronización automática.
Comprueba si se revirtieron los marcadores de eliminación
Identifica si el estado restaurado contiene el evento de eliminación, la versión del archivo, el ID del elemento remoto y el dispositivo que eliminó originalmente el archivo. Compara los registros de actividad inmediatamente anteriores y posteriores a la eliminación.
Syncthing mantiene una base de datos de índice local y advierte de que un restablecimiento de la base de datos fuerza un análisis completo y una resincronización; si posteriormente aparece un árbol de archivos montado más antiguo, pueden producirse versiones incoherentes.
Una eliminación que solo existía en la base de datos más reciente desaparece después de la reversión. El siguiente análisis ve el archivo restante, pero carece de la evidencia histórica de que debía permanecer eliminado.
Revisa los archivos de listado de Bisync o de sincronización bidireccional con estado
En herramientas como Rclone Bisync, localiza ambos listados anteriores, el directorio de trabajo, el estado del bloqueo y la última ejecución correcta. No consideres una resincronización nueva equivalente a continuar desde un estado válido.
Rclone documenta que Bisync conserva el estado entre ejecuciones sucesivas y almacena los datos de trabajo por separado de las carpetas sincronizadas.
Restaurar o eliminar esos listados puede borrar la distinción entre «eliminado desde la última ejecución» y «solo existe en este lado». Usa una ejecución de prueba y guarda ambos listados antes de reconstruir el estado.
Actualiza la huella digital del servidor después de restaurar una base de datos
Comprueba si la plataforma del servidor proporciona un marcador de recuperación que informe a los clientes de que la base de datos se restauró. Aplícalo antes de que los clientes vuelvan a conectarse.
ownCloud indica a los administradores que ejecuten maintenance:data-fingerprint después de la restauración para que los clientes de escritorio y móviles puedan reconocer el estado recuperado del servidor.
Sin una huella de recuperación modificada, los clientes pueden continuar basándose en suposiciones creadas frente a la base de datos posterior. Esto puede provocar conflictos, nuevas cargas o intentos de eliminar objetos restaurados en el servidor.
Identifica las copias locales que sobrevivieron a la eliminación en la nube
Busca en todos los dispositivos sincronizados, carpetas sin conexión, rutas excluidas, papeleras de reciclaje, directorios de conflictos y carpetas temporales de recuperación copias del archivo eliminado.
Dropbox explica que eliminar un elemento puede eliminarlo de los dispositivos sincronizados, pero las copias pertenecientes a otro lugar o que ya no participan en el mismo estado de sincronización pueden permanecer.
Un archivo local superviviente se convierte en candidato para una nueva carga cuando la base de datos restaurada ya no lo reconoce como el objeto eliminado anterior. Calcula su hash y ponlo en cuarentena fuera de la raíz de sincronización antes de reconciliar los estados.
Pausa los clientes antes de restablecer o reconstruir el estado de sincronización
Detén los trabajadores de sincronización del servidor y pausa todos los clientes de sincronización de escritorio, móviles, contenedores y tareas programadas. Vuelve a conectar primero un único punto de conexión autorizado.
El procedimiento de restablecimiento de OneDrive de Microsoft indica que el cliente reconstruye su archivo DAT local, lo que ilustra por qué un restablecimiento modifica el estado del cliente sin decidir qué versión histórica del archivo debe considerarse autorizada.
Restablecer no sustituye a elegir la línea temporal correcta. Si varios clientes vuelven a analizar simultáneamente, uno puede cargar una copia local antigua mientras otro propaga la eliminación.
Reconcilia una carpeta con una ejecución de prueba y una copia de seguridad independiente
Exporta la base de datos restaurada, copia todos los archivos locales en conflicto fuera de las raíces de sincronización, elige el estado autorizado y prueba primero con una carpeta pequeña antes de reanudar la biblioteca completa.
La guía de copias de seguridad 3-2-1 de ZimaSpace establece el límite relacionado: el estado de sincronización no es una copia de recuperación independiente cuando puede reproducir eliminaciones o volver a cargar datos obsoletos.
El problema se resuelve cuando los archivos eliminados permanecen eliminados, los archivos supervivientes previstos se cargan una sola vez, los conflictos quedan documentados y una segunda sincronización controlada no produce resurrecciones inesperadas.
Preguntas frecuentes
¿Restaurar la base de datos también restaura el historial de eliminaciones?
Solo hasta la fecha de la copia de seguridad de la base de datos. Las eliminaciones registradas después de ese momento no están disponibles, salvo que otro registro o punto de conexión las conserve.
¿Deben permanecer conectados todos los clientes de sincronización durante la recuperación?
No. Paúsalos y vuelve a conectar primero un único punto de conexión autorizado para que los clientes antiguos no reintroduzcan inmediatamente archivos obsoletos.
¿Un análisis completo solucionará el problema de forma segura?
Un nuevo análisis reconstruye lo que existe actualmente, pero no puede inferir la intención histórica que falta. Puede volver a cargar archivos supervivientes si antes no se elige el estado autorizado.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
