← Todas las funciones

Copia de servidores y equipos

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

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. Hoy es a nivel de archivo: todavía 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; la copia de imagen con restauración completa está prevista.

restic es el conocido programa de copias de seguridad de código abierto que está detrás del agente: rápido, con deduplicación, cifrado y con un formato de repositorio abierto. Restow entrega su versión oficial sin modificar, comprobada con sumas de verificación fijadas, así que la copia de un equipo es un repositorio restic normal que el propio restic puede abrir con la contraseña del repositorio, también sin Restow. restic es un proyecto de código abierto independiente (BSD-2-Clause, restic.net); Restow no está afiliado a él.

Las máquinas virtuales y los contenedores de Proxmox VE no se copian con este agente, sino mediante la propia Backup Provider API de Proxmox, como vista previa, véase copia de Proxmox VE.

Trabajos de copia para equipos

Los equipos se copian mediante trabajos de copia. Un trabajo define qué se copia, cuándo, en qué repositorio, durante cuánto tiempo y cada cuánto lo demuestra una comprobación de restauración, para muchos equipos a la vez, con excepciones por equipo. En servidores y equipos cliente usted elige las carpetas que se copian y excluye tipos de archivo. Puede limitar el ancho de banda de una copia, dentro de una franja horaria que usted defina. Los hooks, el ancho de banda y la programación de un equipo que está en un trabajo se definen en el trabajo.

Un equipo se copia cuando está en un trabajo. Cada equipo sin trabajo aparece marcado como «Sin copia», se cuenta en un aviso y ofrece «Crear un trabajo» o «Añadir a un trabajo», y un equipo recién inscrito espera a un trabajo en lugar de copiarse por su cuenta. Los servidores copian por defecto sus datos de aplicación (/opt, /usr/local, /var/lib). Una tabla de todos los equipos muestra el nombre de host, la persona a la que está asignado cada equipo, la última copia y la preparación de recuperación.

Desde la 0.3.5, en los equipos Linux, un aviso en el trabajo y en la restauración de archivos nombra las carpetas de datos habituales (/opt, /srv, /var/lib, /home y otras) que las rutas del trabajo dejan fuera, con un botón para añadirlas. Desde la 0.4.0, el agente comunica además cuáles de una lista fija de carpetas de datos de Linux (/opt, /usr/local, /srv, /var/www, volúmenes de Docker y Podman, las carpetas de PostgreSQL, MySQL y MongoDB bajo /var/lib) existen y contienen archivos, solo los nombres. El editor del trabajo nombra entonces las carpetas que los equipos del trabajo realmente tienen y el trabajo deja fuera, y la página de un equipo tiene un botón para añadir cada una al trabajo. Con agentes más antiguos se mantiene el aviso de la 0.3.5. La página de un equipo dice también qué es: contenedor, máquina virtual o físico, con o sin escritorio. Un equipo Linux registrado con un token de cliente cuyo agente comunica un contenedor o una máquina virtual sin escritorio recibe el perfil de servidor, porque ejecuta servicios; la página dice por qué.

Los trabajos en curso se actualizan solos, sin recargar la página, y una ejecución abre un panel de detalle con gráficos de su caudal de datos. El historial lista cada ejecución, también las de los agentes en sus servidores y equipos, con filtros por tipo (copia, restauración, comprobación de restauración, exportación, importación, mantenimiento) y por trabajo.

Políticas de los agentes

Desde la 0.4.0, algunos ajustes de todos los agentes se pueden fijar una vez en lugar de por equipo, en tres niveles: la instalación (Instalación, Política de los agentes), el inquilino (la página del inquilino, Agentes) y el trabajo de copia (el editor del trabajo). Cada nivel puede sobrescribir un ajuste salvo que la instalación lo bloquee, y cada vista dice de dónde viene un valor y si está bloqueado. Los ajustes son:

• una ventana de copia: días de la semana y un intervalo horario, también a través de la medianoche, en la zona horaria de la planificación del trabajo, en la que pueden empezar las copias programadas, las puestas al día y los reintentos. Una copia en curso continúa, y «Copiar ahora» ignora la ventana;
• poner al día las copias perdidas en cuanto el equipo vuelve a estar encendido o en la siguiente ventana de copia, opcionalmente solo hasta una antigüedad máxima;
• el límite de subida de un trabajo que no tiene uno propio (un trabajo también puede elegir «Sin límite», que deja de lado el límite de una política salvo que la instalación lo bloquee);
• solo con corriente alterna;
• el número de reintentos automáticos, de 0 a 10.

Sin política, los agentes se comportan exactamente como antes. La página de un servidor o equipo muestra la política que se le aplica, cada ajuste con su origen (valor por defecto, instalación, inquilino, trabajo de copia o el propio equipo) y si está bloqueado, solo de lectura, y por qué una copia pendiente espera, junto a su siguiente inicio previsto: por la ventana de copia, porque termine una actualización, por la corriente alterna o para ponerse al día en la siguiente ventana. Cada cambio queda en el registro de auditoría. La ventana, la puesta al día, los reintentos y el motivo de espera necesitan el agente 0.4.0; el límite de subida y la corriente alterna llegan también a agentes más antiguos.

Mientras una actualización de Restow pausa las ejecuciones nuevas, el agente 0.4.0 no inicia ninguna copia programada, reintento ni puesta al día y espera a que termine la pausa; la espera no cuenta como copia perdida ni fallida. Una solicitud «Copiar ahora» queda en cola en el servidor hasta que acaba la pausa, también para agentes más antiguos, y restow-agent backup-now en el equipo espera con un mensaje. restow-agent status muestra la política y por qué espera una copia pendiente. Los agentes anteriores a la 0.4.0 no respetan sus propias planificaciones durante una actualización: una copia que uno de esos equipos inicia por sí mismo en ese tiempo se ejecuta, y puede fallar si la API se reinicia debajo.

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 el comando de instalación y, por separado, un token de un solo uso que es válido durante 24 horas y se puede usar una única vez. Usted ejecuta el comando con sudo en el equipo; el script pide el token y lo lee sin mostrarlo, de modo que no aparece ni en la línea de comandos ni en la lista de procesos. Para instalaciones desatendidas (RMM, scripts), el script lee el token de un archivo que solo root puede leer. El script de instalación lo sirve su propia instancia: descarga el agente y restic de esa instancia, comprueba la firma del mantenedor sobre la lista de sumas de comprobación de la versión y el SHA-256 de ambos binarios antes de ejecutar nada, los instala en una carpeta que solo root puede modificar (/opt/restow-agent/bin en Linux, /Library/Application Support/Restow/bin en macOS), configura el servicio (systemd o launchd), registra el equipo y lo inicia. Volver a ejecutarlo repara o actualiza en el mismo sitio.

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 solo anexado protege frente al equipo. Frente a alguien en el servidor de Restow o con su clave de almacenamiento, el repositorio principal del inquilino se puede hacer inmutable desde la 0.4.0 (S3 con Object Lock): el almacenamiento bloquea entonces los objetos data, snapshots, keys y config del repositorio de cada equipo, pero no los archivos de bloqueo e índice de restic. Está desactivado hasta que un administrador lo activa, y el repositorio predeterminado de la instalación no se puede hacer inmutable. Véase almacenamiento.

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 (desde la 0.4.0 también por los operadores de restauración) 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: un ZIP puede contener hasta 10.000 rutas y las carpetas se exploran por páginas («Cargar más»). Una tarea de restauración a una carpeta nueva del equipo admite hasta 200 rutas. 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 (Restow pide un inicio de sesión reciente y anota el acceso en el registro de auditoría). La contraseña también se guarda junto al repositorio, sellada con la clave del inquilino, de modo que con la clave maestra de la instalación y el almacenamiento la herramienta de restauración independiente la recupera, sin un Restow en marcha. 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 vuelve a leer 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 punto de restauración nuevo de un equipo se juzga además en busca de señales de ransomware: la cantidad de cambios, los borrados, las extensiones renombradas, los nombres conocidos, los archivos de muestra que parecen cifrados y los datos que no se comprimen ni se deduplican. El informe de actividad necesita el agente 0.4.0. Un punto de restauración sospechoso pausa la retención de ese equipo hasta que un administrador lo resuelva. Véase detección de ransomware.

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. Qué se borra lo decide el servidor según sus propios registros de las ejecuciones de copia, no según las horas que el equipo escribe en sus instantáneas.

Cada equipo tiene un presupuesto de almacenamiento, 2 TiB por defecto y ajustable por equipo, y todos los equipos de un inquilino juntos 20 TiB. Una subida que ya no cabe se rechaza, las restauraciones siguen funcionando y una alerta avisa al 90 por ciento.

Detener una copia y actualizar el agente al momento

Desde la 0.4.2, «Detener copia» en la página de un equipo y en el panel de ejecución detiene una copia en curso, y «Retirar copia» retira un «Copiar ahora» que no ha empezado. Quien puede iniciar una copia puede detenerla; cada parada pregunta antes y queda en el registro de auditoría, con quién la pidió. El agente recibe la orden en su siguiente contacto (cada minuto mientras copia, y si no cada cinco minutos), detiene restic de forma limpia, de modo que no quedan ni instantánea ni bloqueo, y un post-hook se ejecuta como siempre. La ejecución termina como cancelada, no como fallida: sin alerta de fallo, sin webhook job.failed, la última copia y el recuento de copias fallidas se quedan como estaban, y la siguiente copia programada arranca con normalidad. Necesita el agente 0.4.2; un agente anterior no conoce la orden y termina su copia.

Además de la autoactualización cada seis horas, «Actualizar a <versión>» en la página de un equipo pide la actualización en cualquier momento, y sudo restow-agent update en el equipo instala la versión ofrecida al instante, con la misma descarga firmada, reinicia el servicio y dice lo que hizo. Mientras se ejecuta una copia, una restauración o una prueba de restauración, se niega, y el agente instala la actualización por sí mismo cuando queda libre. Cuando el servidor ejecuta una versión nueva, los agentes la siguen mientras las ejecuciones nuevas esperan, 15 minutos como máximo; la pestaña Actualizaciones muestra su progreso y nombra el comando para un agente que no se alcanzó.

Quitar un equipo

Desde la 0.4.5, un equipo revocado se puede quitar de Restow, con o sin sus copias. Quitar de Restow en la zona de peligro de la página del equipo ofrece Quitar de la lista y conservar las copias hasta que caduquen (la copia más reciente más la regla más larga de la retención del equipo, leída como tiempo) o Eliminar el equipo y sus copias. Ambas necesitan el nombre de host escrito y un inicio de sesión reciente, y el equipo tiene que estar revocado antes. El equipo desaparece de cada lista, selector, panel y recuento y de su trabajo de copia; sus ejecuciones, informes y entradas de auditoría permanecen. El worker elimina el repositorio de restic del equipo en cada destino que contiene archivos suyos: el principal, sus copias y los principales retirados. Eliminar al instante se rechaza mientras una retención legal sobre el inquilino o un punto de restauración sospechoso sin resolver retenga las copias, y el worker espera esa retención cuando las copias caducan. Los objetos que el almacenamiento aún bloquea (S3 Object Lock, el retraso de borrado de un directorio) se eliminan cuando su bloqueo termina; la página de equipos lista las eliminaciones aún pendientes, con la fecha, la retención o el bloqueo. Cada paso se audita.

Hasta que se eliminan las copias, la página de un equipo quitado las ofrece para explorar y para la descarga en ZIP (desde la 0.4.6), y la lista de equipos quitados enlaza «Restaurar archivos»; restaurar sobre el equipo y cualquier otra acción siguen rechazadas. Una desinstalación que espera a un equipo apagado ofrece Revocar ahora, y un equipo sin contacto durante más de un número de días que usted fije (30 por defecto, en Alertas del equipo) sugiere revocarlo.

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;
• una copia va con retraso (backup.overdue): la regla de alerta tiene en cuenta la programación del trabajo y puede fijar su propio plazo, de 24 a 720 horas;
• 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.

Las advertencias indican por qué no se copiaron elementos concretos y se pueden confirmar con una nota. Las alertas por webhook también pueden publicar en Discord, Slack o Microsoft Teams, véase copia de seguridad de Microsoft 365 e IMAP.

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. Se ejecutan como root, así que decide el equipo: en un equipo nuevo los hooks están desactivados y solo root en el equipo puede permitirlos, ya sea solo scripts con nombre que root haya puesto en /etc/restow-agent/hooks.d (sudo restow-agent hooks scripts) o cualquier comando (sudo restow-agent hooks any). Restow no puede cambiar ese ajuste: muestra la regla de cada equipo y rechaza los hooks que el equipo no ejecutaría. Solo con any puede quien cambie la configuración de un equipo en Restow ejecutar cualquier comando como root en él, así que es preferible scripts. Configurar o cambiar un hook pide además un inicio de sesión reciente.

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.
• Mientras un equipo del inquilino esté activo, Restow rechaza cambiar el destino de almacenamiento principal, porque un agente activo sigue escribiendo en el repositorio principal antiguo. Para cambiarlo, revoque o desinstale los equipos, cambie el destino principal y vuelva a registrar los equipos; así se crean repositorios nuevos. Desde la 0.4.2 un «traslado» copia también los repositorios de los equipos revocados al repositorio principal nuevo, verificados por SHA-256, y la página de un equipo nombra el repositorio en el que acaban sus copias (y registrar un equipo avisa cuando es el propio disco del servidor); con «mantener», se quedan en el destino anterior y siguen pudiéndose explorar y descargar. Véase almacenamiento.
• Qué cubren las comprobaciones de la versión: el script de instalación del agente se ejecuta en ellas solo dentro de un contenedor Linux. El instalador de macOS se probó en un Mac fuera de las comprobaciones de la versión, y el servicio de launchd todavía no se ha ejecutado en condiciones reales.
• Todavía no hay copias de imagen ni de sistema completo (bare metal): hoy la copia es a nivel de archivo. La copia de imagen está prevista.
• El agente se ejecuta como root, porque tiene que leer cada archivo que copia.
• El agente busca actualizaciones un minuto después de arrancar y luego cada 6 horas, y además cuando el servidor lo pide (una actualización del servidor o «Actualizar a <versión>»), e instala solo versiones firmadas por el mantenedor: comprueba la firma Ed25519 sobre la lista de sumas de comprobación de la versión con la clave compilada en él y después el SHA-256 de cada archivo, de modo que una instancia comprometida no puede hacerle ejecutar un binario propio. Las actualizaciones automáticas del agente se pueden pausar por inquilino. La primera instalación confía en el script de instalación que sirve su instancia, como cualquier curl | sh: compare la huella de la clave de versión que muestra el script con la publicada, SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (Ed25519, también en las notas de la versión).
• Restow es una beta. Utilícelo junto a sus copias de seguridad actuales hasta que usted mismo haya restaurado desde él.

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 →

Más en Aprender: cómo funciona la retención diaria, semanal y mensual (rotación abuelo-padre-hijo) →

Más en Aprender: copias inmutables, WORM y air gap (el solo anexado en contexto) →