-
Recursos compartidos de archivos (SMB y NFS)
-
Copia y restauración de recursos compartidos de archivos
Copia de un recurso compartido SMB (Windows Server, Samba, un NAS) o de una exportación NFS desde el servidor, sin agente en el servidor de archivos. Restow lo monta en solo lectura durante una ejecución, en un contenedor ejecutor temporal que arranca el montador, y conserva los permisos NTFS (las ACL de NFSv4 y POSIX, en la medida de lo posible) en cada punto de restauración. Los archivos abiertos, ilegibles o sin conexión se omiten y se listan, y la ejecución termina con advertencias. Restauración como ZIP, en una carpeta nueva, en la ubicación original (sobrescribir, conservar ambos, omitir) o en otro recurso compartido, con permisos cuando el destino lo permite. SMB 2.1 a 3.1.1; se rechazan SMB1 y NTLMv1. Las instalaciones nuevas arrancan el montador por defecto; una existente lo obtiene con «Activar recursos de red». Probado contra Samba en la prueba de humo de la versión, no contra Windows Server, un recurso de Synology o TrueNAS, exportaciones NFS reales ni un host con SELinux en modo enforcing. Sin VSS sobre SMB: los archivos abiertos con bloqueo exclusivo se omiten.
0.4.0
Todas las ediciones
-
Recursos compartidos: comprobaciones de restauración, trabajos de copia y presupuestos
Cada punto de restauración nuevo se comprueba releyendo hasta 20 archivos de muestra y comparándolos, el repositorio recibe cada semana una comprobación de restic del 5 por ciento de sus datos y la preparación para restaurar valora un recurso compartido por su punto de restauración más reciente. Los trabajos de copia escriben el punto de restauración comprobado más reciente de un recurso en una carpeta de otro, en modo sobrescribir o espejo; un trabajo de copia no guarda versiones y se marca como que no es una copia de seguridad. Los presupuestos por recurso, por inquilino y como valor por defecto (desactivados por defecto, los fijan los administradores del proveedor) avisan al 80 por ciento y rechazan copias nuevas al 100 por ciento. Los recursos cuentan en el estado, la página de inicio, la preparación para restaurar, las advertencias, el historial, las estadísticas y la vista del proveedor. Todavía no: repositorios distintos del principal, restauración autoservicio para usuarios del inquilino y un bloque de recursos compartidos en los informes programados.
0.4.0
Todas las ediciones
-
Protección frente a ransomware y abusos
-
Copias inmutables
Inmutabilidad por repositorio, desactivada hasta que un administrador la activa (Repositorios, «Cambiar la inmutabilidad»). En S3, Object Lock (compliance o governance, de 1 a 3650 días) bloquea los paquetes, los manifiestos y las claves envueltas del almacén de fragmentos (Microsoft 365, IMAP, discos de Proxmox VE) y los objetos de cada repositorio de restic (equipos, recursos compartidos, contenedores de Proxmox VE). Restow comprueba primero el bucket, renueva el bloqueo de los datos que aún se usan, trata un borrado que el almacenamiento rechaza como «todavía no» y nunca envía la cabecera de omisión de governance. En los directorios (el volumen de Docker, un recurso NFS) un retraso de borrado hace que el propio código de Restow se niegue a borrar o sobrescribir un archivo hasta que pase el plazo; protege frente al mal uso de Restow, no frente a alguien con acceso al servidor, y la interfaz dice que no es inmutabilidad. Los puntos de restauración muestran «Inmutable hasta <fecha>», en verde solo con una retención compliance que el propio almacenamiento ha comunicado; los resultados de la verificación y las advertencias aparecen en la tarjeta del repositorio, el panel y la vista del proveedor. Reducir la protección exige al propietario del proveedor con un inicio de sesión reciente. Probado contra un S3 simulado con Object Lock, todavía no contra un servicio real; el repositorio predeterminado de la instalación no puede hacerse inmutable.
0.4.0
Todas las ediciones
-
Detección de ransomware con retención en pausa
Cada punto de restauración nuevo de un equipo, recurso compartido, invitado de Proxmox VE, buzón, OneDrive, sitio de SharePoint o cuenta IMAP se juzga en busca de señales de ransomware con datos que la copia ya tiene: la cantidad de cambios frente al historial del propio objeto, borrados masivos, extensiones renombradas, extensiones de ransomware conocidas y notas de rescate, la entropía de una muestra de archivos nuevos y la relación de compresión y deduplicación de los datos nuevos. Un punto de restauración sospechoso recibe una insignia y las vistas de restauración ofrecen el más reciente sin hallazgos. Mientras no se resuelve, una retención en pausa detiene la retención y la poda de ese objeto, para que no se poden puntos de restauración antiguos y limpios mientras se acumulan los cifrados; solo un administrador pone fin a la pausa (falsa alarma o liberación, auditado). Nunca lee los datos una segunda vez, nunca bloquea una copia y no es un antivirus. Algunas señales necesitan el agente 0.4.0 en los equipos o restow-pve 0.4.0 en el nodo, y una señal sin datos dice «no disponible», nunca limpia. Activada tras la actualización, con sus umbrales e interruptores en Instalación, Detección de ransomware. Probada con ataques simulados, no con ransomware real.
0.4.0
Todas las ediciones
-
Los endpoints de S3 exigen HTTPS
Se rechaza un endpoint de S3 nuevo o modificado por http:// sin cifrar, también para los administradores del proveedor y el valor por defecto de la instalación, salvo hacia localhost, 127.0.0.1 y [::1]. Los endpoints guardados antes siguen funcionando y avisan en rojo de que deberían pasar a HTTPS; S3_ALLOW_INSECURE=true admite HTTP sin cifrar solo en entornos de prueba y desarrollo.
0.4.0
Todas las ediciones
-
Notificaciones
-
Matriz de notificaciones
En Integraciones, Notificaciones los eventos son las filas, agrupadas y marcadas por gravedad, y la campana, cada webhook y cada destinatario de notificaciones son las columnas, cada una con las opciones rápidas «Solo errores», «Errores y advertencias» y «Todo». Guardar queda auditado. La actualización rellena cada columna con exactamente lo que el canal recibía antes, de modo que al principio nada cambia; un webhook creado después empieza con los valores por defecto de su formato, y una regla de alerta ya no envía un evento a un canal cuya columna lo tiene desactivado. Eventos nuevos: backup.succeeded y verify.completed para el correo y la campana, backup.suspicious y backup.suspicious_hold, boot_test.failed y boot_test.unproven, e installation.disk_low para los administradores del proveedor.
0.4.0
Todas las ediciones
-
Proxmox VE (vista previa)
-
Proxmox VE: progreso de una copia en curso
VMs y contenedores, el inventario y la página del invitado muestran una barra de progreso («34% · 3,2 GB de 9,4 GB · 85 MB/s»), y las líneas del propio asistente (el id de la ejecución, lo que restic añadió, lo que no pudo leer) llegan al registro de la ejecución; una copia correcta con lagunas nombra los primeros 20 elementos ilegibles. Las copias de contenedores dejan ahora que restic escanee primero, de modo que hay un total frente al que mostrar el progreso. Necesita restow-pve 0.4.0 en el nodo. Probado con el nodo simulado de las suites de pruebas, no con un nodo real de Proxmox VE.
0.4.0
Todas las ediciones
-
Proxmox VE: pruebas de arranque de puntos de restauración
Un trabajo de Proxmox VE puede arrancar el punto de restauración más reciente de cada invitado cada semana o tras cada copia (desactivado por defecto; por defecto un límite de memoria de 8 GiB y cinco minutos de espera al agente invitado), y «Probar el arranque ahora» pide una a mano. El nodo lo restaura como un invitado nuevo en el pool restow-restore, lo aísla antes del arranque (enlaces de red desactivados, dispositivos passthrough, puertos serie, montajes bind y el script de hook eliminados), espera al agente invitado de QEMU y lo destruye en cualquier caso. Verde cuando el agente invitado respondió, amarillo cuando la VM solo arrancó, rojo cuando falló la restauración, el arranque o el inicio; la preparación para restaurar valora el punto de restauración más reciente por su prueba de arranque. Una prueba por nodo a la vez, nunca junto a una copia. Necesita restow-pve 0.4.0; probado con el nodo simulado, no con un clúster real de Proxmox VE.
0.4.0
Todas las ediciones
-
Proxmox VE: restauración de archivos de contenedores y VMs (vista previa)
En Servidores y equipos, Restauración de archivos, cada contenedor con un punto de restauración aparece en el grupo «Contenedores de Proxmox VE» y cada VM en «VMs de Proxmox VE», marcados como vista previa: se explora un punto de restauración y se descargan archivos y carpetas como un solo ZIP, leídos por el servidor desde el repositorio del invitado; las lecturas y descargas quedan auditadas. En las VMs, cada sistema de archivos legible de los discos es una carpeta (particiones GPT y MBR y volúmenes LVM lineales con ext2, ext3, ext4, XFS, NTFS o FAT), leída en un proceso hijo restringido, sin montar nada en el servidor ni en el nodo. No se pueden leer: btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker y LUKS, archivos comprimidos con NTFS y EFS; los registros de XFS y NTFS no se reproducen, así que compare un archivo importante con el original antes de fiarse de él. Restaurar archivos sueltos en un invitado en ejecución no está construido.
0.4.0
Todas las ediciones
-
Trabajos de Proxmox VE en Servidores y equipos
Los trabajos de Proxmox VE aparecen en Servidores y equipos, Trabajos junto a los trabajos de equipos, con una columna Tipo, los invitados por trabajo, la programación, la última y la próxima ejecución y «2 de 5 invitados listos» mientras se ejecuta una ronda; una copia iniciada a mano aparece como una fila hasta que termina. Nuevo trabajo es un menú con una entrada por tipo, y el formulario del trabajo de Proxmox VE lista las VMs y los contenedores que entran en el trabajo. La página de un invitado muestra lo que añade de media una copia posterior.
0.4.0
Todas las ediciones
-
Servidores y equipos
-
Políticas de agentes
Reglas para los agentes de servidores y equipos en tres niveles: la instalación (Instalación, política de agentes), el inquilino y el trabajo de copia. Cada nivel puede sustituir un ajuste salvo que la instalación lo bloquee, y cada vista dice de dónde viene un valor. Los ajustes: una ventana de copia (días de la semana y un intervalo horario) en la que pueden empezar las copias programadas, las recuperaciones y los reintentos; recuperar las copias perdidas en cuanto el equipo vuelve a estar encendido o en la próxima ventana, opcionalmente solo hasta una antigüedad máxima; un límite de subida para los trabajos que no tienen uno propio; solo con corriente; y el número de reintentos automáticos (de 0 a 10). La página de un equipo muestra la política que le afecta y por qué espera una copia pendiente. La ventana, la recuperación, los reintentos y el motivo de la espera necesitan el agente 0.4.0; el límite de subida y la corriente llegan también a agentes más antiguos. Probado solo con servicios simulados.
0.4.0
Todas las ediciones
-
Restauración de archivos para el rol de restauración
Los operadores de restauración (el rol de restauración de un inquilino) abren Servidores y equipos, Restauración de archivos: listan los equipos, leen sus puntos de restauración y su inmutabilidad, los exploran, descargan archivos como ZIP y restauran archivos en el equipo. En Proxmox VE leen el resumen y los puntos de restauración de un invitado y exploran y descargan archivos de los puntos de restauración de contenedores y VMs. Los ajustes, los tokens, los trabajos, copiar, verificar y las pruebas de arranque, restaurar un invitado entero y revocar o eliminar siguen siendo de los administradores. Cada lectura, descarga y restauración queda auditada con el operador como actor.
0.4.0
Todas las ediciones
-
Carpetas de datos que un trabajo deja fuera y cómo funciona un equipo
El agente 0.4.0 informa de cuáles de una lista fija de carpetas de datos de Linux (/opt, /usr/local, /srv, /var/www, los 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 de trabajos nombra las carpetas que los equipos del trabajo tienen de verdad y el trabajo deja fuera, y la página de un equipo ofrece «Añadir esta carpeta al trabajo». La página de un equipo dice cómo funciona (contenedor, máquina virtual, físico, con o sin escritorio), y un equipo Linux en un contenedor o una máquina virtual sin escritorio recibe el perfil de servidor; el explorador de archivos de un punto de restauración dice qué carpetas contiene.
0.4.0
Todas las ediciones
-
Trabajos, vista en vivo y panel
-
Crear el trabajo recomendado
Junto a cada aviso de «sin trabajo» (trabajos, inventario, fuentes, directorio, VMs y contenedores) y como «Proteger todo lo que no tiene trabajo» en la tarjeta de preparación del panel: una vista previa de lo que crea o amplía el clic y después un trabajo por tipo (correo cada 8 horas; equipos por sistema y perfil; un trabajo de Proxmox VE, a diario a las 22:00 en modo instantánea). Un segundo clic amplía el mismo trabajo en lugar de crear otro. Solo administradores, anotado en el registro de auditoría.
0.4.0
Todas las ediciones
-
Copias en curso en la barra lateral y un panel de ejecución más vivo
Las entradas Trabajos y VMs y contenedores muestran un indicador con el número de copias en curso y en espera; el tooltip las lista y un clic abre la ejecución. En el panel de la ejecución los gráficos avanzan con el tiempo entre mediciones, los números cuentan hacia arriba, el tiempo restante cuenta hacia abajo y una línea dice cuándo informó la ejecución por última vez (o que Microsoft Graph la limita). La primera copia de un buzón grande muestra «Primera copia: X de Y elementos» sobre todos los intentos, con una estimación del tiempo restante; un OneDrive muestra «X elementos hasta ahora» hasta que está listado por completo.
0.4.0
Todas las ediciones
-
Todos los inquilinos en Trabajos
En «Todos los inquilinos», Trabajos de Mail & SaaS y de Servidores y equipos lista cada inquilino con sus trabajos por tipo, lo que se ejecuta y espera, cómo terminaron las copias más recientes y la próxima ejecución, con filtros y ordenación; una fila abre los trabajos del inquilino en solo lectura. La vista sigue siendo rápida en instalaciones grandes porque lee mediante un índice y conserva las cifras de cada inquilino durante 30 segundos.
0.4.0
Service Provider
-
Crecimiento del almacenamiento en el panel
El panel muestra cómo creció el almacenamiento de un inquilino en 1 semana, 1 mes, 3 meses o 1 año; a partir de 3 meses la estimación es una banda entre el crecimiento más lento y el más rápido, y donde se conoce el espacio libre dice cuándo se llena el repositorio con este crecimiento.
0.4.0
Todas las ediciones
-
Microsoft 365
-
SharePoint Online: copia y restauración de sitios
Cada sincronización del directorio encuentra los sitios de SharePoint del inquilino (incluidos los sitios de grupos de Microsoft 365 y de Teams; los sitios personales se dejan al OneDrive de su propietario), y cada sitio es un objeto protegido propio, en los trabajos de correo como los buzones y los OneDrive; las reglas de protección tienen un modo de sitios, todos o los elegidos. Una copia contiene cada biblioteca de documentos (opcionalmente con versiones), cada lista con sus columnas y los valores de los campos de cada elemento como JSON, y la descripción del sitio. Restauración en el explorador: descarga como ZIP; archivos y carpetas en la biblioteca original o en otra de un sitio copiado (conservar ambos, sobrescribir con SharePoint guardando el archivo antiguo como versión, u omitir los existentes); elementos de lista como elementos nuevos en su lista original, solo campos editables. No se copian ni se restauran: los chats de Teams, los adjuntos de los elementos de lista, el diseño del sitio, la navegación y los flujos de trabajo; los permisos se conservan como información y nunca se restauran; un sitio o una biblioteca eliminados no se recrean. Necesita el permiso de aplicación Sites.ReadWrite.All (Sites.Read.All basta para copiar) y un nuevo consentimiento de administrador por inquilino. Probado contra un Microsoft Graph simulado, no contra un inquilino real de Microsoft 365.
0.4.0
Todas las ediciones
-
Actualizaciones, base de datos y almacenamiento
-
Ejecuciones en curso durante una actualización
El diálogo de instalación cuenta lo que se ejecuta y espera en cada inquilino y pregunta qué hacer: «Detenerlas limpiamente» (el valor por defecto: las ejecuciones de Microsoft 365 y correo guardan un punto de control y se detienen; se espera a las ejecuciones de agentes y de recursos compartidos, 30 minutos como máximo), «Esperar a que terminen» (dos horas como máximo) o «No esperar». Desde la confirmación hasta que termina la actualización no empieza ninguna ejecución nueva, y las programaciones que vencen entretanto se ejecutan después; todos los usuarios conectados ven un aviso. Los agentes 0.4.0 retienen sus propias programaciones y esperan; los anteriores a la 0.4.0 no, así que una copia que un equipo así inicia por sí mismo durante una actualización puede fallar si la API se reinicia debajo. Una copia de Proxmox VE que se ejecuta mientras Restow se actualiza ya no falla: el nodo sigue intentándolo durante cinco minutos.
0.4.0
Todas las ediciones
-
Mover la base de datos a otro disco
Instalación, Base de datos muestra dónde guarda la base de datos sus datos, su tamaño, el espacio libre debajo y bajo el repositorio local predeterminado, y lo que necesita la próxima actualización. Con el actualizador opcional, el propietario del proveedor traslada la base de datos a un directorio de otro disco: primero se comprueba (otro sistema de archivos local, ext4, XFS, Btrfs o ZFS, espacio para los datos), después se copia, se compara archivo por archivo, se arranca de prueba y se conmuta, con reversión automática ante cualquier fallo; la copia antigua se conserva y se impide que arranque hasta que se elimine. La comprobación previa del actualizador suma ahora lo que escribe una actualización y rechaza la que no cabe, y la pestaña Actualizaciones lista los volcados previos (el propietario puede descargar o eliminar uno). El traslado no se probó con un actualizador real y su contenedor auxiliar de Docker antes de publicar la versión.
0.4.0
Todas las ediciones
-
Aviso de poco espacio en disco
Cada 15 minutos la API comprueba el disco bajo la base de datos (a través del actualizador) y bajo el repositorio local predeterminado. Con menos de una décima parte libre, y siempre por debajo de 5 GiB, los administradores del proveedor reciben un aviso en la campana, y las reglas de alerta que incluyen «Poco espacio en disco» lo envían, una vez por episodio.
0.4.0
Todas las ediciones
-
Rendimiento en instalaciones grandes
La memoria sigue acotada sea cual sea el tamaño: el primer catálogo de un recurso compartido se transmite a la base de datos en lotes de 5.000 archivos, la reutilización de los permisos SMB mantiene un índice compacto para que los recursos con millones de archivos no se queden sin memoria, los sitios de SharePoint con miles de listas ya no tardan un tiempo cuadrático, los mapas de bloques de los discos de VM explorados se guardan en caché por tamaño, y la renovación de Object Lock envía 32 solicitudes a la vez y continúa un recorrido interrumpido donde se detuvo. El juicio de ransomware y la vista Todos los inquilinos de Trabajos leen mediante índices.
0.4.0
Todas las ediciones
-
0.4.1
-
Los datos almacenados cuentan los repositorios de restic
Repositorios, Uso, el mosaico «Almacenado» del panel, las estadísticas y la API contaban solo los paquetes del almacén de fragmentos: un inquilino con 10 GB de copias de contenedores veía «Almacenado 10,9 kB». «Almacenado» suma ahora los repositorios de restic de equipos, recursos compartidos y contenedores de Proxmox VE, y la tarjeta de uso muestra cuánto está en el almacén de fragmentos y cuánto en repositorios de restic. El tamaño del repositorio de un contenedor se mide una vez en su primera subida tras la actualización, después se cuenta por subida y borrado y se mide de nuevo tras una poda. El ahorro por deduplicación, el crecimiento y el gráfico siguen siendo cifras del almacén de fragmentos y lo dicen; el tamaño de un repositorio no tiene historial, y «Datos protegidos» sigue contando solo las fuentes del almacén de fragmentos.
0.4.1
Todas las ediciones
-
Proxmox VE: se nombra un asistente de nodo antiguo
Una copia de contenedor en curso en un nodo con restow-pve anterior a la 0.4.0 mostraba «Aún no se ha informado del progreso» durante toda su ejecución. Ahora dice que el progreso necesita restow-pve 0.4.0, qué versión ejecuta el nodo y que hay que actualizarlo. restow-pve pide ahora una actualización dos minutos después de arrancar y luego cada seis horas, en lugar de solo tras seis horas; la actualización sigue esperando a que no haya ninguna copia ni restauración en curso.
0.4.1
Todas las ediciones
-
0.4.2
-
Detener una copia desde la aplicación web
Proxmox VE: «Detener copia» en la tabla VMs y contenedores, en la página del invitado y en el panel de ejecución detiene una copia en curso (el nodo termina la tarea de vzdump mediante la API de Proxmox VE, también si la copia se inició en el propio Proxmox VE) y «Retirar» saca al instante una copia en cola. Por nodo, «Pausar la cola» y «Cancelar todas las pendientes», también para todo el inquilino. Servidores y equipos: «Detener copia» en la página del equipo y en el panel de ejecución; el agente detiene restic de forma limpia en su siguiente contacto, en aproximadamente un minuto. Las ejecuciones de recursos compartidos también se pueden cancelar desde el panel de ejecución (las de Microsoft 365 e IMAP ya se podían). Una ejecución detenida 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. Necesita restow-pve desde la 0.4.2 en el nodo y el agente desde la 0.4.2 en el equipo; un nodo anterior termina una copia cancelada en su siguiente subida, un agente anterior la termina.
0.4.2
Todas las ediciones
-
Los nodos y agentes siguen una actualización del servidor
Cuando el servidor ejecuta la nueva versión, las ejecuciones nuevas siguen en pausa mientras los nodos de Proxmox VE y los agentes la instalan (entonces están libres), hasta que todos los alcanzables la notifican o pasan 15 minutos. Instalación › Actualizaciones muestra su progreso y, para los que no se alcanzaron, el comando para actualizar a mano. «Actualizar a <versión>» en la página de un nodo y de un equipo pide la actualización en cualquier momento. `restow-agent update` en un equipo instala la versión ofrecida al instante, como `restow-pve update` en un nodo, con la misma descarga firmada que la autoactualización automática; mientras se ejecuta una copia se niega, y el agente se actualiza solo cuando queda libre.
0.4.2
Todas las ediciones
-
Actualizaciones planificadas y una zona horaria de la instalación
Una actualización se puede planificar para una fecha y hora elegidas, hasta con 30 días de antelación, además de los plazos desde ahora: antes no se pausa nada, y todos los usuarios conectados ven un aviso desde un día antes. La hora se lee en la zona horaria de la instalación, que se elige en el asistente de configuración (con la zona del navegador preseleccionada) y que un propietario cambia en Instalación › Servidor y operación › Servidor; un inquilino nuevo empieza con ella. Una instalación configurada antes de la 0.4.2 sigue usando RESTOW_TIME_ZONE, después TZ y después Europe/Berlin hasta que un propietario elija una. Cuando hay una actualización disponible, la versión de la barra lateral pasa a ser un «Actualizar a <versión> disponible» resaltado que lleva a Instalación › Actualizaciones, para quienes pueden instalar actualizaciones.
0.4.2
Todas las ediciones
-
Proxmox VE: cada punto de restauración nuevo se comprueba en minutos
Un punto de restauración nuevo de una VM o un contenedor se relee en minutos tras su copia (una muestra de sus bloques, en un contenedor una comprobación de restic de un subconjunto), un número acotado por pasada, además de la comprobación semanal de cada invitado. El ajuste «Comprobar cada punto de restauración nuevo justo después de la copia» (Instalación › Proxmox VE, propietario) viene activado; desactivado, un punto nuevo espera a la comprobación semanal. En Preparación de recuperación hay «Comprobar ahora» por invitado y «Comprobar todos los no verificados». Una comprobación en rojo muestra el error que encontró, por ejemplo el de restic, en lugar de solo «los bloques no coincidían o no se pudieron leer». Es la relectura por muestras, no una prueba de arranque; las pruebas de arranque siguen como en la 0.4.0.
0.4.2
Todas las ediciones
-
Proxmox VE: una cadena de copias nueva para un contenedor cuyo repositorio ha desaparecido
Tras cambiar el repositorio principal con «Mantener las copias existentes donde están», todos los contenedores con un repositorio existente fallaban con «repository does not exist». Antes de que una copia reciba su credencial, el servidor comprueba ahora una vez por ejecución que el repositorio está en el principal. Si falta en todas partes, empiezan un repositorio nuevo y una cadena de copias nueva, visibles en la página del invitado («Nueva cadena de copias iniciada el <fecha>») y en el registro de auditoría; los puntos de restauración anteriores pasan a «No disponible» (sin restauración, sin comprobación, no cuentan para la preparación, la retención los omite). Si sigue en un destino retirado, la copia se rechaza con un mensaje claro. «Restablecer repositorio» (la zona de peligro de la página del invitado, solo contenedores) hace lo mismo a petición: se escribe el nombre del invitado, hace falta un inicio de sesión reciente y queda auditado. Un recurso compartido cuyo repositorio ha desaparecido todavía no se repara así; está previsto.
0.4.2
Todas las ediciones
-
Proxmox VE: cadencias de los trabajos, la VM del propio servidor de Restow y copias con avisos
Los trabajos de copia de Proxmox VE admiten las cadencias de un trabajo de correo: cada pocas horas, a diario, en los días de la semana elegidos, cada mes o con una expresión cron, no más a menudo que cada hora. La VM en la que se ejecuta el propio Restow se reconoce por su UUID de SMBIOS (restow-pve desde la 0.4.2 lo notifica) o la marca un administrador; ningún trabajo la copia, y «Copiar ahora» o incluirla en un trabajo exige una confirmación que nombra el riesgo de copiarla con el propio Restow. Una copia que vzdump termina con «TASK WARNINGS» después de confirmar su punto de restauración cuenta como «Correcta con avisos» en lugar de fallida.
0.4.2
Todas las ediciones
-
Se muestra dónde acaban las copias
El repositorio principal efectivo del inquilino se nombra en la página de un invitado y en su nuevo diálogo «Copiar ahora», en los diálogos de trabajos y de conexión de Proxmox VE, en la página de un equipo y de un recurso compartido y en los editores de trabajos, con el valor por defecto de la instalación en el disco local del servidor resaltado. La sección Repositorios y los diálogos que añaden nodos de Proxmox VE, equipos y recursos compartidos avisan «Las copias acaban en el propio disco del servidor» cuando el repositorio principal es un directorio en un disco del propio servidor (no un recurso de red).
0.4.2
Todas las ediciones
-
Un traslado de almacenamiento se lleva los repositorios de restic
Un «traslado» del repositorio principal copia ahora también los repositorios de restic de contenedores, equipos y recursos compartidos, verificados por tamaño y por SHA-256 como los packs. Espera a las copias de contenedores y las ejecuciones de recursos compartidos en curso antes de cambiar, y copia los manifiestos de los puntos de restauración de VM y contenedores. «Mantener las copias existentes donde están» y promover una copia se rechazan mientras haya contenedores o recursos compartidos con repositorios de restic, que solo el «traslado» se lleva. Un cambio del repositorio principal se sigue rechazando mientras un equipo del inquilino esté activo.
0.4.2
Todas las ediciones
-
Comprobación del almacenamiento: temporalmente ilegible no es dañado
La comprobación del almacenamiento ya no califica de dañado un pack que no pudo leer en ese momento (una descarga cortada a mitad de transferencia, una conexión restablecida, un tiempo de espera agotado, S3 pidiendo ir más despacio, acceso denegado). Lee ese pack de nuevo, hasta tres veces, y enumera lo que sigue ilegible como «temporalmente ilegible» en Preparación de recuperación › Integridad del almacenamiento, con el error, en cuántas comprobaciones seguidas no se pudo leer y cuándo; cada comprobación posterior lo lee primero, y «Volver a comprobar estos packs» lee de nuevo solo los packs marcados. Los objetos que lo usan reciben «Atención»; pasan a «No restaurable» solo cuando un pack está demostradamente dañado (falta, tamaño o suma de comprobación incorrectos) o no se pudo leer en 3 comprobaciones seguidas a lo largo de al menos 24 horas. Las lecturas de S3, también las restauraciones y las comprobaciones de restauración, reanudan una descarga que se corta. El valor storageIntegrity.state de la API de integración tiene el nuevo valor unreadable (contrato 1.5.0, aditivo).
0.4.2
Todas las ediciones
-
Explorador de restauración: una entrada por persona y un calendario por meses
El explorador de restauración muestra una entrada por persona: buzón, OneDrive y una cuenta IMAP asociada se agrupan, y la segunda columna muestra Correo, Calendario, Contactos y OneDrive, cada uno con sus propios puntos de restauración. Los sitios de SharePoint y Teams tienen una sección propia, y un OneDrive huérfano aparece bajo el nombre de su propietario como «Cuenta eliminada». La lista llega por páginas, con búsqueda por nombres, direcciones e ID de cuenta y un filtro por tipo en la base de datos; va bien hasta unas 10.000 personas por inquilino y es más lenta por encima. El calendario de un buzón tiene una vista mensual, día a día en todos sus calendarios o en uno, y una serie se abre en sus apariciones, calculadas a partir del patrón guardado con las apariciones modificadas en su sitio; los eventos se ordenan por el momento en que empiezan.
0.4.2
Todas las ediciones
-
Editor de trabajos de correo: copiar, archivar o ambos
La primera pregunta del editor de trabajos de correo es qué debe hacer el trabajo: copiar, archivar o ambos (ambos es el valor por defecto de un trabajo nuevo). Mientras archiva, el editor nombra cómo llega el correo al archivo (journaling de Exchange, que se configura una vez por inquilino) con el camino a su configuración, y sugiere copiar cada 8 horas; solo copiar nombra el hueco entre dos ejecuciones, en el que un correo que llega y se borra no está en ninguna copia. Un trabajo que solo archiva no hace copias programadas. Desde la 0.4.4 el editor ofrece además las vías de captura que encajan con cada tipo de buzón (véase la 0.4.4).
0.4.2
Todas las ediciones
-
0.4.3
-
Proxmox VE: VMs y contenedores en pestañas, con búsqueda, filtros y un panel de detalle
VMs y contenedores tiene tres pestañas con recuentos: Invitados, Trabajos de copia y Nodos. La tabla de invitados tiene una búsqueda por ID y nombre, filtros por nodo, tipo (VM o contenedor), trabajo de copia (también «Sin trabajo de copia») y estado, un botón «Solo problemas», columnas ordenables, páginas de 25 a 250 y el estado en la dirección, de modo que un enlace abre la misma vista. Cada fila muestra una insignia de estado elegida por prioridad, con una pequeña barra de progreso mientras se ejecuta su copia o «+N» si hay más problemas. Un clic abre un panel de detalle con todos los estados, el error completo y los avisos de la última ejecución en un bloque que se puede copiar, la comprobación de restauración, los tamaños, el trabajo, las ejecuciones más recientes y las acciones (copiar ahora, detener, retirar, comprobar ahora, abrir la página del invitado). La columna «Copia» dice «Primera: 32 GB el 3 oct · Última: +210 MB», y el panel muestra los datos nuevos de las últimas 30 copias como barras pequeñas. La pestaña Nodos muestra el latido de cada nodo, su versión de restow-pve con «Actualizar a …» si va retrasada, su versión de Proxmox VE, su número de invitados, su cola y sus problemas. Las tablas mantienen anchos de columna fijos y una sola altura de fila, así que ya no saltan mientras se ejecutan copias. Probado con pruebas del DOM, no visualmente en un navegador con miles de invitados.
0.4.3
Todas las ediciones
-
Proxmox VE: un repositorio bloqueado ya no hace fallar una comprobación de restauración
Justo después de una copia de contenedor, la nueva comprobación de restauración fallaba a menudo en rojo con un mensaje de restic sobre bloqueos obsoletos, aunque la comprobación nunca se ejecutó: otra ejecución, normalmente la propia copia del invitado, mantenía el bloqueo del repositorio. Una comprobación que un bloqueo deja fuera se pospone ahora y se reintenta tras diez minutos, y el resultado anterior se mantiene. Tras dos horas dice «No se pudo comprobar: repositorio bloqueado» en amarillo (Atención en Preparación de recuperación), nunca en rojo ni en verde, con quién mantiene el bloqueo. Los bloqueos obsoletos de restic se eliminan antes de la comprobación y antes de la retención, un invitado no se comprueba mientras se ejecuta algo suyo, y un punto de restauración nuevo se comprueba dos minutos después de su confirmación como pronto. restow-pve espera hasta 15 minutos el bloqueo durante una copia de contenedor. Las comprobaciones que fallaron en rojo por un bloqueo antes de la actualización siguen en rojo hasta «Comprobar ahora». Probado con una API de Proxmox VE y un almacén S3 simulados, no con un clúster real.
0.4.3
Todas las ediciones
-
Actualizar nodos y agentes ahora
En la tarjeta de nodos y agentes de Instalación › Actualizaciones, «Actualizar nodos y agentes ahora» inicia el paso en el que siguen al servidor cuando ninguna actualización llevó a él: el servidor se actualizó a mano, o se perdió la respuesta a una actualización anunciada. Lo inicia un administrador con todos los inquilinos; las ejecuciones nuevas se pausan como máximo 15 minutos mientras los nodos y agentes alcanzables que van por detrás instalan la versión cuando están libres, y la pausa termina cuando acaban (auditado como update.fleet_started con manual: true). Fuera de una actualización, los nodos y agentes que van por detrás figuran como «Actualización disponible». Los nodos con restow-pve 0.4.1 no reaccionan y necesitan una actualización a mano.
0.4.3
Todas las ediciones
-
Proxmox VE: restow-pve reinicia los demonios de Proxmox VE tras actualizarse a sí mismo
Tras una autoactualización, los demonios de Proxmox VE seguían con el complemento de almacenamiento antiguo cargado hasta que se reiniciaban. restow-pve reinicia ahora pvedaemon, pveproxy, pvestatd y pvescheduler como hace el instalador, y restow-pve update reinicia también el servicio restow-pve en marcha, de modo que el nodo notifica la nueva versión con su siguiente latido. Un nodo que un restow-pve anterior actualizó reinicia los demonios una vez por sí mismo. Los nodos con restow-pve 0.4.1 necesitan una actualización a mano: /opt/restow-pve/bin/restow-pve update, después systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler.
0.4.3
Todas las ediciones
-
Actualizaciones: sin el falso «El actualizador no está en ejecución»
Al anunciar una actualización se podía mostrar «El actualizador no está en ejecución» aunque el actualizador la aceptara unos segundos después. La api esperaba 5 segundos una respuesta mientras el actualizador comprueba primero Docker, la configuración de Compose, el espacio en disco y la versión en ejecución (de 5 a 12 segundos en instalaciones reales); la actualización se ejecutaba entonces sin la pausa de las ejecuciones nuevas, sin la entrada de auditoría update.scheduled y sin el paso en el que los nodos de Proxmox VE y los agentes siguen al servidor. La api espera ahora hasta un minuto y, si la respuesta sigue perdida, vuelve a leer el estado del actualizador y da la actualización por aceptada si el actualizador la muestra; la pestaña Actualizaciones dice que está comprobando si se aceptó. La pestaña tampoco dice ya «no está en ejecución» durante unos segundos de vez en cuando: el actualizador responde al instante con su última comprobación y vuelve a comprobar en segundo plano.
0.4.3
Todas las ediciones
-
0.4.4
-
Captura del archivo: Microsoft 365 por notificaciones de cambios de Graph
Restow archiva los buzones de Microsoft 365 sin journaling. Para cada buzón archivado se suscribe a las notificaciones de cambios de Microsoft Graph y obtiene cada correo nuevo en pocos minutos tras la entrega (los borradores se omiten, y los identificadores inmutables de mensaje evitan que un correo movido se archive dos veces). Una puesta al día de todas las carpetas y de las eliminaciones recuperables se ejecuta por defecto cada seis horas y al instante tras una notificación perdida, y el correo existente del buzón se asume una sola vez, por páginas reanudables, marcado como capturado después. No hace falta ningún permiso nuevo de Microsoft. Las notificaciones solo llegan si la URL pública de la instalación es https en el puerto 443 y Microsoft puede alcanzarla; si no, cada buzón se consulta, por defecto cada 15 minutos, y el estado de la captura dice por qué. Es una captura cercana al momento y no es completa: un correo eliminado definitivamente antes de que Restow lo obtuviera puede faltar, y de los elementos recuperables solo se lee la carpeta de eliminaciones. Graph no puede exportar correo de más de unos 150 MB; ese correo se registra, no se archiva. Restow no puede ver si el inquilino conserva el correo eliminado (una directiva de retención o una retención por litigio, Litigation Hold), porque Graph v1.0 no ofrece forma de leerlo: un administrador lo confirma por fuente en la página del archivo, que muestra los comandos de PowerShell de Exchange Online que lo comprueban. Probado contra una API de Graph simulada, no contra un inquilino real de Microsoft 365.
0.4.4
BusinessService Provider
-
Captura del archivo: IMAP y Google Workspace por sincronización IMAP con IDLE
Las cuentas IMAP y de Google Workspace se archivan con una sincronización continua. La activación anota dónde está cada carpeta, el correo existente se asume una sola vez (reanudable, marcado como capturado después) y cada pasada posterior lee solo el correo nuevo: una consulta de estado por carpeta, primero los metadatos, y el origen solo del correo que el archivo aún no tiene para la cuenta. Se leen todas las carpetas salvo Borradores; en Gmail y Google Workspace solo Todos los mensajes, Spam y Papelera, que contienen cada correo una sola vez. Cuando el servidor ofrece IMAP IDLE, Restow mantiene una conexión abierta por cuenta (por defecto hasta 300 cuentas por worker) y archiva el correo nuevo en instantes, con una comprobación de las demás carpetas por defecto cada cinco minutos; las demás cuentas se consultan por defecto cada diez minutos. Una fuente puede ajustarse a «solo comprobar a intervalos», para proveedores con un límite de conexiones ajustado. Si cambia UIDVALIDITY, la carpeta se lee de nuevo sin archivar nada dos veces. Es una aproximación y se marca como tal: un correo movido o eliminado justo tras la entrega puede perderse, e IMAP no tiene nada parecido a una retención. Probado contra un servidor IMAP simulado y el Dovecot de la prueba de humo de la versión, no contra un inquilino real de Google Workspace ni un proveedor de alojamiento. Las fuentes IMAP con OAuth2 siguen sin poder crearse, así que una cuenta de Google Workspace se reconoce por su host o su lista de carpetas.
0.4.4
BusinessService Provider
-
Copias reenviadas al archivo
Para sistemas de correo sin journaling de Exchange, el proveedor envía a Restow una copia de cada correo entrante y saliente mientras el correo está en su transporte: una regla BCC en Postfix o mailcow, un redirect :copy de Sieve o la regla de enrutamiento «Añadir más destinatarios» de Google Workspace. El receptor de journaling acepta estas copias simples igual que los informes de journaling de Exchange. Cada cuenta IMAP puede tener una dirección de archivo propia (emitida a petición, renovable, auditada): una copia enviada a ella pertenece exactamente a esa cuenta, mientras que una copia enviada a la dirección de journaling del inquilino se asigna por sus cabeceras y el remitente SMTP. Una copia reenviada no tiene un sobre como el de un informe de journaling, así que un destinatario en copia oculta solo aparece si el proveedor lo escribe en una cabecera. La copia se crea en el transporte del proveedor, antes de que el usuario pueda tocar el correo. La página del archivo muestra para cada cuenta cómo configurar la regla (Postfix, mailcow, Sieve, Google Workspace) y si llegan copias. Probado contra el propio receptor, nunca contra un Postfix, mailcow, proveedor de alojamiento o Google Workspace reales. El receptor no comprueba el remitente (SPF).
0.4.4
BusinessService Provider
-
Un elemento archivado por correo, sin importar por cuántas vías se capturó
El correo que llega al archivo por más de una vía se reconoce por su Message-ID y su contenido (los bytes exactos o un hash del cuerpo) y se conserva una sola vez. Una captura que no es más fuerte que lo que el archivo ya tiene pasa a ser una anotación de captura de ese elemento; una más fuerte (por ejemplo una copia reenviada tras una sincronización IMAP) pasa a ser el elemento y nombra el anterior al que sustituye, que queda sin cambios en la cadena. El mismo Message-ID con otro cuerpo se conserva dos veces y se marca. Los informes de journaling y los mensajes importados siguen siendo elementos propios. La búsqueda y el detalle del elemento nombran las copias reenviadas, el correo capturado después y las demás vías que capturaron el mismo correo de nuevo; las capturas sustituidas se ocultan salvo que se pidan, y la exportación de una búsqueda lo sigue. Todos los escritores del archivo anexan ahora por una vía común y suben el original antes de tomar el bloqueo de la cadena del inquilino, de modo que un informe grande ya no retiene las demás entregas del inquilino.
0.4.4
BusinessService Provider
-
Editor de trabajos de correo: solo las vías de captura que encajan con el buzón
El editor de un trabajo de correo reconoce el tipo de buzón (Microsoft 365, IMAP, Google Workspace por IMAP, IMAP en un host de Microsoft) y ofrece solo las vías de captura que le corresponden: Microsoft Graph y el journaling de Exchange para Microsoft 365, el archivado IMAP y el reenvío para IMAP y Google Workspace. Cada vía se marca como captura en el transporte o cercana al momento, se bloquea con la edición que la incluye y se exige al menos una por tipo. Los valores por defecto de un trabajo nuevo, y de un trabajo que activa el archivado, son Graph y la sincronización IMAP, cada una con una asunción única del correo que ya está en el buzón. Las cuentas IMAP en un host de Microsoft reciben el consejo de conectar en su lugar una fuente de Microsoft 365. Desactivar el archivado o una vía pregunta antes: el correo nuevo deja de archivarse desde entonces y el archivo conservado hasta ahora se mantiene. Una dirección de journaling solo se solicita mientras está elegido el journaling de Exchange. Los trabajos que ya archivaban antes de la actualización conservan solo el journaling para Microsoft 365 y aún no tienen vía para las cuentas IMAP y de Google Workspace, así que no arranca nada nuevo por sí solo: un administrador activa Graph o el archivado IMAP en el trabajo. Pausar un trabajo solo detiene sus copias programadas; el archivado continúa.
0.4.4
Todas las ediciones
-
Página del archivo: estado de la captura, confirmación de retención, comandos de PowerShell y direcciones de reenvío
La página del archivo muestra la captura desde los buzones (flujos, cómo se detecta el correo y por qué un buzón se comprueba a intervalos, recuentos de 24 horas y 7 días, la asunción del correo existente), la captura por buzón con una puesta al día a petición y, por fuente de Microsoft 365, la confirmación de la retención con los comandos de solo lectura de PowerShell de Exchange Online que la comprueban. El journaling de Exchange viene como comandos de PowerShell ya preparados (conector, buzón para informes de journaling no entregables, regla de journaling) y una espera del primer informe que comprueba cada 5 segundos. El reenvío tiene una dirección por cuenta IMAP (creada, copiada, renovada tras una pregunta), su estado e instrucciones para Postfix, mailcow, Sieve y Google Workspace. Un aviso que se puede ocultar nombra los trabajos de correo en los que se podría activar Graph o el archivado IMAP, y el estado de la captura lista los trabajos que esperan una vía.
0.4.4
BusinessService Provider
-
Alertas cuando la captura del archivo se detiene
La alerta archive.failed (campana, reglas, correo) informa ahora también de un buzón cuya captura lleva más de una hora en error, de una cuenta IMAP cuyas copias reenviadas llevan 24 horas sin llegar aunque su trabajo las quiere, y de una dirección de journaling sin informes desde hace 24 horas, en cada caso solo después de haber recibido antes y una vez por periodo de fallo. La campana y el correo dicen de cuál se trata y llevan a su sección de la página del archivo.
0.4.4
BusinessService Provider
-
Límites del receptor de journaling y una cadena del archivo que ya no se bifurca
Una transacción SMTP entrega en el archivo de un solo inquilino; un destinatario de un segundo inquilino recibe 452 y el remitente lo entrega por separado. El límite por IP emisora sube de 60 a 600 conexiones por minuto, y un nuevo límite por dirección de archivo (300 por minuto) responde 451. El correo dirigido a la dirección de journaling que no es un informe de journaling se archiva como copia reenviada en lugar de como informe incompleto. Corregido: la cadena del archivo podía bifurcarse cuando dos escritores de un inquilino marcaban sus elementos con la misma hora. Los escritores toman ahora el último elemento en el orden que recorre la comprobación de la cadena (hora, luego id) y marcan el suyo estrictamente más tarde.
0.4.4
BusinessService Provider
-
Explorador de restauración: los buzones y OneDrives grandes se abren en milisegundos
Abrir un buzón o un OneDrive grande en el explorador de restauración ya no tarda de segundos a minutos. Antes, cada listado de carpeta leía dos veces por solicitud todas las entradas del punto de restauración y comparaba con ellas las carpetas de debajo sin índice; ahora lee los hijos de la carpeta y las carpetas de debajo desde dos índices nuevos. En una prueba con 120.000 mensajes y 200.000 archivos, la lista de carpetas de correo pasó de 2,5 s a 15 ms, la raíz del buzón y del OneDrive de más de un minuto a 15 ms, y cada carpeta de OneDrive de 1,5 a 2,5 s a unos 10 ms; una carpeta de 50.000 mensajes muestra su primera página en unos 0,5 s (antes 1,9 s). Las versiones que OneDrive conservó de un archivo y la vista mensual del calendario leen los mismos índices, y la vista previa del correo y la descarga de adjuntos leen exactamente los bytes de un fragmento con una solicitud de rango, en lugar de descargar todo su pack de hasta 64 MiB. Los puntos de restauración de la 0.3.4 y anteriores que el worker aún no ha convertido se listan como antes. Los índices se construyen mientras se ejecuta la actualización, lo que tarda más en una instalación grande (véanse las notas de actualización).
0.4.4
Todas las ediciones
-
Proxmox VE: el diálogo de trabajos cabe en una pantalla de escritorio
El diálogo de trabajos de Proxmox VE es el doble de ancho y distribuye sus ajustes en dos columnas a partir del ancho de una tableta (nombre y programación con las próximas ejecuciones a la izquierda; alcance, puntos de restauración, comprobación de restauración, prueba de arranque e invitados a la derecha), de modo que los ajustes de un trabajo caben en una pantalla de escritorio sin desplazarse. En un teléfono sigue siendo una columna a todo el ancho.
0.4.4
Todas las ediciones
-
0.4.5
-
Claves de licencia con periodo de actualizaciones
Una clave de licencia puede llevar las condiciones de sus actualizaciones: un periodo de actualizaciones (updates_until) y una serie. Una clave con periodo de actualizaciones cubre todas las versiones creadas hasta el final de ese día (UTC), sea cual sea su número de versión. Una clave sin él cubre una serie entera: el formato de clave restow-license-v1 la nombra, y una clave sin serie cuenta como la serie 1, que también cubre todas las versiones 0.x. Todas las claves emitidas hasta ahora son licencias beta: no llevan ninguno de los dos miembros y cubren de forma permanente todas las versiones 0.x y 1.x. El formato acepta los miembros nuevos como opcionales e ignora los que no conoce, de modo que las claves que emita más adelante el servidor de licencias siguen verificándose; los seis miembros de hoy siguen siendo obligatorios y conservan sus reglas. Una clave también puede nombrar la clave de firma del fabricante con la que se firmó (kid), para poder rotar una clave de firma sin romper las claves emitidas. Las claves con los miembros nuevos solo se verifican a partir de la 0.4.5. Las claves se siguen verificando sin conexión: Restow no contacta con ningún servidor de licencias y nada se detiene mientras funciona, porque una clave no caduca; solo hay versiones que cubre y versiones que no.
0.4.5
BusinessService Provider
-
La imagen lleva su fecha de publicación
Cada imagen lleva la fecha de su versión (RESTOW_RELEASED_AT, la fecha de la confirmación de la etiqueta de la versión), y GET /api/v1/status la devuelve como releasedAt. Las notas de la versión publican la misma fecha en una línea released: junto a los digests de las imágenes, y así la comprobación de actualizaciones conoce la fecha de una versión antes de instalar nada. Las claves de licencia con periodo de actualizaciones se miden con esta fecha.
0.4.5
Todas las ediciones
-
La comprobación de actualizaciones y el arranque respetan el periodo de actualizaciones
La comprobación de actualizaciones marca las versiones que la clave de Business o Service Provider instalada no cubre y lo dice con calma en la página Actualizaciones: la versión instalada sigue funcionando y la versión cubierta más reciente se instala como siempre. Restow se niega a instalar o planificar una versión no cubierta (409 update-not-covered), y la campana y las reglas de alerta update.available anuncian solo la versión cubierta más reciente. Una versión que se arranca a mano, sin pasar por la comprobación de actualizaciones, y que la clave instalada no cubre se detiene antes de sus migraciones de la base de datos, con una línea de registro que nombra la versión, el final del periodo de actualizaciones y la fecha de la última versión cubierta; para volver atrás no hay que restaurar nada, y el actualizador opcional repone la versión anterior por sí mismo. Con RESTOW_RUN_AS_COMMUNITY=1 arranca en su lugar como Community: los módulos siguen apagados y no se cambia ningún dato. Nada de esto vale para licencias beta, compilaciones de desarrollo, instalaciones sin clave ni la demo pública.
0.4.5
BusinessService Provider
-
Página de licencia: condiciones de actualización, un aviso antes del final y la renovación
La página de licencia muestra qué actualizaciones incluye la clave instalada («Actualizaciones: todas las 1.x (licencia beta)» o «Actualizaciones: hasta» con la fecha) y, desde 30 días antes del final del periodo y después de él, un aviso breve en la misma página; no se envía ningún correo. Una clave nueva sustituye a la activa aunque esta esté en vigor, y así se instala una renovación: las claves anteriores quedan en el historial, y cada instalación o sustitución se anota en el registro de auditoría con las condiciones de actualización de la clave y si cubren la versión en ejecución. Se rechaza una clave que no cubre la versión en ejecución (outside_update_period), y también una firmada con una clave de firma del fabricante que esta versión aún no conoce (unknown_signing_key): primero actualice y después instálela.
0.4.5
BusinessService Provider
-
Demo pública: un reinicio nocturno rápido
La demo pública se reinicia desde una plantilla guardada en lugar de volver a rellenarse. Tras un relleno completo, deploy/demo/reset.sh guarda una plantilla (un volcado de la base de datos de la demo, sus roles y una copia de cada volumen que escribe el relleno) ligada a la versión, los identificadores de las imágenes y el .env, y la restaura en las noches siguientes, de modo que la demo queda fuera de línea unos 15 a 25 segundos en lugar de muchos minutos. Al restaurar, cada hora del sistema avanza la antigüedad de la plantilla, así que el historial sigue terminando hoy y «última copia hace 12 minutos» sigue siendo cierto; el registro de auditoría, el archivo de correo y las propias horas de las instantáneas de restic conservan sus horas reales, y se eliminan los inicios de sesión. Una plantilla de más de 7 días (configurable), una versión nueva, imágenes nuevas, un .env modificado o una restauración fallida conducen a un relleno completo. Las comprobaciones de estado de los servicios de la demo se ejecutan cada 2 a 5 segundos en lugar de cada 10 a 15, de modo que un reinicio espera menos a servicios que ya están listos. Afecta solo a la demo pública, no a una instalación.
0.4.5
Todas las ediciones
-
Quitar un equipo revocado de Restow, con o sin sus copias
Un equipo revocado se puede quitar de Restow. «Quitar de Restow» en su zona de peligro 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», con el nombre de host escrito y un inicio de sesión reciente. 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 aplazan hasta que su bloqueo termina, y se anotan como una depuración rechazada. La página de equipos lista las eliminaciones aún pendientes, con la fecha, la retención o el bloqueo. Cada paso se audita. La migración 0064 añade el estado de eliminación a los equipos.
0.4.5
Todas las ediciones
-
Revocar un equipo que ya no existe, y una sugerencia para hacerlo
Una desinstalación que espera a un equipo apagado ofrece ahora «Revocar ahora», y un equipo sin contacto durante más de un número configurable de días (30 por defecto, en Alertas del equipo) sugiere revocarlo, en su página y entre lo que requiere atención. El panel de detalle del equipo en el inventario muestra la sugerencia como un estado y ofrece «Revocar ahora» y, una vez revocado el equipo, también «Quitar de Restow».
0.4.5
Todas las ediciones
-
Aviso cuando un repositorio de directorio está en el disco del sistema
Restow avisa cuando un repositorio de directorio está en el disco del sistema del servidor de Restow, el disco bajo el sistema operativo, Docker y la base de datos: un disco del sistema lleno detiene todo, no solo las copias. La api lo reconoce desde dentro de su contenedor por el dispositivo y el dispositivo de bloques de la ruta, incluidos el valor por defecto de la instalación y los recursos del montador. El aviso aparece en la página Repositorios, en la línea «Las copias van a:» de los editores de trabajos y en el mosaico de almacenamiento del panel, donde los administradores del proveedor ven además el espacio libre, su tendencia de la última semana y cuándo se llenaría el disco. La api también vigila ahora el disco del sistema por poco espacio. No se bloquea nada.
0.4.5
Todas las ediciones
-
Grupos de Microsoft 365 como objetos protegidos: calendario y conversaciones
El calendario y las conversaciones de los grupos de Microsoft 365, y de los grupos que hay detrás de Teams, son objetos protegidos de un tipo propio, group. La sincronización del directorio lee groups/delta como un segundo flujo delta junto a los usuarios (una enumeración completa en la primera y en cada sincronización completa, solo cambios entre medias), conserva solo los grupos de Microsoft 365 (los grupos de seguridad y de distribución no tienen buzón de grupo) y deja huérfanos los eliminados, cuyos puntos de restauración permanecen. Los grupos son opcionales: las reglas de protección tienen un interruptor «Proteger todos los grupos de Microsoft 365» (por defecto solo los grupos seleccionados, es decir, ninguno mientras no los incluya en la lista de objetos protegidos), y los grupos sueltos se pueden incluir ahí. Un trabajo de correo con alcance «todos» cubre cada grupo protegido, como los sitios. Los buzones de grupo nunca cuentan como buzones protegidos. La migración 0065 añade el tipo de objeto. Tras la actualización no se copia ningún grupo hasta que las reglas de protección lo activen o se incluyan grupos; la primera sincronización del directorio lee una vez completos los grupos de cada fuente de Microsoft 365.
0.4.5
Todas las ediciones
-
Calendario y conversaciones de grupo: qué contiene una copia
La copia de un grupo contiene su calendario, leído por el mismo código de calendario que el de un usuario (series maestras con sus excepciones), y cada publicación de cada conversación, guardada como mensaje RFC 5322 en mail/Conversations con sus archivos adjuntos cuando Graph los entrega (si no, se anota su ausencia). Si Graph niega a la aplicación el listado de eventos de un calendario de grupo, Restow recurre a calendarView del grupo y a una lectura por serie maestra; un calendario que Graph niega por completo es una advertencia de la ejecución, no un fallo. Solo se vuelven a leer los hilos con publicaciones nuevas. Un grupo que ya no existe falla con la causa nueva graph.group_unavailable. No hace falta ningún permiso nuevo de Microsoft: Group.Read.All y Calendars.ReadWrite siempre fueron necesarios. Probado contra una API de Graph simulada, nunca contra un inquilino real de Microsoft 365: las lecturas de calendario que Graph permite a una aplicación sobre un grupo pueden variar según el inquilino, y la copia informa de lo que no pudo leer.
0.4.5
Todas las ediciones
-
Calendario y conversaciones de grupo: restauración, descarga y exportación
El explorador de restauración lista los grupos en la sección «SharePoint y Teams» con las áreas «Calendario del grupo» y «Conversaciones»; la descarga (EML, JSON) y la exportación (EML, MBOX, PST) funcionan como en los buzones. Una restauración en el buzón de un usuario recupera eventos y conversaciones, las conversaciones como correo en una carpeta Conversations. Una restauración en el propio grupo recupera solo eventos de calendario, porque Microsoft Graph no permite a ninguna aplicación publicar en una conversación de grupo: cada publicación se informa como no restaurable, con las vías que funcionan. Restaurar un grupo no es una suplantación, porque un grupo no pertenece a ninguna persona. La API de integración informa de lastSuccess.groups y ObjectKind incluye group (contrato 1.6.0, aditivo: los clientes que tratan los tipos de objeto de forma exhaustiva deberían aceptar el valor nuevo), y el panel lista los calendarios y las conversaciones de grupo entre las últimas copias.
0.4.5
Todas las ediciones
-
Iniciar ahora y Detener en cada trabajo
Las dos listas de trabajos, Servidores y equipos y Mail & SaaS, tienen «Iniciar ahora» y «Detener» en cada fila y en el menú «…» de la fila: un botón de tamaño fijo que dice «Iniciar ahora», «Detener» mientras las copias del trabajo se ejecutan o esperan, y «Deteniendo…» una vez pedido. Detener pregunta antes y dice qué significa para el tipo de trabajo. El antiguo «Run now» se llama ahora «Iniciar ahora». Rutas nuevas de la API: POST /api/v1/backup-jobs/:id/cancel (cada copia en cola o en ejecución de un trabajo de correo, de equipo, de recurso compartido o de copia, en una sola solicitud), POST /api/v1/pve/jobs/:id/run (una copia de cada invitado que cubre un trabajo de Proxmox VE (vista previa), como lo haría su programación, sin mover la programación) y POST /api/v1/pve/jobs/:id/cancel. Todas se auditan, son para los administradores del inquilino y los roles del proveedor que pueden operar, y están cerradas en la demo pública.
0.4.5
Todas las ediciones
-
Paneles de detalle en el inventario y en las listas de trabajos
El inventario y las listas de trabajos abren un panel de detalle como el de VMs y contenedores: un clic en una fila, en su nombre o en su estado lo abre (?machine=<id> en el inventario, ?job=<id> en las listas de trabajos, de modo que un enlace lo abre). Lista cada estado, los textos completos de error y de aviso de la copia más reciente o de la ejecución fallida en un bloque de ancho fijo que se puede copiar (en un equipo también el final del registro), lo que requiere atención, las comprobaciones de restauración, los datos clave, las ejecuciones más recientes y las acciones. Las tablas mantienen su diseño como VMs y contenedores: anchos de columna fijos, una sola altura de fila (también en las filas que cargan), una insignia de estado compacta por fila (la más urgente de las que corresponden; verde solo si la comprobación de restauración se superó) con el progreso de una copia en ejecución al lado, celdas de una línea sin información emergente y botones de acción de un solo tamaño. Las columnas que no caben en una pantalla ceden desde la derecha; el panel lo tiene todo.
0.4.5
Todas las ediciones
-
Dependencias: bibliotecas de traducción y el código de tokens de Microsoft
Actualización mayor de las bibliotecas de traducción, i18next 26 y react-i18next 17, actualizadas juntas; los textos, los plurales y los formatos de número y fecha se leen exactamente como antes en inglés y alemán. @azure/msal-node ya no es una dependencia, porque nada lo usaba: los tokens de la aplicación de Microsoft 365, el consentimiento del administrador y el inicio de sesión OAuth2 de IMAP usan el cliente de tokens propio de Restow, sin cambios.
0.4.5
Todas las ediciones
-
Correcciones: carpeta de adjuntos en el explorador de restauración, diálogo de trabajos de Proxmox VE en el teléfono, reinicio de la demo
En el explorador de restauración, un mensaje de correo guardado como JSON (demasiado grande para un mensaje normal) ya no muestra a su lado una carpeta <asunto>.attachments vacía: sus adjuntos se restauran con el mensaje y nunca se listaron, y la fila de carpeta que la copia registra para ellos queda ahora oculta del listado, del árbol de carpetas y de la búsqueda. El diálogo de trabajos de Proxmox VE (vista previa) apila en el teléfono (390 px) sus tres campos de puntos de restauración, de modo que «Puntos de restauración mensuales» ya no se sale del borde del diálogo. El script de reinicio de la demo pública lee ahora RESTOW_DEMO_COMPOSE_FILES de deploy/demo/.env, como decía siempre su README, y rechaza las entradas que no son archivos de Compose antes de detener nada.
0.4.5
Todas las ediciones
-
Comprobación del inquilino de Entra y del secreto OAuth2 de IMAP
El asistente de configuración acepta el inquilino de Entra para el correo de Graph solo como identificador de inquilino (GUID) o dominio verificado, como ya hacían los Ajustes; cualquier otra cosa se rechaza (422) antes de que pueda llegar a la URL del token. La URL nunca estuvo abierta a otro host (el valor se codifica como URL y el host de inicio de sesión es fijo), pero un valor como .. cambiaba su ruta. Se rechaza un secreto OAuth2 de IMAP si su tenantId no es un identificador de inquilino, un dominio verificado, common, organizations o consumers, y si su tokenEndpoint no es una URL https. Ni la API ni la interfaz crean todavía esos secretos; la solicitud del token necesitará además la política de direcciones de las conexiones IMAP antes de ofrecer XOAUTH2.
0.4.5
Todas las ediciones
-
0.4.6
-
Proxmox VE: la restauración de un contenedor funciona en el Proxmox VE actual
Restaurar un contenedor desde Restow fallaba con Can't use string ("restow") as a HASH ref en el Proxmox VE actual, que pasa el ID del almacenamiento a la restauración de contenedores del proveedor de copias antes del hash de información. Las pruebas de arranque de contenedores («No arrancó») y «Restaurar como invitado nuevo» de contenedores se veían afectadas; las VM no. El complemento de restow-pve acepta ahora ambas formas; se instala con la actualización de restow-pve, que recarga los demonios de PVE. Actualice restow-pve en cada nodo de Proxmox VE antes de fiarse de las restauraciones de contenedores o de las pruebas de arranque (el servidor lo ofrece tras su propia actualización, y los nodos se actualizan solos cuando están libres); hasta entonces siguen fallando como antes. Para los puntos de restauración de contenedores que dicen «No arrancó» o tienen una comprobación de restauración fallida de antes de la 0.4.3, ejecute «Probar arranque ahora» o «Comprobar ahora» cuando el nodo esté actualizado. Probado con pruebas en Perl del complemento (la restauración del contenedor con y sin el ID del almacenamiento); no se ejecutó contra un nodo real de Proxmox VE antes de la versión.
0.4.6
Todas las ediciones
-
Detección de ransomware: una cadena de copias nueva ya no se marca
La primera copia de la cadena de copias nueva de un contenedor (su repositorio faltaba o se reinició) se juzgaba frente a la cadena antigua y se marcaba como sospechosa, porque en un repositorio vacío cada archivo es nuevo. La base de comparación empieza ahora con la cadena más reciente. Un punto de restauración marcado así antes de la actualización sigue marcado: márquelo como falsa alarma. La primera copia de una cadena nueva se llama además «Primera copia», no «Incremental».
0.4.6
Todas las ediciones
-
Los equipos quitados conservan sus copias navegables
Hasta que se eliminan sus copias, la página de un equipo quitado ofrece su restauración y nada más: los puntos de restauración, la exploración, la descarga en ZIP y la clave del repositorio siguen funcionando para ellas, con auditoría como antes. La lista de equipos quitados enlaza «Restaurar archivos». Restaurar sobre el equipo y cualquier otra acción siguen rechazadas (404); una vez eliminadas las copias, el equipo desaparece para cualquier lector. Antes de la 0.4.6 la interfaz no ofrecía las copias que un equipo quitado conserva hasta que caducan; desde la 0.4.6 sí.
0.4.6
Todas las ediciones
-
«Comprobación en cola» mientras espera una comprobación de restauración
Tras «Comprobar ahora» de una VM o un contenedor, la fila dice «Comprobación en cola» bajo la última comprobación, y la página del invitado lo dice sobre el resultado anterior, hasta que llega el resultado; ambas se actualizan cada pocos segundos mientras tanto.
0.4.6
Todas las ediciones
-
Los textos de error se abren en una tarjeta que se puede copiar
Los textos de error tras una insignia o una línea cortada (la prueba de arranque, la comprobación de restauración de una VM o un contenedor en su página y en la tabla de preparación de recuperación) se abren al pasar el ratón o con el foco del teclado en una tarjeta con el texto completo, seleccionable y con un botón Copiar, en lugar de una información emergente del navegador. Una prueba de arranque que no arrancó muestra el mensaje del nodo bajo su insignia, en la página del invitado y en la tabla de preparación de recuperación.
0.4.6
Todas las ediciones
-
0.4.7
-
Microsoft 365: los objetos desactivados, sin licencia y bloqueados figuran como «No se copia», con el motivo
Un buzón cuya cuenta está desactivada o no tiene licencia de Exchange Online ya no hace fallar su copia cada noche con «Microsoft rechazó la solicitud». La copia pregunta una vez a Microsoft si el usuario existe pero no tiene buzón, marca el buzón «No se copia: cuenta desactivada» o «No se copia: sin licencia» y termina de forma neutra: sin cómputo de fallos, sin rojo en la preparación por la antigüedad, sin considerarse atrasado, sin alerta backup.failed ni webhook job.failed, y las copias existentes se conservan. La sincronización del directorio fija el mismo estado a partir de su sondeo del buzón. Solo cuenta la respuesta de Exchange: una cuenta desactivada cuyo buzón Microsoft sigue sirviendo (un buzón compartido, una persona que ya no está) se copia como antes, y un 401 o 403 nunca se interpreta así. Lo mismo vale para un OneDrive o un sitio de SharePoint que Microsoft bloqueó (HTTP 423, algo que Microsoft hace con el OneDrive de una cuenta sin licencia): en cuanto una única lectura barata confirma el bloqueo, figura como «No se copia: bloqueado», termina sin reintentos y deja de planificarse; la sincronización del directorio solo lo reanuda cuando vuelve a funcionar una lectura de la unidad o del sitio. La copia se reanuda sola tras la sincronización del directorio que encuentra la cuenta de nuevo activada o con licencia. Una restauración en el buzón original se rechaza con el motivo. Probado con una API de Microsoft Graph simulada, no con un inquilino real de Microsoft 365.
0.4.7
Todas las ediciones
-
Ya no se copia, confirme
Los objetos que Restow deja de copiar porque la fuente dice que ya no existen, están desactivados, sin licencia o bloqueados figuran primero en ámbar como «Ya no se copia, confirme», con el motivo y la fecha. No es un fallo, ni rojo, ni atrasado, pero los avisos, el panel y la preparación del inquilino quedan al menos en amarillo (nunca en verde), la API de integración los cuenta en readiness.toConfirm y los proveedores ven inactive_to_confirm entre las alertas de un inquilino, hasta que un administrador confirma «Sí, es intencionado»: por objeto, o para varios en la lista, por selección o por el filtro de la lista (como máximo 1000). Pueden confirmar los administradores del inquilino y los equipos del proveedor con derecho de configuración, y cada confirmación queda en el registro de auditoría; por la API puede llevar una nota para ese registro. Los objetos confirmados figuran en gris como «Ya no se copia a propósito», con quién lo confirmó y cuándo. Cuando el objeto vuelve a estar activo, la confirmación se descarta y la copia se reanuda; si más tarde vuelve a detenerse, Restow vuelve a preguntar. Un objeto excluido que desaparece de la fuente nunca se copió y cuenta como confirmado. La lista de objetos protegidos filtra por to_confirm y confirmed. Los eventos nuevos object.inactive (un aviso por objeto y transición, por defecto en la campana) y object.inactive_many (una advertencia por inquilino y día cuando más de 10 objetos, o más del 20 por ciento de los copiados antes, dejan de copiarse en un día) forman parte de la matriz de notificaciones; un webhook los recibe como report.alert en cuanto están marcados. Los objetos que ya estaban huérfanos antes de la actualización cuentan como confirmados, así que no aparece una larga lista en ámbar. La migración 0069 guarda el estado.
0.4.7
Todas las ediciones
-
API de integración 1.7.0: orphaned significa ahora también «ya no se copia»
El único cambio incompatible de la versión: el estado «orphaned» en GET /api/v1/objects, GET /api/v1/users, el object de GET /api/v1/jobs y objects.orphaned de GET /api/v1/status abarca ahora también los objetos que siguen en la fuente pero ya no se copian (cuenta desactivada, sin licencia o bloqueados por Microsoft); antes significaba eliminado de la fuente. El nuevo statusReason (account_disabled, no_license, locked, null para un objeto eliminado de la fuente) los distingue, así que una integración que trate orphaned como una cuenta borrada debería comprobarlo antes de actuar. Todo lo demás del contrato crece de forma aditiva: inactiveSince y statusConfirmedAt en los objetos, toConfirm en el resumen de preparación de status y verify/latest, una recoveryReadiness de usuario que figura al menos en amarillo mientras uno de sus objetos espera una confirmación, los invitados excluidos de Proxmox VE como guests.excluded (fuera de guests.total y guests.withoutJob), el motivo de omisión inactive en POST /api/v1/jobs/backup, data.job.result en los webhooks job.completed y job.failed de una restauración y los nuevos eventos de alerta. Los clientes que traten de forma exhaustiva los motivos de omisión o los nombres de evento deben aceptar los valores nuevos.
0.4.7
Todas las ediciones
-
Las copias que Microsoft Graph o el almacenamiento retuvo ya no cuentan como fallidas
Una copia de Mail & SaaS que termina, tras todos sus reintentos, con graph.throttled, graph.service_unavailable o storage.rate_limited figura en ámbar como «Retenida por el servicio, se reintenta» en lugar de «Fallida» en rojo, en todas las vistas: Historial, la vista de trabajos de todos los inquilinos, la lista de objetos, las ejecuciones de un trabajo, la página del trabajo, el panel y los detalles de la ejecución. Queda fuera de los recuentos de fallos de las estadísticas y del panel, no hace que el trabajo figure como fallido (cuenta la ejecución anterior), no pone en rojo un aviso ni termina su reconocimiento, y no genera alerta backup.failed ni webhook job.failed. La siguiente ejecución programada lo intenta de nuevo, y un objeto retenido durante más tiempo lo detectan las reglas de copias atrasadas y de preparación, que miran la antigüedad de la copia más reciente. Una restauración, exportación, importación o comprobación que un servicio retuvo no tiene una siguiente ejecución y sigue siendo un fallo. Las ejecuciones anteriores que terminaron con estas causas se muestran igual tras la actualización y salen de los recuentos de fallos de periodos pasados. Un trabajo en segundo plano respeta además un Retry-After de hasta 5 minutos (antes las esperas se limitaban a aproximadamente un minuto, y Exchange rechaza un reintento antes de que termine su penalización de concurrencia de buzones); las solicitudes de la interfaz conservan el límite de un minuto.
0.4.7
Todas las ediciones
-
Un permiso concedido a la aplicación de Microsoft 365 surte efecto sin un secreto de cliente nuevo
Un token lleva los permisos de la aplicación tal como eran cuando se emitió, y Restow lo conservaba hasta poco antes de que caducara (hasta aproximadamente una hora), así que un permiso que un administrador concedió entretanto se rechazaba hasta entonces o hasta que se introducía un secreto nuevo. Cuando Graph responde 401 o 403, Restow obtiene ahora un token nuevo una vez y vuelve a enviar la solicitud, como máximo una vez por minuto por inquilino o fuente, de modo que una serie de rechazos (un elemento que la aplicación no puede leer) no obtiene un token cada vez; las subsolicitudes rechazadas de un $batch también se reenvían una vez. Una solicitud rechazada de nuevo con el token nuevo falla como antes. Esto vale para las copias, las restauraciones, la sincronización del directorio, la captura del archivo, la búsqueda de grupos, la prueba de conexión y la comprobación del consentimiento. A un punto de acceso de tokens que no responde se le pregunta dos veces más (a 1 y 4 segundos) y después hace fallar la ejecución, que continúa desde su punto de control, en lugar de anotar cada elemento como fallido. El correo de notificaciones mediante un registro de aplicación todavía no obtiene un token nuevo tras un rechazo: un permiso Mail.Send concedido más tarde surte efecto cuando caduca el token en caché.
0.4.7
Todas las ediciones
-
Una copia en cola ya no bloquea la cola de copias de todos los inquilinos
Una copia en cola de un objeto cuya copia seguía en curso (la siguiente ejecución programada, «Copiar ahora») bloqueaba la cola de copias de todos los inquilinos hasta que esa copia terminaba, porque la cola de trabajos la ofrecía siempre primero y no entregaba nada. Un trabajo así espera ahora a la copia en curso de su objeto y deja pasar a todas las demás. Restow incluye para ello pg-boss 10.4.2 con un parche propio; las imágenes lo llevan, y quien compila desde el código fuente conserva la carpeta patches.
0.4.7
Todas las ediciones
-
Recordatorios antes de que caduque el secreto de cliente o el certificado de un registro de aplicación
Restow avisa a los administradores del proveedor 30 días antes de que caduque el secreto de cliente o el certificado del registro de aplicación central de Microsoft 365, de nuevo 7 días antes y una vez caducado, cada etapa una vez por fecha de caducidad; el evento installation.app_secret_expiring es una advertencia, un error una vez caducado. Una fuente conectada mediante un registro de aplicación propio recibe los mismos recordatorios como source.app_secret_expiring, que también pueden elegir los administradores del inquilino. La fecha es la introducida en Instalación › Aplicación multiinquilino de Microsoft (ENTRA_CLIENT_SECRET_EXPIRES_AT para un secreto del entorno), el «El secreto caduca el» de la aplicación propia de una fuente, o el fin del propio certificado; Restow no la lee de Microsoft Graph, lo que exigiría Application.Read.All. En una fuente, la tarjeta de conexión muestra «Caduca», y la fecha puede anotarse, cambiarse o quitarse allí sin volver a introducir el secreto. Una fecha, un secreto o un certificado nuevos reinician los recordatorios. La campana nombra la etapa («caduca en 5 días», «Renuévelo ahora», «ha caducado»), y el correo indica la fecha, los días que quedan y el ID de la aplicación y explica cómo renovar sin interrupción: crear el secreto nuevo, introducirlo con su fecha nueva y solo entonces borrar el antiguo en Entra. La insignia de caducidad pasa a ámbar 30 días antes del final en lugar de 60, y a rojo desde 7. Las fuentes conectadas mediante una aplicación propia antes de la 0.4.7 todavía no tienen fecha: anótela en la página de la fuente.
0.4.7
Todas las ediciones
-
Buzón, OneDrive, SharePoint e IMAP: un error cuesta un área o un elemento, no toda la ejecución
Copia de buzones: un 403 en calendarios o contactos (permiso que falta, una política de acceso que solo cubre el correo) hace fallar esa área y conserva el correo de la ejecución, en lugar de descartar la instantánea; un 401 a mitad de una ejecución guarda un punto de control y continúa; una carpeta conocida que Graph se niega a resolver se trata como ausente; un enlace delta que Graph rechaza como estado de sincronización no válido lleva a una resincronización completa; un mensaje que Exchange no puede convertir a MIME se guarda como JSON con sus adjuntos, como uno demasiado grande; una subcarpeta borrada mientras se listaba su carpeta superior ya no hace fallar la ejecución. SharePoint: una biblioteca o lista que Graph no entrega es un fallo de elemento que conserva su última copia, y el resto del sitio recibe su instantánea. OneDrive y SharePoint: un elemento que falló y pasó más tarde en la misma ejecución ya no queda entre los fallos, y un OneDrive cuya unidad Graph ya no encuentra falla como «OneDrive no disponible», permanente y sin reintentos. Copia IMAP: un inicio de sesión que el servidor rechaza por ahora (demasiadas conexiones, un sistema de autenticación caído) y un límite de descarga son la nueva causa transitoria imap.server_limit, que se reintenta sola, en lugar de una contraseña incorrecta o un buzón lleno; los mensajes borrados o movidos durante la copia no cuentan como fallos. Captura IMAP del archivo: un mensaje que el servidor rechaza ya no retiene su carpeta ni toda la pasada (tras tres pasadas la captura lo abandona), y las carpetas que una pasada no alcanzó conservan su estado. Cada $batch de Graph envía además una lectura idéntica solo una vez, de modo que un ID de solicitud repetido ya no hace fallar un lote, y una conexión cortada antes de que Graph respondiera se reintenta en las lecturas.
0.4.7
Todas las ediciones
-
Las restauraciones que no restauraron nada ya no se notifican como completadas
Una restauración completada con elementos fallidos y ninguno restaurado figura como «Nada restaurado» (rojo) y genera restore.failed y el webhook job.failed, con «Nothing was restored: N items failed.» como error. Una que omitió todos los elementos figura como «Todo omitido» (ámbar) y sigue siendo restore.completed, pero lo dice en lugar de afirmar que restauró algo (información, no éxito, en los canales de chat). Los webhooks job.completed y job.failed de una restauración completada llevan sus contadores en data.job.result (restored, skipped, failures, unverified).
0.4.7
Todas las ediciones
-
Preparación para restaurar y copias atrasadas: objetos eliminados, miembros con calendario propio, copias en curso
Un objeto eliminado de su fuente (un buzón borrado en Microsoft 365, por ejemplo) ya no se pone en rojo porque su última copia envejece: nada lo copia ya y la retención conserva siempre su punto de restauración más reciente, así que se valora según si esa copia se restaura, sin los motivos de antigüedad, y nunca está atrasado; una copia conservada que no se restaura sigue en rojo. La misma valoración rige en las estadísticas, la lista de objetos, la preparación global del inquilino, la API de integración y la notificación verify.completed; la tabla dice «Eliminado de la fuente, copias conservadas», y la página del informe empieza con una nota «Eliminado de la fuente». Un objeto cuya copia más reciente nunca se comprobó recibe una comprobación más del planificador semanal. En backup.overdue, un miembro de buzón con calendario propio se juzga por ese calendario o por los trabajos de correo del inquilino (el más relajado), lo que permita más tiempo, así que un miembro semanal de un trabajo diario ya no está atrasado dos días después de su copia, y un objeto cuya copia ha empezado y sigue en curso (hasta 21 días, una primera copia grande) tampoco está atrasado.
0.4.7
Todas las ediciones
-
Proxmox VE: excluir un invitado de la copia a propósito
Un administrador puede excluir una VM o un contenedor de la copia, para VM de prueba o invitados que se copian en otro sitio: «Excluir de la copia» en la página del invitado o, para una selección de los invitados de un nodo, en el inventario; «Incluir de nuevo» lo devuelve. Pueden hacerlo los administradores del inquilino y los administradores del equipo del proveedor. Ningún trabajo copia un invitado excluido, ni siquiera el trabajo de todos los invitados, y el trabajo recomendado lo deja fuera; su propio trabajo sigue registrado, de modo que al incluirlo de nuevo recupera lo que tenía. Excluir retira sus copias en cola (una copia puesta en cola en el mismo momento se retira en el siguiente latido del nodo, antes de que el nodo la reciba), y «Copiar ahora» y poner el invitado en un trabajo se rechazan hasta que se incluya de nuevo. Un invitado excluido no cuenta como desprotegido en ningún sitio: ni en las vistas generales, la preparación para restaurar, los avisos, backup.overdue, las estadísticas ni la vista del proveedor, y nunca impide que un inquilino esté en verde; los recuentos de invitados lo cuentan como excluido. En VMs y contenedores figura como «Excluido» (gris, nunca un problema) y tiene un filtro de estado propio, y el inventario muestra «Excluido: N» por nodo. Sus puntos de restauración siguen siendo restaurables, y la retención los trata como antes. Ruta nueva PUT /api/v1/pve/guests/:id/excluded, auditada como pve.guest.excluded. La actualización no excluye ningún invitado; los invitados sin trabajo siguen contando como «sin trabajo de copia» hasta que un administrador los excluya. restow-pve no necesita actualización para esto.
0.4.7
Todas las ediciones
-
Proxmox VE: el tamaño de la primera copia y de una copia posterior como texto en el inventario
El inventario muestra el tamaño de la primera copia de un invitado («Primera copia el» con la fecha y el tamaño guardado) y lo que añade de media una copia posterior («Media por copia posterior» con el tamaño y el número de copias en que se basa) como texto en la fila del invitado, no solo en su información emergente, de modo que ambos se pueden leer y copiar.
0.4.7
Todas las ediciones
-
Trabajo recomendado con el archivo de correo
Mientras la instalación ofrezca la captura del archivo desde el buzón (Business y Service Provider) y el inquilino tenga buzones o cuentas que un archivo pueda capturar, «Crear el trabajo recomendado» y «Proteger todo lo que no tiene trabajo» hacen que el nuevo trabajo de correo sobre todos los objetos copie y archive. Un trabajo de correo sobre todos los objetos que ya existe y todavía no archiva se cambia a archivar («Activar el archivado en …»); sus programaciones se conservan, y el cambio queda auditado como una edición en el editor de trabajos. El clic usa las vías de captura que no necesitan nada más en el inquilino: Microsoft Graph para los buzones de Microsoft 365, sincronización IMAP para las demás cuentas; el journaling y el reenvío siguen siendo una elección en el editor. El trabajo recomendado nunca cambia un trabajo de correo sobre objetos seleccionados (la vista previa los nombra), y un trabajo de correo sobre todos los objetos cuyas vías de captura se eligieron a mano se deja como está, cosa que dice la vista previa. La lista de trabajos de correo muestra «Activar el archivado» donde la recomendación lo activaría. Sin la captura, el trabajo recomendado se crea como antes, y los trabajos de correo existentes solo cambian cuando un administrador lo aplica.
0.4.7
Todas las ediciones
-
Precios mensuales y una estimación de precio por inquilino para proveedores
En Instalación › Precios, el propietario de la instalación introduce un precio mensual por buzón y por GB o TB de copias guardadas, en EUR, CHF, USD o GBP (como máximo cuatro decimales; un precio que se deja vacío no se muestra). Los buzones se cuentan como en el uso de buzones (un OneDrive no cuenta dos veces); el almacenamiento son las copias guardadas del inquilino, deduplicadas y comprimidas, en unidades decimales (1 GB = 10^9 bytes). Los administradores del proveedor con todos los inquilinos pueden leer los precios, solo el propietario los cambia, y cada cambio queda auditado con los valores anteriores y posteriores. La vista general de cada inquilino muestra entonces a los administradores del proveedor una tarjeta «Precio al mes» con lo que supone el inquilino a esos precios, una línea para los buzones y otra para el almacenamiento, y un enlace a los precios. Los usuarios del inquilino nunca ven los precios. Restow no factura nada y no limita nada, y los precios están vacíos tras la actualización.
0.4.7
Todas las ediciones
-
Correcciones: restauraciones de IMAP y de listas, límites de tiempo de los trabajos, semilla de la demo, textos
Una restauración IMAP cuya conexión se corta ahora falla y se reintenta en una conexión nueva, donde la comprobación del Message-ID omite lo que ya se había añadido, en lugar de terminar «completada» con todos los elementos restantes fallidos. Una restauración repetida de una lista de SharePoint en el modo «conservar ambos» ya no vuelve a añadir los elementos que añadió el intento interrumpido, y una restauración repetida de contactos en ese modo ya no crea contactos dos veces. Una restauración en un buzón indicado por dirección resuelve el buzón que aceptó la API, de modo que una dirección duplicada ya no elige otro. El límite de tiempo de un trabajo cuenta desde que la cola lo entregó, también mientras espera un hueco libre de su inquilino; una cancelación que llega mientras un intento arranca o falla se conserva; un trabajo que el reconciliador termina definitivamente genera, como cualquier otro, el webhook job.failed, la campana y las reglas de notificación. La semilla de la demo pública ya no falla cuando Restow puso en cola por sí mismo la primera copia de un objeto, lo que había dejado la demo en su página «se está reiniciando». La página del trabajo nombra las fases de la copia de un sitio de SharePoint («Leyendo el sitio», «Listas») y del descubrimiento de sitios y buzones de grupo, y las notas de retención dicen que el punto de restauración más reciente de cada objeto se conserva siempre. «Quitar de Restow» ya no dice que la restauración de archivos deja de ofrecer las copias de un equipo quitado (las ofrece desde la 0.4.6), y la página de licencia ya no enumera el inicio de sesión con Microsoft entre lo que desbloquea Business, porque todavía no está disponible.
0.4.7
Todas las ediciones
-
Dependencias: better-auth, bibliotecas de correo, Vite, React y las herramientas de compilación
better-auth 1.7.14, mailparser 3.14.1, nodemailer 10.3.1, smtp-server 3.21.3, msgreader 1.29.0, Biome 2.6.4, Vitest 5.0.5, Vite 8.3.5, React 19.3.1 y, en las pipelines de publicación, docker/login-action 4.7.0. zod 4 no forma parte de esta versión.
0.4.7
Todas las ediciones
-
Avisos de dependencias: ip-address, seroval y zod
ip-address 10.7.5 (desde 10.7.2), una dependencia transitiva a través de socks, resuelve un aviso de gravedad moderada; socks viene con la biblioteca IMAP y solo se usa para conexiones a través de un proxy SOCKS, que Restow no configura. seroval 1.7.5 (desde 1.6.7, a través del enrutador TanStack) resuelve GHSA-7rv5-mrxv-xcr9, GHSA-wp97-x4hv-qvhp y otros avisos de su deserializador, y zod 4.6.7 (una sustitución para la copia que usa better-auth) resuelve allí GHSA-mrhx-c7xc-m3w5. Ese aviso (uso de memoria al validar una matriz grande) nombra también zod 3, que usa la validación de solicitudes propia de Restow y para el que no existe un 3.x corregido; la auditoría de la CI ignora este único aviso hasta que Restow pase a zod 4. El límite de cuerpo de solicitud de la api (1 MB en la mayoría de las rutas) lo acota: una matriz de 1 MB que falla elemento a elemento cuesta unos 150 MB y un segundo de la api para esa solicitud.
0.4.7
Todas las ediciones
Por Lucas Flores, IT Systeme Flores UG. Última actualización: