Cómo demostrar que una copia de seguridad se puede restaurar
Por Lucas Flores, IT Systeme Flores UG. Última actualización:
Usted demuestra que una copia de seguridad se puede restaurar restaurando a partir de ella: con regularidad, según un calendario que respete y comparando el resultado con lo que se registró al hacer la copia. En la práctica son una prueba de restauración, la relectura de una muestra de los datos, una comparación de hashes con las sumas de comprobación registradas, un ritmo fijo como el semanal y resultados por escrito. Un trabajo de copia terminado solo dice que se escribieron datos. Restow ejecuta esta comprobación cada semana y muestra el resultado como «Preparación de recuperación» (en la interfaz en inglés, «Recovery readiness»).
¿Por qué un trabajo de copia terminado con éxito no demuestra nada?
Porque «terminado» significa que la escritura funcionó, no que los datos se puedan volver a leer. Una clave de cifrado puede dejar de coincidir con la que escribió un fragmento, el almacenamiento puede dañar un bloque que no se lee durante meses y un cambio de formato puede romper en silencio la compatibilidad con copias antiguas. Nada de eso aparece en el estado del propio trabajo. Aparece cuando alguien intenta una restauración, que es el peor momento para descubrirlo.
¿Qué cuenta como prueba?
Cinco partes, y la prueba vale tanto como la más débil:
| Parte | Qué hace usted | Qué demuestra |
|---|---|---|
| Prueba de restauración | Restaure datos reales en un destino aparte, nunca sobre la producción. | La vía de restauración funciona de extremo a extremo, incluidas las claves y los permisos. |
| Relectura de una muestra | Elija elementos al azar de la copia más reciente y relea esos elementos por la misma vía que usa una restauración real. | La copia se puede leer y se descifra, con datos que usted no eligió de antemano. |
| Comparación de hashes | Compare una suma de comprobación como SHA-256 de lo que ha vuelto con la que se registró al hacer la copia. | Lo que ha vuelto es, byte por byte, lo que entró, y no solo algo que se abre. |
| Un ritmo regular | Repítalo según un calendario fijo, por ejemplo cada semana, y tras cambios en la configuración. | Sigue funcionando hoy. Una sola prueba demuestra solo el día en que se hizo. |
| Resultados documentados | Anote la fecha, la copia, la muestra, el método y el resultado, y consérvelo. | Puede enseñárselo a un compañero, a un cliente o a un auditor, y ver una tendencia. |
¿Cómo hacerlo sin herramientas especiales?
Cualquier producto de copia de seguridad se puede comprobar a mano con una rutina corta. En un servidor Linux, por ejemplo: registre con sha256sum las sumas de comprobación de una muestra aleatoria de ficheros (con rutas relativas) antes de la copia, restaure esos ficheros en una carpeta vacía y ejecute allí sha256sum -c sobre la lista. Cada línea debe decir OK. Para el correo, restaure una muestra de mensajes en un buzón de prueba y compárelos con los originales, y de vez en cuando haga una restauración de un buzón completo en un buzón de prueba. Anote el resultado. Hágalo según un calendario, no cuando se acuerde.
¿Con qué frecuencia conviene comprobar?
La relectura de una muestra, al menos cada semana, porque con esa rapidez debería detectarse un problema silencioso, y un simulacro de restauración completa en un destino de prueba cada trimestre y tras cualquier cambio en el almacenamiento, las claves o la herramienta de copia. Es nuestra sugerencia, no una regla de una norma; su propio riesgo y los contratos de sus clientes pueden exigir más.
¿Cómo lo hace Restow?
Cuando Restow hace una copia, registra una suma de comprobación SHA-256 de cada elemento. Cada semana, para cada buzón, OneDrive y cuenta IMAP, una comprobación de restauración toma al azar de la copia más reciente 20 correos, 20 ficheros y algunas citas del calendario y contactos, los relee por la vía de restauración, incluido el descifrado, y compara lo que vuelve con las sumas de comprobación registradas. En servidores y equipos, el agente además restaura algunos ficheros en una carpeta temporal del equipo, los compara allí y borra la copia. El resultado se muestra como «Preparación de recuperación»: «Listo» (verde; en la interfaz en inglés, «Ready») solo después de superar una comprobación de la copia más reciente, y «No verificado» (en la interfaz en inglés, «Unverified») para una copia que existe pero aún no se ha comprobado; nunca verde por defecto. Un informe por comprobación enumera lo que se releyó, y las alertas pueden enviar un correo, un aviso en la campana o un webhook firmado cuando una comprobación falla.
Desde la 0.4.0 existen dos comprobaciones más. Un recurso compartido de archivos se comprueba tras cada punto de restauración nuevo: se releen y se comparan hasta 20 archivos de muestra, y el repositorio recibe cada semana un restic check del 5 % de sus datos. Los sitios de SharePoint se comprueban como los OneDrive, tomando archivos de las bibliotecas como muestra. En Proxmox VE (una vista previa), un trabajo también puede ejecutar pruebas de arranque, desactivadas por defecto: un punto de restauración se restaura como un invitado nuevo sin conexión a la red, se arranca, se comprueba que el agente invitado de QEMU responde y se borra de nuevo. Una prueba de arranque en verde significa que el invitado respondió, no que cada aplicación funcione; los invitados Windows sin agente invitado llegan como mucho a amarillo. Desde la 0.4.2, cada punto de restauración nuevo de un invitado de Proxmox VE también se relee en minutos tras su copia: una muestra de sus bloques se compara con la suma de comprobación registrada.
Además, una comprobación del almacenamiento vuelve a leer los packs y los compara con su tamaño y su suma de comprobación registrados: una muestra cada semana y todos los packs cada mes. Desde la 0.4.2 distingue un pack que no pudo leer en ese momento (un error de conexión o de permisos) de uno dañado: ese pack se lee de nuevo y se califica «Atención» en lugar de «No restaurable», salvo que siga ilegible en tres comprobaciones seguidas a lo largo de al menos 24 horas. Y el registro de auditoría anota cada lectura y cada restauración, de modo que el historial de quién restauró qué es en sí mismo una prueba. Los detalles están en cómo demuestra Restow que sus copias se pueden restaurar, en la página de funciones sobre verificación y en la documentación (en inglés).
¿Cuáles son los límites de una muestra?
Una muestra es una muestra: 20 correos de 50.000 demuestran que la vía de restauración y esos correos funcionan, no cada correo. La comprobación mensual del almacenamiento, que lee todos los packs almacenados, cierra buena parte de esa laguna. La comprobación semanal no restaura en un buzón activo de Microsoft 365; una restauración de prueba completa en un destino aparte está prevista y no está construida, así que restaure usted mismo un buzón de prueba de vez en cuando. Y la copia y la restauración de Microsoft 365 todavía no se han ejecutado contra un inquilino real en las comprobaciones de versión de Restow; están cubiertas por pruebas contra una API de Graph simulada. Por eso Restow, todavía una beta, debería funcionar junto a una copia de seguridad existente hasta que usted haya verificado restauraciones con sus propios datos.
Preguntas frecuentes
¿Es una prueba de restauración lo mismo que verificar los datos almacenados?
No, responden a preguntas distintas. Verificar los datos almacenados (leer los packs y comparar sumas de comprobación) demuestra que el almacenamiento sigue conteniendo lo que se escribió. Una prueba de restauración recorre el mismo camino que una restauración real, incluidos el descifrado y el reensamblado, y compara el resultado con el original. Conviene tener ambas: la primera detecta pronto los daños silenciosos y la segunda demuestra que toda la cadena funciona.
¿Cuántos elementos debo muestrear?
No hay un número mágico. Cubra todos los tipos de datos que protege (correo, calendario, ficheros, un volcado de base de datos), elija los elementos al azar para no probar siempre los mismos, los fáciles, y haga la muestra lo bastante grande como para que un fallo se note. Restow toma por buzón 20 correos, 20 ficheros y algunas citas del calendario y contactos, y por equipo hasta 20 ficheros; una rutina manual puede ser mucho más pequeña si la repite.
¿Tengo que restaurar en producción para probar?
No, y no debería. Restaure en un destino aparte: una carpeta vacía, un buzón de prueba, una máquina virtual desechable. Una restauración que sobrescribe datos en uso es un riesgo, no una prueba. La restauración de Restow es no destructiva por defecto, y su comprobación semanal lee la copia en el servidor sin escribir en un buzón ni sobre los ficheros de un equipo.
¿Qué debe contener el resultado por escrito?
La fecha, qué copia se probó (trabajo y punto de restauración), qué se muestreó y cuántos elementos, el método, el resultado por elemento o en conjunto, la persona o el sistema que la ejecutó y qué se hizo ante cualquier fallo. Basta una línea por ejecución si siempre es la misma línea y se guarda donde un auditor o un compañero pueda encontrarla.
¿Demuestra Restow todo sobre una copia de seguridad?
No. La comprobación semanal demuestra que una muestra aleatoria se relee intacta por la vía de restauración; no restaura en un buzón activo de Microsoft 365, y una restauración de prueba completa en un destino aparte está prevista, no construida. Restow también dice qué no han cubierto todavía sus comprobaciones de versión, por ejemplo la copia y la restauración de Microsoft 365 contra un inquilino real.
Por qué importan más las pruebas de restauración que las copias de seguridad · Retirada de EWS: qué necesitan ahora las herramientas de copia de seguridad
Más en Aprender: la regla 3-2-1 de copias de seguridad y el «0» de la 3-2-1-1-0 →