Tocho: almacenamiento personal soberano, cifrado y replicado entre dos ubicaciones

Puedes escuchar este artículo en formato audio (generado por NotebookLM):

1. Introducción

Tocho es un proyecto personal que mantenemos Ismael Ripoll y yo, Raúl, con el objetivo de disponer de un sistema de almacenamiento masivo, razonablemente fiable, cifrado y replicado entre dos ubicaciones físicas diferentes.

La idea inicial era sencilla: cada uno de nosotros tendría una Raspberry Pi con un disco duro SATA de 16 TB. Cada disco serviría para guardar los datos propios y, al mismo tiempo, una copia cifrada de los datos del otro. De esta manera, cada uno dispondría de una réplica externa en otra casa.

Con el tiempo, el proyecto ha ido evolucionando. Ya no es solo “un NAS casero con una copia remota”, sino una infraestructura personal que combina:

• almacenamiento masivo;
• copias cruzadas;
• cifrado;
• acceso nativo desde Linux;
• monitorización;
• protección frente a averías;
• protección parcial frente a ransomware;
• copias versionadas con Borg;
• y una filosofía clara de soberanía técnica.

No es un sistema empresarial ni pretende sustituir una infraestructura profesional. Pero sí proporciona una mejora muy importante respecto a tener una sola copia local, o peor todavía, a no tener ninguna estrategia de copia sistemática.

2. Motivación

La motivación principal es muy práctica: los datos personales ocupan cada vez más espacio y no siempre encajan bien en los servicios comerciales de nube. Fotos, vídeos, repositorios, documentos, imágenes de disco, copias de máquinas, proyectos personales y archivos históricos pueden llegar fácilmente a varios terabytes.

Los servicios comerciales resuelven muy bien muchos problemas, pero también imponen limitaciones:

• coste mensual recurrente;
• dependencia de un proveedor;
• integración desigual con Linux;
• ausencia de control real sobre protocolos y automatismos;
• límites de espacio;
• políticas cambiantes;
• y, a menudo, una interfaz pensada más para usuarios generales que para flujos técnicos.

Tocho nace de una idea diferente: si tenemos conocimiento técnico suficiente, podemos construir una infraestructura propia, entenderla, repararla y adaptarla a nuestras necesidades.

Ahora bien, una de las lecciones del proyecto es precisamente que esto no es gratis. Aunque no se pague una cuota mensual, hay que pagar discos, adaptadores, alimentación, refrigeración, tiempo de administración, pruebas, monitorización y mantenimiento. La nube comercial puede parecer cara hasta que cuentas todo lo que implica operar tú mismo una infraestructura mínimamente fiable.

3. Objetivos del proyecto

Los objetivos principales de Tocho son:

1. Disponer de mucho espacio de almacenamiento a un coste asumible.
2. Mantener una réplica remota de los datos importantes.
3. Proteger la confidencialidad de los datos alojados en el servidor del otro.
4. Reducir el riesgo de pérdida frente a averías, robos, incendios u otras incidencias locales.
5. Usar herramientas estándar de Linux.
6. Permitir acceso nativo a los archivos, sin depender de una aplicación propietaria.
7. Hacer copias versionadas y deduplicadas.
8. Reducir el riesgo de que un ransomware o un error humano destruya todas las copias.
9. Mantener el sistema comprensible y reparable por los dos administradores.

La filosofía es que la fiabilidad no depende solo de comprar hardware caro, sino de combinar buenas prácticas: réplicas, cifrado, monitorización, comprobaciones periódicas, separación de privilegios y capacidad real de restauración.

4. Arquitectura general

Cada participante tiene una instalación parecida:

• una Raspberry Pi que actúa como servidor;
• un disco duro SATA de 16 TB;
• un adaptador USB-SATA compatible con discos grandes;
• alimentación propia para el disco;
• una carcasa o rack físico;
• ventilación;
• acceso SSH con claves públicas;
• exportación local de archivos, en mi caso también por NFS;
• espacios cifrados;
• y tareas programadas de copia y verificación.

El esquema conceptual es este:

Figura 1

Cada servidor tiene una doble función:

• servidor principal de datos locales;
• destino remoto de la copia cifrada del otro.

5. Modelo de réplica cruzada

El modelo básico de réplica es deliberadamente simple. Los datos se copian de manera periódica, normalmente durante la noche, mediante rsync.

En el caso habitual:

1. El servidor local contiene los datos principales.
2. Antes de la copia, se comprueba el estado del disco.
3. Si el disco parece estar en buen estado, se inicia la sincronización.
4. Los datos del otro se guardan cifrados.
5. El propietario físico del servidor remoto no puede leer el contenido real.

Figura 2

También es posible forzar una sincronización manual después de copiar muchos datos. Esto reduce la ventana de riesgo entre el momento en que un dato nuevo aparece en el servidor local y el momento en que queda replicado remotamente.

rsync permite limitar fácilmente el ancho de banda (--bwlimit), pero en la práctica no lo hacemos: cada nodo dispone de 1 Gbps y las copias se lanzan de noche, así que nunca hemos notado pérdida de rendimiento ni en la red doméstica ni en la conexión entre las dos casas. Si algún día esto cambiara, activar el límite sería trivial.

6. RPO: cuántos datos podemos perder

En el estado actual, el sistema tiene un RPO aproximado de un día para los datos que solo se sincronizan durante la noche.

RPO significa Recovery Point Objective: el máximo periodo de datos que se asume que se podría perder en un desastre. Si la copia se hace cada noche, la pérdida máxima habitual es lo que se ha modificado desde la última copia correcta.

En la práctica:

• si la copia nocturna ha ido bien, puedo perder como máximo los datos del mismo día;
• si después de copiar muchos datos ejecuto manualmente una sincronización, reduzco esa ventana;
• si la copia falla y no lo detecto, el RPO real empeora.

Esto hace que la monitorización no sea un detalle secundario. No basta con “tener copias”: hay que saber que las últimas copias han terminado correctamente.

7. Cifrado con GoCryptFS

Un punto esencial del proyecto es que cada participante aloja datos del otro, pero no debe poder leerlos.

Por eso, una parte de los datos remotos se guarda cifrada con GoCryptFS. Este sistema permite tener una representación cifrada de los archivos en disco, mientras que el propietario puede montarlos de manera transparente cuando necesita acceder a ellos.

Esto aporta varias ventajas:

• el disco se puede retirar, sustituir o destruir sin exponer los datos;
• el propietario físico del servidor no puede inspeccionar el contenido real de la copia del otro;
• la copia se puede hacer con herramientas estándar, porque al final se copian archivos cifrados normales;
• el montaje puede hacerse localmente en la Raspberry Pi o remotamente desde otro ordenador.

Figura 3

En la práctica, es útil poder hacer el montaje desde un PC más potente. La Raspberry Pi es una máquina eficiente, pero el cifrado puede cargar la CPU. Si el proceso usa pocos hilos o la copia es intensiva, delegar parte del trabajo criptográfico en un ordenador más potente puede mejorar el rendimiento.

8. NAS, pero no solo NAS

Una parte de Tocho funciona como un NAS: un servidor de archivos accesible desde la red local. En mi caso, puedo montar los archivos por NFS y trabajar con ellos de manera natural desde Linux.

Esto es muy cómodo, pero también introduce un riesgo: si mi PC tiene acceso completo al sistema de archivos, un error mío, un script defectuoso o un ransomware podría modificar o borrar datos directamente.

Por eso es importante distinguir dos funciones:

1. NAS de trabajo, pensado para acceder cómodamente a archivos.
2. Sistema de copia de seguridad, pensado para conservar versiones y resistir errores o ataques.

Un NAS no es automáticamente una copia de seguridad. Si está montado permanentemente con permisos de escritura, forma parte de la misma superficie de riesgo que el PC.

9. Copias Borg: deduplicación, cifrado y versiones

Para reforzar la parte de copias, he empezado a usar BorgBackup. Borg es una herramienta de copia de seguridad con deduplicación, compresión y cifrado autenticado. Está pensada para hacer copias eficientes, porque después de la primera solo necesita almacenar los bloques que han cambiado.

Esta parte es especialmente importante porque introduce una diferencia conceptual respecto al uso clásico de un NAS.

Con NFS, trabajo directamente sobre archivos visibles. Con Borg, los ordenadores clientes crean archivos de copia versionados dentro de un repositorio. Esto permite conservar muchas versiones sin multiplicar linealmente el espacio usado.

Borg aporta tres propiedades muy valiosas:

• cifrado;
• deduplicación;
• snapshots lógicos.

Esto hace que sea mucho más adecuado para copia histórica que una réplica simple con rsync.

10. Claves SSH restringidas por ordenador

Cada ordenador que hace copias hacia el servidor tiene una clave SSH propia, creada específicamente para esa función.

Estas claves no deberían dar acceso general al servidor, ni permitir abrir una shell interactiva, ni administrar el sistema. La idea es que cada clave solo permita ejecutar el servicio necesario para añadir copias al repositorio Borg correspondiente.

Borg soporta el uso de borg serve con órdenes forzadas vía SSH, que es precisamente el patrón adecuado para este tipo de configuración.

En concreto, esto se consigue limitando cada clave a una orden concreta dentro del fichero authorized_keys. Si se antepone command="<orden autorizada>" delante de la clave pública, el servidor solo ejecutará esa orden cuando alguien se conecte con la clave, aunque el cliente intente lanzar otra. De este modo, una clave pensada para hacer copias no puede abrir una shell interactiva, recorrer el sistema de archivos ni borrar datos de forma arbitraria. Es una pieza clave para reducir el riesgo de ransomware y otros escenarios de ataque.

El esquema es aproximadamente este:

Figura 4

Esto reduce mucho el riesgo en caso de que un portátil, un PC u otra máquina cliente quede comprometida. Si un atacante obtiene la clave de esa máquina, no debería poder entrar libremente al servidor ni borrar cualquier cosa.

11. Modo append-only y defensa contra ransomware

Una de las motivaciones recientes del proyecto es mejorar la protección frente a ransomware.

El problema de un NAS tradicional es que, si los archivos están montados con permisos de escritura desde el PC principal, un ransomware podría cifrar o destruir también los datos del NAS. En ese caso, el NAS dejaría de ser una copia de seguridad real y pasaría a ser una extensión vulnerable del propio ordenador.

Para reducir este riesgo, los repositorios Borg pueden configurarse en modo append-only. La documentación de Borg explica que este modo es útil cuando una máquina cliente hace copias remotas hacia un servidor con borg serve, porque una máquina cliente comprometida no puede eliminar permanentemente las copias del servidor.

La separación es clave:

• los clientes pueden añadir copias;
• los clientes no deberían poder destruir el histórico;
• la poda de versiones antiguas debe ser una operación separada;
• un ataque desde un ordenador cliente no debería poder eliminar todas las copias buenas.

Esto no elimina todos los riesgos. Un atacante podría añadir copias malas o cifradas, y habría que detectar el problema antes de hacer una poda destructiva. Pero es una mejora muy importante respecto a tener un directorio NFS montado permanentemente con acceso completo.

12. Separación entre datos vivos y copias de seguridad

Una idea de futuro es reducir el uso del servidor como almacén de archivos directamente manipulables y convertirlo cada vez más en un almacén de copias Borg.

Esto implica distinguir entre:

1. Datos vivos, que se pueden abrir, editar, mover o borrar desde el PC normal.
2. Copias de seguridad, que solo se añaden al repositorio y no son modificables directamente por la cuenta de usuario habitual.

Esta separación es muy sana. Los datos vivos pueden estar en discos locales, por ejemplo en un disco de 4 TB o en un disco interno de 2 TB. El servidor Tocho, en cambio, puede dedicarse sobre todo a guardar versiones Borg cifradas y deduplicadas.

El objetivo es pasar de este modelo:

Figura 5

a este otro:

Figura 6

Si la cuenta normal del usuario comete un error, ejecuta un rm demasiado amplio o queda comprometida, no debería tener acceso directo a destruir todas las copias históricas.

13. Copias incrementales y sincronización parcial

Una pregunta abierta es si se pueden hacer copias incrementales sin tener que recorrer todo el árbol de archivos cada vez.

Con rsync, el modelo normal es comparar origen y destino para decidir qué ha cambiado. Esto es robusto, pero puede ser costoso si hay muchísimos archivos.

Hay varias estrategias posibles:

• lanzar sincronizaciones manuales de carpetas concretas después de cambios importantes;
• hacer copias Borg de los conjuntos de datos realmente importantes;
• usar listas de archivos modificados recientemente con find, aunque esto es más frágil;
• separar mejor los datos por frecuencia de cambio: archivos fríos, datos activos y copias críticas;
• considerar sistemas con snapshots nativos si en el futuro se usa Btrfs o ZFS.

En general, para copia de seguridad versionada, Borg es más adecuado que una réplica simple con rsync. Para réplica de un árbol de archivos navegable, rsync sigue siendo muy sencillo y práctico.

14. Acceso nativo desde Linux y soberanía sobre los archivos

Una de las ventajas más importantes de Tocho es que me permite trabajar con mis archivos de manera nativa en Linux.

A diferencia de algunos servicios comerciales de nube, el sistema no me obliga a pasar por una interfaz web, una aplicación propietaria o una capa de integración ajena. Puedo montar sistemas de archivos con herramientas estándar, acceder con NFS, SSHFS, GoCryptFS o Borg, automatizar tareas con scripts y decidir exactamente cómo quiero organizar los datos.

Esto tiene un valor práctico enorme. Para un usuario de Linux, el sistema de archivos no es solo un lugar donde dejar documentos: es una interfaz universal. Las mismas herramientas que uso para programar, indexar, buscar, comparar, versionar o transformar datos pueden operar directamente sobre mis archivos.

Google Drive es un buen contraejemplo. A pesar de ser un servicio muy popular, Google no ofrece un cliente oficial completo de Google Drive para Linux. De hecho, hay una página mantenida por la comunidad, How long since Google said a Google Drive Linux client is coming?, que cuenta el tiempo transcurrido desde el 24 de abril de 2012, cuando Google dio a entender que llegaría soporte para Linux con el mensaje “hang tight”.

Esta ausencia obliga a los usuarios de Linux a depender de herramientas no oficiales o de soluciones parciales. Algunas funcionan muy bien, como rclone, pero no dejan de ser capas alternativas alrededor de un servicio que no está pensado principalmente para mi flujo de trabajo.

Con Tocho, en cambio, la situación es la contraria: yo controlo el servidor, el protocolo, el sistema de archivos, el cifrado, los permisos y los automatismos. No dependo de que una empresa decida si Linux merece o no una integración de primera clase.

Esta es una forma concreta de soberanía técnica: no solo poseer los datos, sino poder decidir cómo se accede a ellos.

15. Lo que todavía no tenemos: gestión nativa de fotografías

Ahora bien, esta soberanía todavía no es completa en todos los ámbitos.

Un punto pendiente es la gestión de fotografías. Los servicios comerciales han resuelto muy bien la parte de experiencia de usuario: subida automática desde el móvil, álbumes compartidos, miniaturas, línea temporal, reconocimiento de duplicados, compartición sencilla y acceso cómodo desde cualquier dispositivo.

Tocho todavía no ofrece una alternativa propia a eso. Puede guardar fotografías como archivos, naturalmente, pero no proporciona todavía una experiencia comparable a Google Photos, iCloud Photos o servicios parecidos.

Un paso futuro interesante sería desplegar una solución propia para fotografía, capaz de:

• recibir copias automáticas desde el móvil;
• generar miniaturas;
• organizar álbumes;
• compartir fotos y álbumes fácilmente con amigos y familiares, de manera controlada;
• mantener las imágenes dentro de la infraestructura propia;
• integrarse con el sistema de copias y réplicas ya existente.

Esta parte sería una evolución natural del proyecto: pasar de “tengo los archivos guardados” a “tengo también servicios personales encima de mis archivos”.

16. Hardware utilizado

Cada instalación está formada aproximadamente por:

• Raspberry Pi;
• disco duro SATA de 16 TB;
• adaptador USB-SATA compatible con discos grandes;
• fuente de alimentación adecuada para el disco;
• caja, rack o soporte físico;
• ventilación adicional;
• conexión de red doméstica con fibra.

Un detalle importante es que no todos los adaptadores USB-SATA funcionan correctamente con discos de gran capacidad. En algunos casos puede haber limitaciones del chipset, del firmware, del tipo de puente USB-SATA, del soporte UASP, de la gestión de sectores grandes o simplemente problemas de compatibilidad con discos modernos de muchos terabytes.

Por eso fue necesario elegir un adaptador más fiable, aunque fuera más caro.

17. Refrigeración, ruido y estabilidad física

La temperatura del disco es un factor importante para la longevidad y la estabilidad del sistema.

En mi caso, el disco está montado dentro de una estructura metálica pensada para varios discos, aunque actualmente solo utilizo uno. Esto proporciona más masa metálica y, por lo tanto, más capacidad de disipación.

Además, el rack dispone de un ventilador controlado por PWM desde la Raspberry Pi. Esto permite ajustar la velocidad del ventilador, reducir el ruido y mantener el disco a una temperatura razonable.

Figura 7

El objetivo no es enfriar agresivamente, sino evitar que el disco trabaje caliente durante muchas horas. Un disco que se mantiene templado y estable es preferible a un disco sometido a picos térmicos o a ventilación deficiente.

18. El caso del ventilador: cuando el plug and play no lo es

Otra lección del proyecto es que el hardware doméstico raramente es tan plug and play como promete.

En mi caso, compré una carcasa o rack que teóricamente ya venía preparado, con ventilador incluido. La idea era sencilla: montar el disco, conectarlo todo y dejar que el sistema funcionara.

Pero el ventilador que venía de serie tenía un comportamiento claramente defectuoso: lo que se calentaba era el propio ventilador, no el disco que debía refrigerar. En vacío, sin una carga real que lo justificara, el ventilador llegaba a aproximadamente 70 °C en pocos segundos. Es decir, no era el disco el que estaba a 70 °C, sino el ventilador mismo, algo que no era ni aceptable ni seguro.

Aprovechando que había que sustituirlo, cambié el ventilador original, de aproximadamente un centímetro de grosor, por otro de dos centímetros. Los ventiladores más gruesos pueden mover aire con menos esfuerzo y, en general, pueden ser más silenciosos para un mismo caudal. Esto era importante porque el servidor está instalado en el salón, donde el ruido es un factor real.

El cambio tampoco fue inmediato. Tuve que usar la impresora 3D para fabricar cilindros o separadores adaptadores que permitieran montar correctamente el ventilador nuevo en la carcasa existente.

Este episodio resume muy bien el carácter del proyecto: sobre el papel, parece solo “una Raspberry Pi con un disco”. En la práctica, aparecen muchos detalles pequeños pero importantes:

• compatibilidad del adaptador USB-SATA;
• alimentación del disco;
• temperatura;
• ruido;
• vibraciones;
• montaje físico;
• flujo de aire;
• piezas adaptadas;
• control PWM;
• ubicación dentro de casa.

Cada detalle puede parecer menor, pero todos juntos separan un montaje improvisado de un sistema razonablemente fiable.

19. Monitorización y comprobaciones

El sistema incorpora varias comprobaciones periódicas.

Antes de iniciar una copia importante, se consulta el estado del disco con smartctl. Si el disco informa de un estado problemático o de prefallo, la copia se puede omitir para evitar escribir sobre un soporte potencialmente defectuoso o agravar una situación delicada.

Además, hay una comprobación horaria que verifica que la máquina está accesible y que el disco continúa montado o disponible. Esta comprobación consulta también el espacio libre mediante df.

Una vez al día, alrededor de las 7 de la mañana, se envía un mensaje por Telegram con el estado general. De esta manera, los problemas importantes no quedan silenciosos durante semanas.

De momento, Telegram no nos ha fallado nunca. Además, este mensaje diario funciona como una especie de interruptor de hombre muerto: lo miramos cada mañana a las 7, así que, si algún día no llegara, la propia ausencia sería la alarma y nos preocuparíamos de inmediato.

Figura 8

Un punto que hay que reforzar es la revisión habitual del estado de las copias. No basta con generar logs: hay que conseguir que el estado final sea visible.

Una mejora clara sería incorporar al mensaje diario de Telegram información como esta:

• última copia correcta de cada máquina;
• duración de cada copia;
• cantidad de datos añadidos;
• número de archivos procesados;
• estado del repositorio Borg;
• resultado del último borg check, si se ejecuta periódicamente;
• espacio libre restante;
• estado SMART y temperatura del disco;
• el desfase horario entre los nodos (todos se ponen en hora por NTP, pero verificarlo periódicamente ayuda a detectar problemas de reloj);
• aviso explícito si una copia lleva más de X días sin completarse.

Esto convertiría la monitorización en una herramienta de confianza real, no solo en una comprobación superficial de disponibilidad.

20. Gestión del reposo del disco

Los discos duros se pueden dormir después de un periodo corto de inactividad. Esto reduce consumo, ruido y desgaste mecánico, pero también introduce una tensión entre dos objetivos:

• no despertar el disco innecesariamente;
• detectar problemas con suficiente rapidez.

Por este motivo, conviene agrupar operaciones pesadas en franjas horarias concretas, especialmente las copias nocturnas. También hay que evitar comprobaciones demasiado intrusivas cada hora si eso obliga al disco a girar constantemente.

La regla práctica es que las comprobaciones frecuentes deberían ser ligeras, y las operaciones que despiertan claramente el disco deberían estar justificadas.

21. Repositorios Git cifrados con git-crypt

En el caso de Ismael, otra línea interesante ha sido el uso de repositorios Git con contenido cifrado mediante git-crypt.

git-crypt es una herramienta que permite cifrar de manera transparente determinados archivos dentro de un repositorio Git. Los archivos configurados como sensibles se guardan cifrados en el repositorio, pero los usuarios autorizados los ven descifrados en su árbol de trabajo. La descripción oficial del proyecto es precisamente “transparent file encryption in git”.

Esto es útil cuando se quiere mantener un repositorio Git normal, pero sin exponer secretos, configuraciones privadas, claves, datos personales o archivos que no deberían estar en claro.

Figura 9

Esto encaja bien con la filosofía general de Tocho: no confiar solo en el perímetro del sistema, sino cifrar también los datos según su uso concreto.

En otras palabras, hay varias capas de protección:

• GoCryptFS para árboles de archivos cifrados;
• Borg para copias versionadas, deduplicadas y cifradas;
• git-crypt para secretos o archivos sensibles dentro de repositorios Git;
• SSH con claves restringidas para limitar qué puede hacer cada máquina;
• separación entre datos vivos y copias históricas.

El patrón común es claro: cada herramienta protege una parte diferente del problema.

22. Riesgos cubiertos

Tocho cubre bastante bien varios escenarios de riesgo.

Avería de un disco

Si un disco falla, todavía hay una réplica en la otra ubicación. En ese caso, hay que comprar un disco nuevo y reconstruir la copia.

Robo

Si roban uno de los equipos, los datos del otro continúan estando en otra casa. Además, los datos alojados en el disco robado están cifrados.

Incendio o daño físico local

Una catástrofe que afecte a una sola ubicación no debería destruir todas las copias.

Error humano parcial

Si se borra accidentalmente algo y la copia todavía no se ha sincronizado, puede ser posible recuperarlo de la réplica anterior. Ahora bien, esta protección es limitada si la supresión o corrupción ya se ha propagado con rsync.

Compromiso de una máquina cliente

Con Borg append-only y claves SSH restringidas, una máquina cliente comprometida no debería poder eliminar permanentemente todas las copias históricas.

23. Riesgos no resueltos completamente

El sistema actual todavía tiene puntos débiles importantes.

Corrupción silenciosa

Si un archivo se corrompe y después se replica, la copia remota puede acabar conteniendo también la versión corrupta. rsync no es, por sí solo, un sistema de verificación histórica de la integridad.

Ransomware sobre datos vivos

Si una máquina cliente cifra o modifica masivamente los archivos visibles, y después se ejecuta una sincronización, el daño se puede propagar a la réplica.

Ausencia parcial de histórico

Una réplica simple protege contra la pérdida de un disco, pero no siempre contra errores lógicos. Para eso hacen falta snapshots, versiones antiguas o copias inmutables durante un periodo.

Ventana de vulnerabilidad

Entre una modificación local y la copia remota hay una ventana temporal en la que los datos nuevos todavía solo existen en un lugar.

Reconstrucción lenta

En caso de pérdida de un disco completo, reconstruir 16 TB puede ser lento. A 100 MB/s sostenidos, copiar 16 TB tarda aproximadamente 44 horas. En la práctica, puede ser más, porque el rendimiento real depende del disco, de la red, del cifrado, del protocolo y de la cantidad de archivos.

Por eso, en una reconstrucción completa puede ser más razonable llevar físicamente el disco a la otra casa y hacer la primera copia en local o por red local rápida.

24. Recuperación frente a un desastre

En caso de fallo completo de un disco, el procedimiento general sería:

1. Detectar el fallo mediante SMART, errores de E/S o ausencia del disco.
2. Marcar el nodo afectado como no fiable.
3. Detener las sincronizaciones automáticas hacia ese disco.
4. Comprar o instalar un disco nuevo.
5. Inicializar el sistema de archivos.
6. Restaurar la copia desde el otro servidor.
7. Verificar integridad y montaje del sistema cifrado.
8. Reactivar las copias nocturnas.

Durante la reconstrucción, el sistema queda en un momento más delicado, porque temporalmente puede haber una sola copia completa. Por eso hay que minimizar el tiempo de reconstrucción y evitar operaciones arriesgadas hasta que la redundancia quede restaurada.

25. Mejoras posibles

El proyecto ya es útil en su forma actual, pero hay varias mejoras posibles.

Estado persistente de “disco sospechoso”

Si smartctl detecta una situación de prefallo, no basta con omitir una copia concreta. Sería conveniente dejar el disco en un estado persistente de “bloqueado”, “sospechoso” o “requiere intervención manual”.

Esto evitaría que una ejecución posterior volviera a intentar copiar automáticamente hasta que alguien revisara el problema.

Tests SMART activos periódicos

Actualmente solo se leen los atributos SMART antes de cada copia, pero no se lanzan tests activos. Sería buena idea programar un test largo (smartctl -t long) una vez al mes: recorre toda la superficie del disco y puede detectar sectores defectuosos antes de que causen problemas. Como es una operación lenta que mantiene el disco despierto, conviene lanzarla en una franja nocturna y dejar constancia del resultado en el aviso diario.

Snapshots o versiones

Para protegerse mejor contra ransomware, borrados accidentales o corrupción lógica, sería interesante añadir algún mecanismo de versiones.

Algunas opciones serían:

• snapshots con Btrfs o ZFS;
• copias con rsnapshot;
• repositorios BorgBackup o Restic;
• hard links con estrategias tipo rsync --link-dest;
• retención de versiones diarias, semanales y mensuales.

Verificación de integridad

También sería útil disponer de un catálogo de hashes o de un sistema de verificación periódica que permita detectar corrupción silenciosa.

El reto es hacerlo sin despertar el disco continuamente ni convertir la verificación en una tarea demasiado costosa.

Detección de cambios sospechosos

Otra idea interesante sería un sistema que detectara automáticamente cambios sospechosos en los archivos antes de propagarlos a la réplica. Por ejemplo, si un archivo cambia de tipo —tal y como lo identificaría la herramienta file—, podría ser una señal de corrupción o de cifrado por ransomware: un documento que de repente pasa a ser un binario opaco, o un montón de archivos que cambian de tipo a la vez, es un patrón anómalo. Detectarlo permitiría pausar la sincronización y avisar antes de que el daño llegue a la copia remota.

Pruebas de restauración

Una copia de seguridad que no se ha restaurado nunca es solo una hipótesis. Por eso sería saludable hacer pruebas periódicas de restauración, aunque sean parciales.

Por ejemplo:

• restaurar un directorio aleatorio;
• verificar que GoCryptFS se puede montar desde otra máquina;
• verificar que Borg puede restaurar archivos antiguos;
• documentar los pasos de recuperación;
• confirmar que las claves necesarias están disponibles.

26. Lecciones aprendidas

Una de las lecciones más importantes del proyecto es que montar una alternativa propia a servicios de nube no es gratis, aunque no se pague una cuota mensual.

El coste no es solo el disco. También hay que tener en cuenta:

• el precio de los discos grandes;
• adaptadores USB-SATA compatibles y fiables;
• fuentes de alimentación;
• cajas, racks o soportes físicos;
• refrigeración;
• ruido;
• consumo eléctrico;
• tiempo de administración;
• monitorización;
• pruebas de restauración;
• gestión de claves;
• documentación;
• respuesta frente a incidentes.

Por eso, estar en contra de pagar por un servicio de nube solo porque “lo puedo hacer yo gratis” es una simplificación peligrosa. La realidad es que hacerlo bien exige dinero, tiempo y conocimiento.

La conclusión no es que la nube sea siempre mejor. La conclusión es más matizada: la nube comercial puede parecer cara hasta que cuentas todo lo que implica operar tú mismo una infraestructura fiable.

En nuestro caso, Tocho tiene sentido porque aprendemos, controlamos los datos, tenemos capacidad técnica y nos interesa el proceso. Pero no es una solución mágica ni gratuita. Es infraestructura real, aunque esté hecha en casa.

27. Dirección futura del proyecto

La dirección natural de Tocho es evolucionar desde un NAS replicado hacia un sistema híbrido:

• NAS para archivos grandes y acceso cómodo;
• Borg para copias versionadas;
• claves SSH restringidas por máquina;
• append-only para reducir el riesgo de destrucción remota;
• poda controlada desde el servidor;
• monitorización diaria realmente accionable;
• separación entre datos vivos y copias históricas;
• servicios personales encima de los archivos, como una futura gestión propia de fotografías.

Esta evolución hace que el sistema sea más resistente no solo frente a averías físicas, sino también frente a errores humanos, scripts defectuosos y ataques de ransomware.

28. Resumen: pasos para montar tu propio Tocho

Si alguien quiere replicar una configuración parecida, estos son los pasos básicos, en orden aproximado:

29. Resumen visual final

Figura 10

30. Conclusión

Tocho es un sistema doméstico de almacenamiento y copia de seguridad distribuida que combina NAS, réplica remota, cifrado y copias versionadas.

Su valor no está solo en los terabytes disponibles. Está en el control: control sobre dónde están los datos, quién puede leerlos, cómo se montan, cómo se copian, cómo se monitorizan y cómo se restauran.

Su evolución natural es reducir el acceso directo a los archivos críticos y aumentar el peso de repositorios append-only, más resistentes a errores humanos y ransomware.

En resumen, Tocho es una infraestructura personal de soberanía técnica: no perfecta, no gratuita y no trivial, pero comprensible, reparable y adaptada a nuestra manera real de trabajar.