GUÍA PRÁCTICA · GURUCLOUD
Cómo plantear una nube personal sin convertirla en un servicio público de archivos
Una nube personal no empieza con un botón de subir. Empieza decidiendo quién controla el ordenador, qué carpetas se exponen y cómo se reconoce cada dispositivo. Esta guía resume el modelo que uso al desarrollar y probar GuruCloud y GuruNode.
1. Define primero el modelo de propiedad
En un servicio centralizado, una empresa recibe los archivos y decide dónde conservar las copias. En un sistema autohospedado, el ordenador del usuario sigue siendo el origen. La aplicación móvil actúa como cliente y el nodo del ordenador decide qué operaciones acepta. Esta diferencia cambia la instalación, la seguridad y también las expectativas de disponibilidad.
GuruCloud se diseñó para contenido propio o autorizado. No crea un directorio público, no publica enlaces para terceros y no busca material en Internet. Tampoco convierte una carpeta en una red abierta. Esta frontera es deliberada: el propósito es acceder a un equipo concreto que el usuario administra.
2. Piensa en fallos reales, no en una nube abstracta
Los riesgos más habituales no son misteriosos: un código de vinculación aceptado sin mirar, una carpeta demasiado amplia, una copia de seguridad inexistente o un portátil que queda apagado cuando se necesita. También importa diferenciar la confidencialidad de la disponibilidad. Cifrar la conexión protege el tránsito, pero no enciende un ordenador ni recupera un disco averiado.
Mi lista mínima incluye cuatro preguntas: qué ocurre si se pierde el teléfono, cómo se revoca un dispositivo, qué copia independiente existe y cómo se comprueba la identidad del nodo. El sistema debe ofrecer una respuesta concreta para cada una. Una contraseña compartida entre todos los dispositivos dificulta la revocación; una credencial distinta por teléfono permite retirar solo el acceso perdido.
3. Empieza en la red local y añade acceso remoto después
La red local reduce variables durante la primera instalación. El teléfono y el ordenador deben verse, el nodo debe escuchar en la dirección esperada y el cortafuegos debe permitir únicamente el puerto necesario. Cuando el flujo local funciona, una red privada como Tailscale puede ofrecer una ruta remota sin publicar el nodo directamente en Internet.
Conviene conservar ambas rutas cuando han sido verificadas. En casa, la LAN suele ser más rápida; fuera, la ruta privada remota mantiene el acceso. La aplicación puede elegir una ruta disponible, pero el propietario debe poder ver cuál se usa. Un fallo remoto no debe confundirse con un problema de credenciales si la conexión local sigue funcionando.
Comprobación de red
- El nodo muestra una dirección HTTPS y su puerto.
- El certificado identifica al mismo nodo que se va a autorizar.
- La búsqueda automática se limita a la red local.
- El acceso remoto usa una red privada administrada por el propietario.
- No se abre un directorio público ni se comparte una URL anónima.
4. Trata la vinculación como una comprobación de identidad
Encontrar un nodo no significa que sea el correcto. Un buen flujo presenta la identidad del ordenador y un código corto en ambos extremos. El usuario compara el código y confirma desde un dispositivo ya autorizado o desde el propio nodo. Si los datos no coinciden, se cancela y se investiga; no se repite pulsando aceptar.
Después de vincular, cada teléfono recibe una credencial aleatoria. Guardarla en el almacén seguro de Android reduce la exposición accidental. El nodo debe permitir listar y revocar dispositivos. Probar la revocación forma parte de la instalación: si un teléfono revocado aún puede explorar una carpeta, el sistema no está listo.
5. Expón carpetas por intención
Compartir la raíz de un disco suele ser cómodo el primer día y confuso después. Es mejor crear ubicaciones concretas, por ejemplo documentos de trabajo propios, fotografías personales o una carpeta de intercambio entre dispositivos del mismo propietario. Los permisos deben corresponder a la tarea: lectura para consulta, escritura cuando realmente se necesite subir o reorganizar.
Los nombres y miniaturas también son datos. Aunque los archivos no salgan del nodo, un cliente puede mantener una caché local para mostrar la galería con rapidez. Esa caché debe estar limitada, poder borrarse y desaparecer al eliminar los datos de la aplicación. Para contenido sensible, revisa además las copias automáticas del sistema móvil.
6. Sincronización y copia de seguridad no son lo mismo
Una sincronización propaga cambios. Si se elimina un archivo por error, la eliminación puede propagarse con la misma eficacia. Una copia de seguridad conserva estados anteriores y permite recuperar. Para los datos importantes recomiendo tres capas: el archivo de trabajo, una copia local independiente y una copia adicional desconectada o en otra ubicación controlada.
Antes de automatizar una carpeta, prueba con archivos sintéticos. Observa qué ocurre al renombrar, mover, interrumpir la red y recuperar la conexión. Comprueba también el espacio libre. La automatización útil es la que falla de forma visible y puede reanudarse sin duplicar o sobrescribir contenido inesperadamente.
7. Diagnostica por capas
Cuando algo falla, separa descubrimiento, transporte, identidad, autorización y operación. Si el nodo no aparece, prueba la dirección explícita y revisa la red. Si responde pero rechaza, comprueba certificado, código y credencial. Si se puede listar pero no escribir, revisa permisos de la carpeta. Esta secuencia evita cambiar varias cosas a la vez.
Guarda una nota corta de cada prueba: dispositivo, red, ruta, operación y resultado. No incluyas tokens, códigos temporales ni nombres privados en mensajes de soporte. Un informe pequeño y preciso permite reproducir el problema sin entregar el contenido del usuario.