← Todas las funciones

Copia de servidores y equipos

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

Restow hace copia de seguridad de servidores Linux y macOS y de equipos cliente con un agente pequeño que maneja restic, hacia su propia instancia de Restow. Forma parte de la edición Community, así que está en todas las ediciones, y está disponible desde la 0.1.0 (beta). Las copias son a nivel de archivo, se almacenan deduplicadas y cifradas, y se comprueban igual que las copias de buzones: una copia que nunca se ha leído de vuelta no se da por probada.

Qué hace

El agente es un programa pequeño en Go para Linux (systemd, x86_64 y aarch64) y macOS 13 o posterior (Intel y Apple Silicon). Copia las carpetas que usted elija con restic 0.19.1 a un repositorio en su instancia de Restow, deduplicadas, comprimidas y cifradas. Es a nivel de archivo a propósito: sin imágenes de disco y sin restauración completa del sistema (bare metal). Restaurar un equipo entero supone reinstalar el sistema operativo y restaurar los archivos.

Cómo se añade un equipo

En la interfaz web de Restow usted da de alta un servidor nuevo o un equipo cliente nuevo. Restow muestra un comando con un token de un solo uso; el token es válido durante 24 horas y se puede usar una única vez. Usted copia el comando y lo ejecuta con sudo en el equipo. El script de instalación lo sirve su propia instancia: descarga el agente y restic de esa instancia, comprueba el SHA-256 de ambos binarios antes de instalar nada, configura el servicio (systemd o launchd), registra el equipo y lo inicia. Volver a ejecutarlo repara o actualiza en el mismo sitio. Como el token llega al script como variable de entorno de sudo, queda visible durante unos instantes en la lista de procesos de ese equipo; es de un solo uso y caduca.

El agente abre conexiones HTTPS salientes hacia su instancia de Restow y hacia nada más, y no abre ningún puerto en el equipo. En macOS usted concede al agente el acceso total al disco en los ajustes del sistema; sin él, las carpetas protegidas se omiten y la copia se notifica como parcial, con el motivo en el registro de la ejecución.

Por qué el agente no puede destruir sus propias copias

El modo solo anexado lo impone su instancia de Restow, no se deja a la buena conducta del agente. El agente escribe en un repositorio restic que la instancia ofrece en modo solo anexado: puede añadir copias, pero no borrarlas ni sobrescribirlas. Las pruebas de extremo a extremo de Restow comprueban que forget, prune, borrar y sobrescribir con el acceso del agente son rechazados y que los bytes almacenados no cambian. La retención, la depuración y las comprobaciones de integridad se ejecutan únicamente en el servidor de Restow.

El agente nunca guarda credenciales del destino de almacenamiento, como claves de S3 o rutas de montaje. Solo conoce su propio secreto de agente y la contraseña de su propio repositorio. Cada equipo tiene un repositorio y una contraseña aleatoria; el servidor guarda esa contraseña cifrada con la clave del inquilino, de modo que un administrador aún puede restaurar cuando el propio equipo ya no existe.

Restauración

Una restauración en el equipo va siempre a una carpeta nueva y nunca sobre archivos existentes: el destino no debe existir o debe estar vacío; de lo contrario la ejecución falla y no se toca nada. La alternativa es explorar una copia en la interfaz de Restow y descargar archivos o carpetas como ZIP. La exploración, las descargas y las solicitudes de restauración quedan en el registro de auditoría. El repositorio es un repositorio restic corriente, de modo que es posible restaurar sin Restow con la contraseña del repositorio. Un administrador puede hacer que Restow muestre esa contraseña; guarde una copia en un gestor de contraseñas, porque sin la base de datos de Restow y su clave maestra la contraseña no se puede reconstruir. Las reglas generales de restauración están en la página de restauración.

Restauración probada

Después de cada copia, el agente anota el SHA-256 de hasta 20 archivos al azar. Más tarde el servidor restaura esos archivos desde la instantánea y compara los hashes; el resultado es verde solo si coinciden. Ese resultado alimenta la preparación de recuperación (Recovery Readiness), el mismo estado que se usa para los buzones, de modo que un equipo solo figura como probado cuando su última copia se ha leído de vuelta. Hay más sobre el enfoque en la página de verificación.

Cada semana el servidor comprueba además cada repositorio, leyendo una veinteava parte de los datos en cada ejecución, de modo que todo el repositorio se lee a lo largo de unos cinco meses. La retención también se ejecuta en el servidor; por defecto conserva 30 copias diarias, 12 semanales y 12 mensuales, y se puede cambiar por equipo.

Alertas

Restow genera una alerta, por los mismos canales que cualquier otro trabajo (campana, correo, webhook), cuando:

• un servidor guarda silencio: por defecto, más de 2 horas sin contacto;
• un equipo cliente lleva tiempo sin una copia correcta: por defecto 7 días, porque un portátil está apagado por la noche;
• falla una copia o falla una restauración en un equipo;
• falla una prueba de restauración o una comprobación del repositorio detecta daños.

Perfiles y hooks

El perfil Servidor hace copia a diario (la hora por defecto es las 22:00). El perfil Cliente hace copia cuando el equipo alcanza su instancia de Restow, como máximo una vez cada 4 horas, y se puede limitar el ancho de banda y configurar para que solo se ejecute con corriente alterna (la detección es de mejor esfuerzo). Los hooks opcionales previos y posteriores ejecutan comandos alrededor de una copia, por ejemplo un volcado de base de datos. Los hooks se ejecutan como root y son una función de administrador: quien pueda cambiar la configuración de un equipo en Restow puede ejecutar comandos como root en ese equipo, así que trate ese acceso en consecuencia.

Límites indicados, no ocultos

• Todavía no hay agente para Windows. Está previsto, véase la hoja de ruta.
• Todavía no hay instantáneas LVM, ZFS ni btrfs, ni instantáneas APFS en macOS. La coherencia depende de los hooks opcionales (un volcado de base de datos, por ejemplo); los archivos que cambian mientras se leen pueden quedar incoherentes en la instantánea.
• Todavía no hay mTLS: cada agente se autentica con su propio secreto por HTTPS. Un secreto robado no permite borrar nada.
• No hay copias de imagen ni de sistema completo (bare metal), a propósito: la copia es a nivel de archivo.
• El agente se ejecuta como root, porque tiene que leer cada archivo que copia.
• El agente busca actualizaciones cada 6 horas y verifica cada una con SHA-256. La suma de comprobación procede de su propia instancia, así que protege frente a descargas dañadas, no frente a una instancia comprometida, y las actualizaciones del agente no están firmadas.
• Esto es una beta (0.1.0). Utilícela junto a sus copias de seguridad actuales hasta que usted mismo haya restaurado desde ella.

Documentación

La guía del administrador (en inglés) incluye la descripción general y los pasos de instalación, con el permiso necesario en macOS.

Preguntas frecuentes

Vea cómo funciona la restauración →