Resumen

  • El Informe Anual 2025 de AFRINIC describe una transición hacia una huella física menor y más uso de modelos cloud e híbridos, junto con Bacula moderno, cobertura de servicios críticos, copias externas en AWS S3, pruebas trimestrales y automatización con Ansible.
  • La estrategia tiene ventajas claras. Sin embargo, terminar un respaldo, leer un objeto, restaurar una instantánea, arrancar la aplicación y completar una operación de miembro son resultados distintos; ninguno demuestra automáticamente el siguiente.
  • Un mapa público de control podría registrar objetivos, escenarios, controles de integridad y aceptación, etapas a cargo de terceros, excepciones y el último ensayo fuera del entorno ordinario sin publicar nombres de cuentas, depósitos, claves ni instrucciones de emergencia.

La copia está lejos; la dependencia puede seguir cerca

AFRINIC presenta su cambio de infraestructura como una modernización, no como una retirada. Durante 2025 retiró equipos obsoletos y al final de su vida útil, sustituyó componentes de red y almacenamiento averiados, desplegó infraestructura de peering de 10 Gbit/s, amplió el almacenamiento para respaldos y preparó diseños redundantes de encaminamiento y enlaces. El trabajo mencionado abarca Mauricio, Johannesburgo, Parklands, Mombasa e Isando. Parte de las iniciativas quedó condicionada por calendarios y aprobaciones de proveedores.

En ese contexto, tener menos equipamiento propio puede ser una decisión prudente. Cada activo antiguo eliminado es una avería conocida menos. El almacenamiento externo separa una copia de un daño local. Un modelo híbrido puede poner recursos de recuperación a disposición antes de que exista otro recinto físico. Bacula y Ansible permiten repetir tareas que de otro modo dependen de memoria individual. Y probar la restauración cada trimestre vale mucho más que limitarse a contar ejecuciones de respaldo terminadas.

Esta es la versión fuerte del argumento y conviene conservarla. La propiedad de un servidor no garantiza continuidad; el uso de un proveedor tampoco la impide. La diferencia está en la trayectoria de la prueba. Cuando disminuye el espacio físico, la recuperación puede depender más de identidades, permisos, regiones, claves, semántica de restauración, contratos y tiempos de autorización. La copia viaja fuera del centro de datos. La capacidad de usarla debe viajar también.

El informe permite ver las piezas, pero no publica el mapa que las une. No sabemos por la documentación revisada qué clases de datos autoritativos contiene cada respaldo, si todos los servicios siguen el mismo recorrido, cuáles son sus RPO y RTO, qué instantánea se eligió, quién custodia las claves, dónde se realizó el ensayo, qué versión arrancó, qué validaciones pasó o si hubo una reconstrucción en un entorno controlado de forma independiente. Son datos no publicados, no fallos demostrados.

Recuperar es una escalera de nueve peldaños

El primer peldaño es que el trabajo de respaldo termine. El segundo es que el objeto almacenado pueda leerse. El tercero, que una instantánea elegida se restaure en un destino. Después deben validarse esquema, firmas e integridad referencial. Sólo entonces tiene sentido observar si la aplicación arranca, si el punto público responde y si un miembro o una parte dependiente completa la acción relevante. Queda por medir si se cumplieron el punto y el tiempo de recuperación. Y existe un último ensayo: reconstruir el estado autoritativo en un entorno que no dependa del control habitual.

Subir un peldaño no transporta automáticamente al siguiente. Una base restaurada puede pertenecer a una versión que la aplicación ya no entiende. Un servicio puede responder con datos incompletos. Una acción autenticada puede fallar por una identidad ausente aunque las tablas estén intactas. La recuperación puede terminar técnicamente después del RTO comprometido. Un ensayo dentro de la misma cuenta puede ser impecable y, aun así, no decir nada sobre una pérdida de acceso a esa cuenta.

En un registro regional, el criterio funcional es imprescindible. WHOIS, MyAFRINIC, DNS o RPKI no son sólo procesos que contestan a una sonda. Sus datos sostienen acciones de miembros y decisiones de terceros. El punto final debe describir la función recuperada, no el color del monitor.

La publicación de este criterio no exige exponer secretos. AFRINIC puede identificar una clase de destino, un tipo de custodia y un límite cruzado sin revelar topología, credenciales, claves, nombres de depósitos o comandos. La transparencia útil habla de resultados y responsabilidades.

El compromiso de servicio deja un hueco medible

El Compromiso de Nivel de Servicio de AFRINIC aparece como Versión 1 de noviembre de 2015. Abarca registro y atención al cliente, bases de datos y servicios públicos en línea, DNS inverso, facturación e infraestructura. Enumera WHOIS, MyAFRINIC, sitios, IRR, DNS, DNSSEC, correo y RPKI, y promete 99,8 % de disponibilidad por servicio y para la red.

El texto excluye del cálculo la indisponibilidad de terceros. También dice que AFRINIC no puede ofrecer compromisos sobre proveedores externos, aunque procurará reflejar sus propios compromisos en las relaciones comerciales que afecten servicios centrales. No hay evidencia de que un proveedor haya incumplido. Lo que existe es una frontera declarada: el resultado que vive el miembro puede incluir un tiempo que la métrica institucional excluye.

El Informe Anual afirma que los servicios críticos estuvieron normalmente por encima del 99,7 % de disponibilidad en 2025. En la captura, la página de estado mostraba como operativos WHOIS Database, MyAFRINIC Portal, AFRINIC Web Sites, Mailing Lists, New Member Registration Portal, DNS Services, RPKI Systems y Other Systems, sin resumen métrico en los componentes raíz. Una cifra anual, un estado presente y un ensayo de recuperación no compiten. Miden disponibilidad histórica, salud inmediata y capacidad de volver, respectivamente.

Cuando una iniciativa espera al proveedor, la cuestión útil es si ese tiempo aparece en la prueba. El reloj debería comenzar con la indisponibilidad y terminar con la aceptación funcional. Dentro de ese intervalo se pueden asignar etapas, pero no borrar minutos por haber cruzado un contrato.

Lo que S3 puede hacer no prueba cómo se usa

La documentación de AWS ofrece una lista valiosa de condiciones. Según el modelo de responsabilidad compartida, AWS opera la infraestructura de servicios administrados como S3, mientras el cliente conserva la responsabilidad sobre la resiliencia de sus datos, incluidas las decisiones de respaldo, versionado y replicación.

S3 puede participar en copias continuas o periódicas, restauración a un punto en el tiempo y acceso directo a los datos. El camino de AWS Backup requiere S3 Versioning. Los permisos y roles, las ACL, el versionado del destino, la región y la disponibilidad de claves de cifrado pueden alterar la restauración. Algunos objetos pueden omitirse cuando ya existe el mismo nombre o identificador de versión. Restaurar al depósito original no destruye de forma uniforme lo existente.

Nada de esto demuestra que AFRINIC utilice AWS Backup, Versioning, Replication, copias entre regiones, una región concreta o cierto diseño de IAM y cifrado. La comparación sirve para otra cosa: obliga a tipificar la prueba. “S3 restaurado” puede significar bytes recuperados, estado de aplicación reconstruido, transacción aceptada o salida independiente. Cada frase necesita su propio criterio.

La tabla que debería acompañar al porcentaje

Un mapa público de servicio a recuperación puede ser pequeño. Para cada componente indicaría la clase de datos autoritativos, RPO y RTO, un identificador no sensible del ejercicio, la hora de referencia, una huella de integridad y la clase de retención. Separaría las fases controladas por AFRINIC de las controladas por un proveedor.

El escenario precisaría la clase de destino y si cruzó una frontera de cuenta, región o proveedor. Los permisos y las claves aparecerían como categorías de custodia, no como secretos. El resultado distinguiría completitud, esquema, firmas, referencias, arranque, respuesta y aceptación del usuario. Tres marcas horarias —inicio, servicio utilizable y aceptación— impedirían que una sola duración ocultara el último tramo.

También deberían permanecer las excepciones: objetos omitidos, aprobaciones pendientes, responsable, fecha de corrección y vía de reversión. El último ejercicio en un entorno independiente mostraría si la salida se practicó. Una salida contractual no ensayada es una intención, no una capacidad.

Esa tabla no reemplaza una auditoría. Da a los miembros un vocabulario estable y permite comparar trimestres. Un resultado imperfecto, explicado y corregido, transmite más control que una sucesión de “prueba exitosa” cuya definición nadie puede observar.

Lo que no se puede concluir

Las fuentes no describen una caída, una restauración fallida, un respaldo ausente, una intrusión ni pérdida de datos en AFRINIC. No prueban que S3 aloje todos los servicios críticos o toda la información registral. Tampoco muestran dependencia irreversible, imposibilidad de salir de AWS, incumplimiento de un proveedor ni falsedad del 99,7 %. La página de estado no es un archivo histórico, pero sus etiquetas presentes no son por eso incorrectas.

La propuesta es preventiva. AFRINIC ya ha descrito un programa razonable: menos equipamiento obsoleto, copias externas, herramientas modernas, automatización y pruebas trimestrales. Hacer visible el recorrido de la prueba convertiría esa modernización técnica en una mejora de gobernanza.

Fuentes