← Todas las funciones

Recursos compartidos de archivos (SMB y NFS)

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-21

Restow copia recursos compartidos SMB (un servidor Windows, Samba, un NAS) y exportaciones NFS desde el servidor de Restow, sin agente en el servidor de archivos, y los restaura con sus permisos. Forma parte del núcleo Community, así que todas las ediciones lo tienen, y está disponible desde la 0.4.0 (beta). Como cualquier otra fuente, se valora en la preparación de recuperación mediante una comprobación de restauración que relee su copia.

Cómo se copia un recurso compartido

En cada ejecución, el mounter, un contenedor opcional de Restow (las instalaciones nuevas lo arrancan por defecto), inicia un contenedor runner de vida corta. El runner monta el recurso solo de lectura, lo copia con restic en un repositorio propio (file-shares/<share id>/ en el repositorio principal del inquilino), anota los permisos en el mismo punto de restauración y se elimina de nuevo. Las ejecuciones son incrementales y deduplicadas, como las demás copias restic de Restow. Añadir, probar, copiar o restaurar un recurso nunca reinicia la API ni el worker. Desde la 0.4.2, la página de un recurso y su editor de trabajos nombran el repositorio en el que acaban las copias, y el diálogo que añade un recurso avisa «Las copias acaban en el propio disco del servidor» cuando el repositorio principal es un directorio en un disco del propio servidor de Restow.

Desde la 0.4.2, una ejecución de un recurso compartido se puede cancelar desde el panel de ejecución, como ya se podían las de Microsoft 365 e IMAP. Termina como cancelada, no como fallida: sin alerta de fallo, y no cuenta como la última copia. Cada parada pregunta antes y queda en el registro de auditoría.

Los archivos abiertos en exclusiva, ilegibles o sin conexión se omiten y se enumeran en la ejecución por causa; la ejecución termina entonces «con advertencias», y en la página de advertencias puede confirmar lo que se esperaba. Un recurso que de pronto está vacío, cuando el punto de restauración anterior no lo estaba, no se copia (un punto de restauración vacío dejaría que la retención borrase los buenos); «Copiar una vez el recurso vacío» lo permite de forma deliberada.

Qué hace falta

• El mounter. Las instalaciones nuevas lo arrancan por defecto (la opción del instalador --no-mounter lo deja apagado). En una instalación existente, el propietario del proveedor pulsa «Activar los recursos de red» cuando el actualizador opcional está en marcha, o ejecuta docker compose --profile mounts up -d mounter. Tras actualizar a la 0.4.0, ejecute de nuevo el install.sh de la 0.4.0, para que el docker-compose.yml tenga los cambios que necesitan las ejecuciones de recursos compartidos. El mounter tiene el socket de Docker, es decir, acceso equivalente a root en el host: lea las notas de seguridad del mounter (en inglés) antes de activarlo.
• El cliente del host Docker. El núcleo del host monta el recurso, así que necesita el módulo cifs para SMB o el cliente NFS para NFS, y debe llegar al servidor de archivos: TCP 445 para SMB, TCP 2049 para NFS (NFSv3 necesita además el portmapper y el demonio de montaje).
• Una cuenta. Para SMB, una cuenta de dominio o local que pueda leer todo lo que se copia. Lo mejor es un miembro de Operadores de copia de seguridad (Backup Operators) en Windows, que lee también archivos cuyos permisos la excluirían, junto con sus permisos. Para restaurar en el recurso necesita acceso de escritura. En NFS, la exportación debe admitir el host Docker; con root_squash se omiten los archivos que solo root puede leer, así que exporte con no_root_squash para una copia completa.

La guía de operación, con los requisitos, las causas de error y qué hacer en cada caso, es docs/FILESHARES.md en el repositorio del producto (en inglés).

Añadir un recurso y su trabajo de copia

«Recursos compartidos» está en el menú junto a «VMs y contenedores». «Añadir recurso compartido» pide el protocolo, el servidor, el recurso o la exportación, una subcarpeta opcional, la cuenta y la contraseña, prueba la conexión (y si los permisos se pueden leer) y guarda el recurso. La contraseña se sella con la clave del inquilino y no se vuelve a mostrar. Después pone el recurso en un trabajo de copia del tipo «Recursos compartidos»: una planificación (como máximo cada hora), las carpetas que se copian (todas por defecto), tipos de archivo que se omiten y la retención en puntos de restauración diarios, semanales y mensuales, como en los equipos. Un recurso que no está en ningún trabajo no se copia, y Restow lo dice.

Los administradores del inquilino gestionan sus propios recursos. Un recurso en una dirección privada o de bucle local, como lo son la mayoría de los servidores de archivos, necesita la aprobación de un administrador del proveedor o el interruptor de la instalación «Los inquilinos pueden añadir recursos en redes privadas».

Restauración

Desde un punto de restauración puede explorar, buscar y ver las versiones de un archivo, y luego elegir una de cuatro vías: descargar como ZIP (sin el registro de permisos), restaurar en una carpeta nueva del mismo recurso, restaurar en la ubicación original (sobrescribir, conservar ambos u omitir los archivos existentes) o restaurar en otro recurso. Una restauración devuelve los permisos donde el destino lo permite y enumera los archivos cuyos permisos no se pudieron establecer. Las restauraciones en un recurso necesitan «Permitir restaurar en este recurso», que está desactivado por defecto. Los usuarios de inquilino todavía no tienen restauración de autoservicio de recursos compartidos.

Restaurable con comprobación

Cada punto de restauración nuevo se comprueba: Restow relee hasta 20 archivos de muestra y los compara con lo copiado. Un punto de restauración sin muestras, porque todos los archivos cambiaron en la hora previa a la ejecución, se valora en amarillo y dice por qué. Además, el repositorio recibe cada semana un restic check del 5 por ciento de sus datos. La preparación de recuperación valora un recurso por su punto de restauración más reciente, el mismo estado que se usa para buzones y equipos. Véase la página de verificación.

Cada punto de restauración nuevo se juzga además en busca de señales de ransomware: la cantidad de cambios, los borrados, las extensiones renombradas, los nombres conocidos y los archivos de muestra que parecen cifrados. Detalles en la página de detección de ransomware.

Trabajos de copiado

Un trabajo de copiado escribe, según una planificación, el punto de restauración más reciente del recurso A que superó su comprobación en una carpeta del recurso B. En el modo «Sobrescribir» añade y reemplaza archivos; en el modo «Reflejar» borra además lo que el punto de restauración no tiene, pero solo dentro de esa carpeta. Reflejar se rechaza en la raíz de un recurso o en el recurso de origen, y una ejecución se detiene si el punto de restauración tiene menos de la mitad de los archivos de la última copia. El recurso B debe permitir restauraciones. Un trabajo de copiado se etiqueta «No es una copia de seguridad: sin versiones en el destino»: el destino es un segundo lugar cómodo para los archivos actuales, no una segunda copia de seguridad.

Presupuestos

Se puede fijar un presupuesto por recurso, por inquilino y como valor por defecto para recursos nuevos. Está desactivado por defecto y es cosa de los administradores del proveedor. Al 80 por ciento el recurso avisa; al 100 por ciento se rechazan las copias nuevas; las restauraciones, la retención y las comprobaciones siguen funcionando.

Dónde aparecen los recursos compartidos

Un recurso en un trabajo activo se cuenta junto a buzones, equipos y VM: en la pestaña de estado, en la página de inicio, en la preparación de recuperación, en las advertencias, en el historial, en las estadísticas y en la vista de proveedor. Hay dos alertas para ellos: file_share_backup_failed y file_shares_without_job, y un recurso atrasado genera backup.overdue. Cuáles llegan a qué canal se fija en la matriz de notificaciones, en Integraciones, Notificaciones.

Inmutabilidad

Si activa las copias inmutables en el repositorio principal del inquilino (véase almacenamiento), los repositorios restic de los recursos compartidos también quedan bloqueados. Un recurso cuyo repositorio sigue bloqueado no se puede purgar antes de que termine el bloqueo.

Límites declarados, no ocultos

• No hay instantánea de volumen (VSS) por SMB: los archivos que otro programa mantiene abiertos en exclusiva se omiten. No hay flujos de datos alternativos, ni espacios de nombres DFS, ni Kerberos, ni SMB1.
• Los repositorios están solo en el repositorio principal. Los repositorios de copia no cubren los recursos compartidos. Un «traslado» del repositorio principal se los lleva (0.4.2), y «mantener las copias existentes donde están» se rechaza mientras haya recursos compartidos con repositorios de restic.
• Un recurso compartido cuyo repositorio ha desaparecido todavía no se repara como un contenedor (una cadena de copias nueva). Está previsto.
• Los usuarios de inquilino todavía no tienen restauración de autoservicio de recursos compartidos, y los informes programados todavía no tienen un bloque de recursos compartidos.
• Los runners se ejecutan en el host Docker de Restow, no cerca del servidor de archivos. Un servidor de archivos al que solo se llega por un enlace lento se copia por ese enlace.
• La copia de recursos compartidos se probó con Samba en las comprobaciones de la versión (comprobación 12: copiar, explorar, buscar, descargar ZIP, restaurar con permisos, trabajo de copiado). No se probó con Windows Server (permisos NTFS, Backup Operators, un archivo abierto en Excel), un recurso Synology o TrueNAS, exportaciones NFS reales (NFS no está en esa comprobación) ni un host con SELinux en modo enforcing.
• El mounter tiene el socket de Docker, así que activarlo es una decisión de seguridad. Restow es una beta: úselo junto a su copia de seguridad actual hasta que haya restaurado usted mismo desde él.

Preguntas frecuentes

Cómo se juzga cada punto de restauración en busca de ransomware →

Copia de servidores y equipos con un agente →

Más en Aprender: la regla 3-2-1 de copias de seguridad y dónde encaja un servidor de archivos →

Más en Aprender: elegir almacenamiento para copias →