Sincronización con almacenamiento cifrado remoto

Question

Estoy intentando mantener sincronizado un árbol de carpetas entre varias computadoras. Actualmente, lo estoy usando unisonen una topología en estrella, con un servidor remoto central. Quiero que los datos en el servidor estén encriptados, por lo que en el servidor, el unisonárbol (incluida la .unisoncarpeta) se mantiene dentro de un encfsárbol. Para realizar una sincronización, cada cliente:

• monta el almacenamiento del servidor consshfs
• monta el encfsalmacenamiento sshfslocalmente
• realiza unisonentre la copia local de documentos y la montada.

La configuración tiene muchas ventajas:

• herramientas de código abierto
• solución de línea de comandos programable
• comunicación segura sobressh
• privacidad del servidor porque el encfsárbol de carpetas nunca se descifra allí
• capacidad de diferenciar modificaciones durante la sincronización, porque unisonse ejecuta sobre texto sin formato

Una cosa que no funciona tan bien es la velocidad de sincronización. Debido a que la encfscarpeta del servidor está montada en el cliente, cada stat()llamada que realiza el cliente debe reenviarse sshal servidor. El árbol de documentos ya tiene miles de archivos y una unisonsincronización debe realizar al menos una stat()llamada para cada archivo (para descartar modificaciones en el estado almacenado en la .unisoncarpeta). ¿Existe alguna alternativa más rápida que mantenga las ventajas enumeradas anteriormente?

Nota: Si eliminara la última condición, podría ejecutar unisonel texto cifrado y montar el encfsárbol solo localmente. Luego unisonse ejecutaría localmente en el cliente y en el servidor, por lo que stat()las llamadas serían rápidas. Pero es bueno tener la opción de ver al menos qué archivos se están sincronizando; con texto unisoncifrado encfs, los nombres de los archivos se cifrarían.

Entiendo que para resolver este problema, hay que transferir eficientemente los metadatos del archivo desde el servidor al cliente durante la sincronización. Me pregunto si hay una manera (es decir, una combinación de herramientas existentes) de, por ejemplo, almacenar los metadatos en un solo lugar, de modo que todos se transfieran enviando solo uno (o algunos) bloques de datos. , en lugar de enviar miles de bloques (que es lo que stat()hace el desvío de llamadas).

¿Qué pasaría si tuviera que reemplazar encfspor, digamos, una partición ext4over dm-cryptalmacenada dentro de un archivo grande en el servidor y montada en el cliente mediante losetupover sshfs? ¿El ext4sistema de archivos mantendría los metadatos de los archivos juntos, de modo que se transfieran enviando solo unos pocos bloques? ¿Sabría sshfsenviar sólo unos pocos bloques durante una actualización, en lugar de reescribir todo el archivo cifrado?

Answer 1

He tenido éxito con ext4over luksover sshfs. Encuentro que ejecutar unisonen una montura de este tipo es mucho, mucho más rápido que sobre encfsover sshfs. Entonces debe ser que esos miles de stat()estructuras están de alguna manera agrupadas en ext4fs, de modo que requieren menos tráfico de red durante una sincronización.

Una cosa que es un poco molesta es que el ext4sistema de archivos necesita una identificación de usuario para cada archivo, y esta identificación de usuario se usa para calcular los permisos de acceso cuando el ext4fs está montado localmente en un cliente. En mi caso, elegí cambiar mi identificación de usuario local a un número específico entodolos clientes desde los que estoy sincronizando. La alternativa sería almacenar los archivos en ext4fs con uid 0 y luego usarlos bindfspara montar ext4fs con uid que no sea root.