Probar que las copias de seguridad realmente se restauran
Por Lucas Flores, IT Systeme Flores UG. Última actualización:
Una copia de seguridad que nunca se ha vuelto a leer a través de la ruta de restauración es una teoría, no una prueba. Por eso Restow trata «respaldado» y «restauración probada» como dos estados distintos, mostrados por separado, y una copia de seguridad sin una relectura verificada se muestra como no hecha, no como un matiz más discreto del éxito.
Copiar
Correo, calendario, contactos y OneDrive, incremental y cifrado, en su almacenamiento.
Tomar una muestra
Cada semana, por buzón y OneDrive: unos 20 correos, 20 archivos, calendario y contactos.
Releer
Desde la última copia, por el mismo camino que una restauración real.
Comparar
Byte a byte con las sumas de comprobación guardadas. Solo cuenta si coincide.
Mostrado por buzón como preparación para restaurar
- ListoÚltima prueba superada
- AtenciónAvisos en la prueba
- No restaurableLa prueba falló
- No verificadoAún no releído
Qué relee una comprobación de restauración, con qué frecuencia se ejecuta y qué significan verde, rojo y «No verificado», en lenguaje sencillo para clientes y proveedores de servicios de TI: cómo demuestra Restow que sus copias se pueden restaurar.
Qué se comprueba hoy
Una comprobación semanal por muestreo de la preparación de recuperación se ejecuta por buzón, OneDrive y sitio de SharePoint: Restow relee una muestra a través de la ruta de restauración y la compara con los hashes registrados, y después muestra el resultado con claridad como una comprobación basada en muestra, no como una cobertura completa que no se ha ganado. La comprobación no restaura nada en un buzón de Microsoft 365, OneDrive o cuenta IMAP; la restauración de prueba opcional en un destino aparte todavía no está conectada (véase más abajo). Cuando una comprobación falla, ese fallo aparece en el estado propio del buzón u OneDrive: no se promedia hasta desaparecer en un panel general en verde.
Un objeto eliminado de su fuente se valora de otra manera. Desde la 0.4.7, por
ejemplo, un buzón borrado en Microsoft 365 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. Se valora según si esa copia se restaura, sin motivos
de antigüedad como «La última copia tiene N días», y nunca está atrasado; una copia
conservada que no se restaura sigue en rojo. La tabla dice «Eliminado de la fuente,
copias conservadas» (Removed from source, backups kept), y la página del informe
empieza con «Eliminado de la fuente» (Removed from the source) y anota la antigüedad
como «No se cuenta: ...» (Not counted: ...). 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. Un objeto cuya copia
más reciente nunca se comprobó recibe una comprobación más del planificador semanal.
Los objetos de Microsoft 365 que Restow deja de copiar (la cuenta está desactivada,
no tiene licencia, Microsoft la bloqueó o se eliminó de la fuente) figuran primero
en ámbar como «Ya no se copia, confirme» (Not backed up any more, please confirm),
con el motivo. No es un fallo, ni rojo, ni atrasado, pero la preparación del
inquilino queda al menos en amarillo, nunca en verde, y la API de integración los
cuenta en readiness.toConfirm, hasta que un administrador confirma «Sí,
es intencionado» (Yes, intended); entonces el objeto figura en gris como «Ya no se
copia a propósito» (Intentionally no longer backed up). Los buzones desactivados o
sin licencia y los OneDrive y sitios bloqueados figuran como «No se copia: cuenta
desactivada», «No se copia: sin licencia» o «No se copia: bloqueado» y son neutros:
no suman ningún fallo.
Los servidores y equipos también están cubiertos
En un servidor o equipo respaldado con el agente (véase copia de servidores y equipos), la comprobación se ejecuta tras cada copia nueva correcta. El agente registra el SHA-256 de hasta 20 archivos al azar, el servidor de Restow los lee del repositorio y compara los hashes, y el resultado es verde solo si coinciden. Además, el repositorio se comprueba una vez por semana. Ambos resultados alimentan la preparación de recuperación, de modo que un equipo solo cuenta como recuperable cuando se han vuelto a leer archivos reales con hashes coincidentes. Los invitados de Proxmox VE (una vista previa) también cuentan en la preparación de recuperación. Una comprobación fallida dice qué ocurrió, por qué y qué hacer: véanse, en inglés, las explicaciones de fallos en la documentación.
Los recursos compartidos también están cubiertos
En un recurso compartido (véase
recursos compartidos), cada
punto de restauración nuevo se comprueba: Restow relee hasta 20 archivos de
muestra y los compara con lo copiado, y el repositorio recibe cada semana un
restic check del 5 por ciento de sus datos. La preparación de
recuperación valora un recurso por su punto de restauración más reciente. Un
punto de restauración sin muestras, porque todos los archivos cambiaron en la
hora previa a la ejecución, se valora en amarillo y dice por qué. Los
trabajos de copiado solo usan un punto de restauración que superó su
comprobación.
Proxmox VE: una comprobación tras cada copia y pruebas de arranque
Desde la 0.4.2, cada punto de restauración nuevo de una VM o un contenedor de Proxmox VE (una vista previa) se relee en minutos tras su copia: el servidor compara una muestra de sus bloques con el SHA-256 registrado (en un contenedor, una comprobación restic de un subconjunto), además de la comprobación semanal de cada invitado. Viene activado por defecto (Instalación › Proxmox VE) y se puede desactivar para la instalación. «Comprobar ahora» y «Comprobar todos los no verificados» en Preparación de recuperación inician comprobaciones a mano, y una comprobación en rojo muestra el error que encontró. Relee datos del almacenamiento; no arranca el invitado.
Una comprobación que no pudo ejecutarse no es una comprobación fallida. Desde la 0.4.3, cuando otra ejecución tiene el bloqueo del repositorio restic de un contenedor, la comprobación se pospone y se reintenta diez minutos después, y el resultado anterior se mantiene mientras tanto. Tras dos horas, el punto de restauración aparece como «No se pudo comprobar: repositorio bloqueado»: amarillo (atención) en Preparación de recuperación, nunca rojo ni verde, con el informe de restic sobre quién tiene el bloqueo. Los bloqueos obsoletos se eliminan antes de la comprobación (detalles). Un repositorio bloqueado ya no produce, por tanto, una «Comprobación de restauración fallida» en rojo que los datos nunca se ganaron, y tampoco una en verde: un punto de restauración que ninguna comprobación pudo leer sigue sin demostrarse. Las comprobaciones que fallaron en rojo por un bloqueo antes de la 0.4.3 siguen en rojo hasta la siguiente comprobación («Comprobar ahora»).
Proxmox VE (una vista previa) tiene
más que la comprobación por muestreo. Un trabajo puede arrancar el
punto de restauración más reciente de cada invitado, cada semana o tras cada
copia, y «Probar el arranque ahora» en un punto de restauración pide una a
mano. Está desactivado por defecto y tiene un límite de memoria y una espera
al agente invitado. El nodo del invitado restaura el punto de restauración
como invitado nuevo en el pool restow-restore, lo aísla antes de
arrancarlo (cada interfaz de red desconectada o en un puente aislado,
dispositivos passthrough, puertos serie y bind mounts eliminados), lo
arranca, espera al agente invitado de QEMU (en un contenedor: su init) y lo
destruye en cualquier caso. Se ejecuta una prueba por nodo a la vez, nunca
junto a una copia. Verde significa que el agente invitado respondió, amarillo
que la VM solo arrancó y nada respondió, rojo que falló la restauración, el
arranque o el inicio. La preparación de recuperación valora el punto de
restauración más reciente por su prueba de arranque donde la hay. No
comprueba puertos ni aplicaciones dentro del invitado. Necesita restow-pve
0.4.0 en el nodo y se probó con un nodo simulado, no con un clúster real de
Proxmox VE.
La comprobación del almacenamiento: dañado no es lo mismo que ilegible
Junto a las comprobaciones de restauración, una comprobación del almacenamiento relee packs y los compara con su tamaño y suma de comprobación registrados (una muestra cada semana, todos los packs cada mes). Desde la 0.4.2 distingue 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) de uno dañado. Lee ese pack de nuevo, hasta tres veces; uno 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. Los objetos que lo usan reciben «Atención», no «No restaurable»: eso exige un pack demostradamente dañado (falta, tamaño o suma de comprobación incorrectos) o uno que no se pudo leer en 3 comprobaciones seguidas a lo largo de al menos 24 horas. Cuando los packs se leen de nuevo intactos, el hallazgo termina y las comprobaciones de restauración propias de los objetos vuelven a calificarlos.
La detección de ransomware juzga, no demuestra
Cada punto de restauración nuevo se juzga además en busca de señales de ransomware, a partir de datos que la copia ya tiene. Es otra pregunta que «¿se puede restaurar esto?»: un punto de restauración sin hallazgos no demuestra nada, y un hallazgo es un motivo para mirar. Véase detección de ransomware.
El archivo tiene su propia comprobación
La cadena de hashes SHA-256 del archivo se verifica por separado de las copias de seguridad. La verificación de la cadena comprueba cada eslabón, los anclajes diarios (escritos cada noche) y, si usted quiere, una muestra del contenido de los mensajes. Forma parte del archivo, en todas las ediciones, véase el archivo.
Qué está previsto
Una restauración de prueba completa en un destino aparte para todos los tipos de copia está prevista, y también la verificación de cada elemento respaldado en lugar de una muestra; la prueba de arranque de Proxmox VE solo cubre invitados. Hasta entonces, la comprobación por muestreo es el estado intermedio indicado con honestidad. Véase la hoja de ruta para el estado exacto, y, en inglés, cómo se construye Restow para la ejecución automatizada de pruebas de publicación que cada versión tiene que superar antes de publicarse, incluida una copia de seguridad y restauración IMAP con comparación byte a byte y una restauración con el servidor detenido.
Qué cubren las comprobaciones de la versión
Una ejecución de pruebas de publicación condiciona cada versión: una instalación nueva, restauraciones con comparación de hashes, copia de equipos, copia de un recurso compartido contra Samba, captura del archivo desde una cuenta IMAP e importación de correo, entre 13 comprobaciones. En cada versión desde la 0.4.4, 12 de 13 comprobaciones se superaron por completo para las imágenes completas y 1 se omitió; para las imágenes Community, 9 de 13 se superaron por completo y 4 se omitieron, entre ellas, por diseño, las que necesitan un módulo de Business o un segundo inquilino: la recepción de journaling, los destinos de almacenamiento y, desde la 0.4.4, la captura del archivo. De la 0.4.0 a la 0.4.3 la ejecución tenía 12 comprobaciones (la de recursos compartidos llegó con la 0.4.0): 11 de 12 se superaron por completo para las imágenes completas y 1 se omitió, y para las imágenes Community 9 de 12 se superaron por completo y 3 se omitieron. De la 0.2.1 a la 0.3.6 tenía 11 comprobaciones: 10 de 11 se superaron por completo para las imágenes completas y 1 se omitió, y para las imágenes Community 8 de 11 se superaron por completo y 3 se omitieron. El informe, con el motivo de cada comprobación omitida, se adjunta a cada versión.
La comprobación omitida es la número 4, la comprobación automática de copia y restauración de Microsoft 365 contra un inquilino real, ejecutada contra un inquilino de desarrollo. Todavía no está activa y se omitió en todas las versiones hasta ahora. Microsoft 365 está cubierto por pruebas contra una API de Graph simulada. Restow es una beta: utilícelo junto a sus copias de seguridad actuales hasta que haya verificado restauraciones con sus propios datos. En las comprobaciones de la versión, el script de instalación del agente solo se ejecuta dentro de un contenedor Linux; el agente de macOS se entrega, pero su instalador no forma parte de las comprobaciones de la versión (las pruebas propias del agente se ejecutaron de forma nativa en macOS).
Preguntas frecuentes
¿Cómo verifica Restow que una copia de seguridad realmente se puede restaurar?
Releyéndola a través de la ruta de restauración y comprobándola con los hashes registrados, no asumiendo que un trabajo de copia de seguridad correcto significa que los datos son recuperables. Hoy eso se ejecuta como una comprobación semanal por muestreo de la preparación de recuperación, por buzón, OneDrive y sitio de SharePoint, mostrada como una muestra y no como una prueba completa. La comprobación no restaura nada en un buzón, OneDrive o cuenta IMAP. Los servidores, los equipos y los recursos compartidos se comprueban tras cada copia nueva, los invitados de Proxmox VE en minutos tras cada copia nueva (una vista previa, desde la 0.4.2) y además con una prueba de arranque si la activa. Una restauración de prueba completa en un destino aparte para todos los tipos de copia y la verificación de cada elemento respaldado están previstas. Véase la hoja de ruta.
¿Qué ocurre si falla una comprobación de verificación?
Se muestra, no se oculta. El estado de preparación de recuperación del buzón u OneDrive afectado refleja el fallo de inmediato, la misma norma de honestidad que se aplica a las esperas por limitación de Graph y a cualquier otro límite conocido del producto. Una comprobación fallida dice además qué ocurrió, por qué y qué hacer, con los detalles técnicos reservados para un caso de soporte. El rojo necesita una prueba (datos que faltan, que difieren o que no se pueden decodificar); una comprobación que no pudo completarse, por ejemplo porque el almacenamiento no respondió, no valora nada, no envía ninguna alerta y se repite.
¿Se muestra como correcta una copia de seguridad no verificada?
No. Una copia de seguridad que no se ha releído y verificado se trata, y se muestra, como no probada, nunca redondeada en silencio a «hecho».
¿Se verifican también los recursos compartidos?
Sí. Tras cada punto de restauración nuevo de un recurso compartido, Restow relee hasta 20 archivos de muestra y los compara con lo copiado, y el repositorio recibe cada semana un restic check del 5 por ciento de sus datos. La preparación de recuperación valora el recurso por su punto de restauración más reciente. Un punto de restauración sin muestras, porque todos los archivos cambiaron en la hora previa a la ejecución, se valora en amarillo y dice por qué.
¿Puede Restow comprobar que una copia de Proxmox VE arranca?
Opcionalmente, como vista previa. 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). El nodo del invitado lo restaura como invitado nuevo en el pool restow-restore, corta su red antes del arranque, espera al agente invitado de QEMU y destruye el invitado de prueba en cualquier caso. Verde significa que el agente invitado respondió, amarillo que la VM solo arrancó, rojo que falló la restauración, el arranque o el inicio. No comprueba puertos ni aplicaciones dentro del invitado.
¿Se comprueba una copia de Proxmox VE justo después de hacerla?
Desde la 0.4.2, sí, por defecto (Instalación › Proxmox VE, propietario): cada punto de restauración nuevo de una VM o un contenedor se relee en minutos tras su copia, una muestra de sus bloques comparada con el SHA-256 registrado, en un contenedor una comprobación restic de un subconjunto, además de la comprobación semanal de cada invitado. Es una vista previa, probada con un nodo simulado de Proxmox VE. «Comprobar ahora» y «Comprobar todos los no verificados» en Preparación de recuperación inician comprobaciones a mano, y una comprobación en rojo muestra el error que encontró.
¿Qué significa «No se pudo comprobar: repositorio bloqueado» en una copia de Proxmox VE?
Que la comprobación de restauración no pudo ejecutarse, no que la copia esté dañada. Desde la 0.4.3, cuando otra ejecución tiene el bloqueo del repositorio restic de un contenedor, la comprobación se pospone y se reintenta diez minutos después, y el resultado anterior se mantiene. Si el bloqueo sigue dos horas, el punto de restauración aparece como «No se pudo comprobar: repositorio bloqueado» (en la interfaz en inglés, «Could not check: repository locked») en amarillo (atención) en Preparación de recuperación, con el informe de restic sobre quién tiene el bloqueo. Nunca es rojo, porque no se encontró nada, ni verde, porque no se leyó nada. Los bloqueos obsoletos de restic se eliminan antes de la comprobación, y «Comprobar ahora» lo intenta de nuevo al instante. Las comprobaciones que un bloqueo hizo fallar en rojo antes de la actualización siguen en rojo hasta la siguiente comprobación.
¿Qué hace Restow cuando la comprobación del almacenamiento no puede leer un pack?
Desde la 0.4.2 no lo llama daño. Un pack que la comprobación del almacenamiento no pudo leer en ese momento (una descarga cortada, una conexión restablecida, un tiempo de espera agotado, S3 pidiendo ir más despacio, acceso denegado) se lee de nuevo, hasta tres veces; si sigue ilegible, aparece como temporalmente ilegible, con el error y en cuántas comprobaciones seguidas no se pudo leer, y 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. Cada comprobación posterior lo lee primero, y «Volver a comprobar estos packs» lee de nuevo solo los marcados.
¿Se verifican también los servidores y portátiles?
Sí. Tras cada copia nueva correcta de un servidor o equipo, el agente registra el SHA-256 de hasta 20 archivos al azar. El servidor de Restow lee esos archivos del repositorio y compara los hashes, y la comprobación solo sale en verde si todos coinciden. Además, el repositorio se comprueba una vez por semana. Ambos resultados alimentan la preparación de recuperación.
Por qué importan más las pruebas de restauración que las copias →