← Volver a la visión general

Cómo demuestra Restow que sus copias se pueden restaurar

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

Una copia de seguridad solo vale lo que devuelve cuando hace falta. Que una tarea de copia haya terminado dice que se escribieron datos, no que se puedan volver a leer. Por eso Restow distingue dos estados: «copiado» y «restauración demostrada». Una copia solo cuenta como restaurable cuando Restow la ha releído y la ha encontrado idéntica a lo que la copia registró al hacerse.

Qué es una comprobación de restauración

Cuando Restow hace una copia, registra una huella de cada elemento: una suma de comprobación SHA-256 que cambia por completo si cambia un solo byte. Una comprobación de restauración toma una muestra aleatoria de la copia más reciente, la relee por el mismo camino que usa una restauración real, incluido el descifrado, y compara lo que vuelve con esas huellas. La comprobación se ejecuta en el servidor y lee de su almacenamiento. No escribe nada en un buzón ni sobre los archivos de un equipo.

Con qué frecuencia se ejecuta

• Buzones, OneDrive y cuentas IMAP: cada semana (el domingo a las 03:00 en la planificación recomendada, que puede cambiar) y, mientras esa planificación esté activa, después de cada copia. También puede iniciar una comprobación en cualquier momento. Una comprobación que no pudo completarse se repite unos minutos después, hasta tres veces, y si no, en la siguiente comprobación programada.
• Servidores y equipos: después de cada nueva copia correcta. Si la comprobación del servidor no pudo completarse, se repite cada hora hasta que lo consiga. La prueba de restauración en el equipo se vuelve a ofrecer al cabo de 1, 2, 4, 8, 16 y 24 horas, mientras la copia que prueba sea la más reciente del equipo; después, la siguiente copia trae una prueba nueva.
• Recursos compartidos de archivos: después de cada punto de restauración nuevo (desde la 0.4.0); el repositorio del recurso recibe además cada semana un restic check del 5 % de sus datos.
• Máquinas virtuales y contenedores de Proxmox VE (vista previa): en minutos tras cada punto de restauración nuevo (desde la 0.4.2, activado por defecto y desactivable para la instalación), y el punto de restauración más reciente de cada invitado al menos cada semana. «Comprobar ahora» en Preparación de recuperación inicia una comprobación a mano.
• Pruebas de arranque de Proxmox VE (vista previa): desactivadas por defecto; cuando un trabajo las activa, cada semana sobre el punto de restauración más reciente o después de cada copia, o a mano con «Boot test now» (en la interfaz en inglés).
• El propio almacenamiento: una muestra cada semana y cada archivo almacenado cada mes (vea «La comprobación del almacenamiento» más abajo), y para servidores y equipos una comprobación semanal de una vigésima parte de los datos de cada equipo, de modo que en unos cinco meses se ha leído todo.

Qué se comprueba en buzones y OneDrive

De la copia más reciente de cada buzón, OneDrive o cuenta IMAP, Restow toma al azar 20 correos, 20 archivos y algunas citas del calendario y contactos. Cada uno se relee y se comprueba pieza a pieza: cada pieza almacenada tiene que descifrarse y ser la pieza que la copia indica, y el elemento completo tiene que tener el tamaño y la huella que la copia registró. Si la comprobación del almacenamiento encontró datos dañados que usa esta copia, la copia cuenta como no restaurable aunque la muestra no los haya tocado.

Qué se comprueba en servidores y equipos

Después de cada copia correcta, el agente del equipo elige hasta 20 archivos al azar que no cambiaron mientras se hacía la copia y registra sus huellas. Después, el servidor de Restow relee exactamente esos archivos de la copia y compara las huellas. El agente además restaura una vez los mismos archivos en una carpeta temporal del equipo, los compara allí y borra la copia, de modo que la restauración también queda demostrada en el propio equipo. El agente informa archivo por archivo de lo que encontró, y el servidor de Restow valora ese informe con la misma regla que su propia comprobación (más abajo).

Qué se comprueba en sitios de SharePoint, recursos compartidos y Proxmox VE

Un sitio de SharePoint se comprueba como un OneDrive: Restow toma como muestra archivos de sus bibliotecas de documentos y los relee. En un recurso compartido de archivos se comprueba cada punto de restauración nuevo: se releen hasta 20 archivos de muestra y se comparan con lo que registró la copia, y el repositorio del recurso recibe cada semana un restic check del 5 % de sus datos; la preparación de recuperación valora un recurso por su punto de restauración más reciente. En Proxmox VE (una vista previa), un trabajo también puede ejecutar pruebas de arranque, desactivadas por defecto: el nodo del invitado restaura el punto de restauración más reciente como un invitado nuevo sin conexión a la red, lo arranca, espera al agente invitado y lo borra de nuevo. Verde significa que el agente invitado respondió, amarillo que el invitado solo arrancó, rojo que falló la restauración, el arranque o el inicio; lo que se ejecuta dentro del invitado no se comprueba. Además, cada punto de restauración nuevo de un invitado se relee en minutos tras su copia (una muestra de sus bloques de datos comparada con el SHA-256 registrado, en un contenedor una comprobación restic de un subconjunto), y la comprobación de restauración mensual opcional de un invitado de Proxmox VE y la comprobación semanal siguen existiendo.

Qué significan verde, rojo y «No verificado»

• Listo (verde): solo después de que una comprobación de restauración de la copia más reciente se haya superado. Nunca se muestra verde para una copia que simplemente ha terminado.
• Atención (amarillo): la copia se puede restaurar, pero algo merece una mirada: la copia más reciente tiene dos días o más, no había nada que comprobar en ella, la copia de un equipo solo se completó en parte, o la última comprobación del almacenamiento no pudo leer un pack que esta copia usa (un error de conexión o de permisos, que no es un daño demostrado).
• No restaurable (rojo): hay pruebas de que hoy una restauración no sería completa: un elemento volvió distinto o faltaba, hay datos almacenados dañados sin una copia intacta, un pack no se pudo leer en tres comprobaciones del almacenamiento seguidas a lo largo de al menos 24 horas, o la copia más reciente tiene una semana o más, de modo que se perderían datos recientes. En las alertas, este último caso aparece como «Backup too old», no como una comprobación fallida. La misma regla vale para cada buzón, OneDrive, cuenta IMAP, servidor y equipo: una comprobación solo valora en rojo con una prueba, es decir, con datos que faltan, que difieren de lo que registró la copia o que no se pueden descifrar o decodificar. En servidores y equipos eso significa una huella distinta, o restic informando de que el archivo o los datos que necesita faltan o están dañados.
• No verificado: existe una copia, pero todavía no se ha completado ninguna comprobación de exactamente esa copia. Una copia nueva después de una comprobación en verde vuelve a empezar como «No verificado». Una comprobación que no pudo completarse (el almacenamiento no respondió, no a tiempo o solo con limitación de peticiones, la copia estaba ocupada, el programa de comprobación no pudo arrancar) no valora nada y no envía ninguna alerta: en la lista de ejecuciones aparece como «Not completed, will be retried», ni en rojo ni en verde, y se repite.

Desde la 0.4.7 dos casos se valoran de otra manera. Un objeto eliminado de su fuente (un buzón borrado en Microsoft 365, por ejemplo) se valora solo según si se restaura su copia conservada más reciente, no según su antigüedad, porque nada lo copia ya y la retención conserva esa copia. Y un objeto que Restow ya no copia (cuenta desactivada, sin licencia, bloqueado por Microsoft o eliminado) espera primero en ámbar la confirmación de un administrador: no es un fallo, pero la preparación del inquilino queda al menos en amarillo, nunca en verde, hasta que se confirma con «Sí, es intencionado».

La comprobación del almacenamiento

Las copias se guardan en archivos más grandes llamados packs. Al escribir un pack, Restow registra su tamaño y su huella. La comprobación del almacenamiento vuelve a leer los packs, en cada repositorio que guarda una copia, y los compara: una muestra aleatoria cada semana y todos los packs cada mes. Una copia dañada se repara automáticamente a partir de una copia intacta en otra ubicación. Un pack dañado en todas partes marca al instante como no restaurable cada copia que lo usa, genera una alerta, y las copias posteriores vuelven a escribir esos datos desde el origen, en la medida en que el origen todavía los tenga.

Desde la 0.4.2 la comprobación distingue el daño de una lectura que falló. 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, el almacenamiento pidiendo ir más despacio o acceso denegado) no demuestra nada sobre los datos. La comprobación lo lee de nuevo, hasta tres veces, y un pack que sigue ilegible aparece en Preparación de recuperación, Integridad del almacenamiento, como «temporalmente ilegible», con el error, en cuántas comprobaciones seguidas no se pudo leer y cuándo. Las copias que lo usan muestran «Atención», no «No restaurable». Cada comprobación posterior lee primero los packs marcados, «Volver a comprobar estos packs» lee de nuevo solo esos, y cuando se leen intactos otra vez el hallazgo termina. Solo un pack demostradamente dañado (falta, tamaño o suma de comprobación incorrectos) o que no se pudo leer en tres comprobaciones seguidas a lo largo de al menos 24 horas hace que las copias que lo usan no sean restaurables.

Qué ve usted

• Capacidad de restauración: una tabla con cada buzón, OneDrive, cuenta IMAP, servidor y equipo, su estado, cuándo se comprobó por última vez y por qué, con un informe por comprobación que enumera lo que se releyó.
• Alertas: reglas que envían un correo, una entrada en la campana o un webhook firmado cuando una comprobación falla, necesita atención o se recupera, y cuando hay datos almacenados dañados.
• Overview e informes: la proporción de copias con restauración demostrada y el historial de comprobaciones en la página Overview (pestaña Statistics) y, con Business y Service Provider, informes resumidos programados.
• Para proveedores de servicios de TI: con Service Provider, la vista de proveedor de la página Overview para todos los inquilinos, y la API de integración informa de los mismos estados a su RMM o PSA, para que una comprobación fallida pueda abrir un ticket.

Límites, con honestidad

• Una muestra es una muestra. 20 correos de 50.000 demuestran que el camino de restauración y esos correos funcionan, no cada correo. La comprobación mensual del almacenamiento, que lee cada pack almacenado, cierra buena parte de esa brecha, y se puede solicitar una comprobación completa que lee cada elemento de una copia.
• La comprobación demuestra que su copia se puede releer intacta. No restaura en un buzón de Microsoft 365, OneDrive o cuenta IMAP en uso. Una restauración de prueba en un destino aparte no forma parte de la 0.1.0, así que restaure usted mismo un buzón de prueba de vez en cuando.
• La copia y la restauración de Microsoft 365 todavía no se han ejecutado contra un inquilino real de Microsoft 365 en las comprobaciones de la versión; están cubiertas por pruebas contra una API de Graph simulada.
• En servidores y equipos, la muestra solo abarca archivos que no cambiaron durante la copia. Que el volcado de una base de datos sea coherente depende de cómo se genere antes de la copia.
• Una comprobación encuentra daños; no impide que se borren datos. En S3 con Object Lock, las copias inmutables (desactivadas hasta que un administrador las activa por repositorio) hacen que el propio almacenamiento se niegue a borrar los datos bloqueados; un directorio o un recurso compartido NFS solo recibe un retraso de borrado, que no es inmutabilidad. Aparte de eso, proteja el propio almacenamiento, por ejemplo con copias en una segunda ubicación.
• Las comprobaciones de los recursos compartidos de archivos se ejecutaron en las comprobaciones de la versión contra Samba, no contra Windows Server, Synology, TrueNAS ni exportaciones NFS reales; las pruebas de arranque, la comprobación tras cada copia y la restauración de archivos de invitados de Proxmox VE se ejecutaron contra el nodo simulado de las suites de pruebas, no en un clúster de Proxmox VE.

Los detalles técnicos, con cada suma de comprobación, cada tamaño de muestra y cada regla tal como los aplica el código, están en la documentación (en inglés): how restorability is verified, in detail. Vea también la página de verificación.

Preguntas frecuentes