Resumen

  • El acuerdo público de nivel de servicio separa dos relojes: la avería de hardware puede dejar de computarse cuando el equipo de sustitución recibe corriente, aunque la recarga del sistema, la reconstrucción RAID y la restauración de copias todavía mantengan al cliente sin servicio.
  • La presencia anunciada en Sídney, las instalaciones de Equinix y las conexiones visibles de AS56106 y AS45152 respaldan una operación australiana, pero no revelan cuántos racks, kilovatios, equipos de reserva, rutas físicamente diversas ni recursos de recuperación puede usar Zone Networks durante un fallo.
  • Para valorar la continuidad real hay que contratar y ensayar el trayecto completo hasta la aplicación operativa: ubicación y aislamiento de las copias, velocidad de restauración, responsabilidades de soporte, dependencias externas y capacidad disponible cuando la avería afecta a varios clientes a la vez.

Dos relojes empiezan con la misma avería

La pregunta más útil sobre un servicio alojado no es cuánto tarda alguien en cambiar una pieza. Es cuánto tarda el cliente en volver a vender, facturar, atender consultas, publicar contenido o ejecutar el proceso del que depende su organización. Ambos plazos pueden empezar en el mismo instante, con el fallo de un servidor, pero no terminan necesariamente juntos. El acuerdo de nivel de servicio de Zone Networks permite que el tiempo atribuido a una avería de hardware deje de correr una vez encendido el equipo de sustitución. La recarga de programas, la reconstrucción de un conjunto RAID y la restauración desde una copia quedan fuera de ese cómputo específico. El metal puede haber regresado; el negocio, no.

Esa frontera contractual cambia la lectura de casi todas las promesas de disponibilidad. Un porcentaje resume una categoría de interrupción conforme a unas reglas, pero no cuenta por sí solo la experiencia completa del usuario. Si un nuevo chasis recibe corriente y red, el trabajo posterior puede incluir instalar o verificar el sistema operativo, reconocer los discos, reconstruir datos, recuperar una imagen, aplicar configuraciones, reponer certificados y confirmar que la aplicación responde de manera íntegra.

La duración relevante para el cliente sigue avanzando durante cada una de esas tareas, incluso cuando el reloj más estrecho del hardware ya se ha detenido.

La diferencia tampoco es una sutileza reservada a grandes empresas. Una tienda pequeña puede tener un solo servidor dedicado, una máquina virtual y unas pocas integraciones, pero precisamente por esa concentración dispone de menos caminos alternativos. Si la restauración exige una copia externa, una licencia asociada a una dirección IP, un cambio de DNS o la intervención de una persona concreta, la vuelta de la electricidad al servidor es apenas un hito intermedio. La recuperación empresarial termina cuando se han validado datos, transacciones y accesos, no cuando se ilumina un indicador.

Las condiciones de servicio añaden otra razón para mirar el contrato completo: facturación, avisos, cancelación, terminación y eliminación de datos forman parte del entorno operativo. Un incidente técnico puede coincidir con una cuenta bloqueada, un acceso perdido al portal o una discusión sobre la responsabilidad de una tarea. La continuidad depende entonces tanto de la capacidad física como de que el cliente pueda abrir un caso, autorizar cambios, recuperar sus credenciales y obtener los datos en un formato utilizable.

El análisis correcto comienza, por tanto, con dos objetivos distintos. El primero es el plazo de sustitución o reparación de la infraestructura que controla Zone Networks. El segundo es el tiempo de recuperación de la actividad que debe definir el cliente. Si solo se contrata el primero, todo el trabajo entre un servidor encendido y una aplicación sana queda sin un compromiso temporal suficiente. Ese intervalo es el centro económico y operativo de la relación.

Operación visible, capacidad de recuperación invisible

Zone Networks no aparece como una mera marca sin señales de actividad. El Australian Business Register identifica a Zone Networks Pty Ltd con ABN 83 136 050 578 y ACN 136 050 578 como una sociedad privada australiana activa. El ABN figura activo desde el 24 de marzo de 2009, y el nombre comercial ZONE NETWORKS aparece desde agosto de 2011, con ubicación principal en NSW 2015. Es una base jurídica sólida para saber con quién se relaciona un cliente, aunque no diga nada sobre servidores disponibles, piezas de repuesto o tiempos observados de recuperación.

También hay señales operativas en la página principal de Zone Networks, que anuncia alojamiento, VPS, servidores dedicados y colocación en Australia, y en la presentación de la empresa, donde se describen decisiones históricas de almacenamiento EMC y equipos Juniper. Esas páginas ayudan a entender la oferta y su desarrollo, pero varias referencias tecnológicas parecen antiguas. Una descripción histórica no equivale a un inventario fechado del equipo que está instalado, encendido y libre hoy.

El portal público de clientes muestra acceso a cuentas, categorías de producto, soporte, anuncios y estado de red. Su disponibilidad indica que existe una superficie comercial y de atención. No demuestra que cada configuración enumerada pueda comprarse en ese momento, que haya existencias para sustituirla o que todos los servicios mostrados compartan la misma arquitectura. Un escaparate accesible confirma un canal, no su capacidad bajo presión.

La lectura prudente es que existe evidencia de una operación australiana y una red activa con confianza media. No hay base pública para elevar esa conclusión a una plataforma de múltiples emplazamientos con capacidad masiva y recuperación ya probada. Tampoco debe confundirse esta sociedad australiana con ZONENETWORKS.COM Inc. Los materiales revisados no acreditan propiedad común, relación matriz-filial, reparto de activos, control compartido ni cooperación operativa entre ambas. Cualquier evaluación de recursos debe ceñirse a la entidad australiana y a los activos que puedan vincularse a ella.

Esta distinción entre existencia y capacidad importa porque una empresa puede estar legalmente activa, originar rutas y atender clientes sin mantener suficiente reserva para una avería correlacionada. La pregunta de continuidad no es si existe algún servidor ni si funciona un portal. Es cuánta capacidad queda disponible después de perder un host, un sistema de almacenamiento, una alimentación, un enlace o un rack, y cuánto trabajo hace falta para que el cliente la aproveche. Sobre esos valores, la información pública permanece limitada.

Un catálogo vende tamaños, no demuestra una reserva

Las páginas de producto describen lo que un cliente puede recibir en condiciones normales. No describen necesariamente lo que la empresa posee en total ni lo que puede movilizar durante una emergencia. La oferta general de alojamiento compartido habla de plataformas Linux y Windows, hardware Dell, almacenamiento EMC SAN, copias diarias y disponibilidad. Es una descripción del diseño comercial. No publica cuántos nodos integran la plataforma, cuánto almacenamiento bruto o utilizable existe, qué proporción está ocupada ni qué parte se mantiene vacía para fallos.

La presentación de los VPS en nube emplea la idea de una infraestructura virtual capaz de recuperarse y menciona vigilancia y copias diarias. Para convertir esa idea en una expectativa operativa harían falta otros datos: número de hosts, dominios de fallo, capacidad libre de CPU y memoria, relación entre almacenamiento y cómputo, estado del plano de control y comportamiento cuando el problema afecta al SAN compartido. Sin esa información, la capacidad de mover una máquina virtual es una propiedad anunciada, no un plazo demostrado.

En la página de VPS gestionados con cPanel aparecen planes de 4 a 8 vCPU, de 4 a 8 GB de memoria, de 50 a 100 GB de SAN y de 1 a 3 TB de transferencia. Esos números delimitan la asignación de un producto. No permiten sumar procesadores físicos, contar servidores ni calcular la sobreasignación. Tampoco revelan si existe otro nodo capaz de recibir todas las máquinas afectadas por una avería sin degradar a las que ya estaban funcionando.

Un plan gestionado de Windows VPS muestra 8 vCPU, 8 GB de memoria, 100 GB de SAN y 3 TB de transferencia, además de describir la migración a otro nodo. La página combina referencias antiguas de programas con expresiones de disponibilidad que no son uniformes. Lo que interesa para la recuperación no es solo que otro nodo exista en abstracto, sino que esté sano, conectado al almacenamiento adecuado, tenga reserva suficiente y pueda aceptar la carga en el momento de la avería.

La familia SSD VPS añade una copia nocturna y una retención anunciada de siete días. De nuevo, el dato describe una periodicidad y una ventana, no la tasa de trabajos completados, la integridad de cada copia, el aislamiento de credenciales, la ubicación de la segunda copia ni la velocidad de retorno. Retener siete puntos potenciales no garantiza que alguno pueda restaurarse dentro del tiempo que tolera el negocio.

El catálogo sirve para comparar formas de producto. No sirve para inferir flota total, ocupación, existencias vendidas, servidores de reserva ni capacidad utilizable durante un fallo. Confundir esas magnitudes produce una ilusión peligrosa: sumar los recursos que aparecen en una tarjeta comercial y tratarlos como si fueran equipos físicos disponibles para contingencias. La recuperación depende justamente de la parte no vendida, separada y operativa, una cifra que no aparece.

El servidor dedicado revela el límite con más claridad

En un servidor dedicado, la frontera entre pieza sustituida y servicio recuperado resulta especialmente visible. La descripción general de servidores dedicados sitúa la oferta en un centro de datos Equinix en Sídney y distingue opciones gestionadas y no gestionadas. La ubicación metropolitana es relevante. La modalidad de gestión lo es aún más, porque determina quién debe ejecutar las acciones que siguen a una avería y qué tareas están incluidas.

La gama dedicada premium presenta configuraciones de un socket con procesador, memoria, discos, RAID, puerto, transferencia y servicios opcionales. La gama dedicada empresarial hace lo mismo con opciones de dos sockets. Son fichas de configuración, no partes de almacén. No indican cuántas unidades compatibles están montadas, cuántos discos o controladores se guardan, qué modelos pueden sustituirse de forma equivalente ni cuánto tarda una intervención cuando varias máquinas requieren atención.

Una configuración grande también puede constituir un único dominio de fallo. Dos sockets y varios discos no crean por sí solos una segunda máquina. RAID puede tolerar determinados fallos de disco según su diseño, pero una controladora, una placa, una fuente mal conectada o una corrupción más amplia puede obligar a reconstruir. Si la sustitución no es idéntica, pueden aparecer diferencias de controladores, firmware o arranque. El reloj empresarial incluye el diagnóstico, la adaptación y la verificación de datos, aunque el equipo nuevo ya esté alimentado.

La página de una oferta especial de servidor dedicado menciona equipo minorista, supervisión en SY3, opciones de copia local y externa de 50 GB a 1 TB y lenguaje de existencias excedentes. Pero la oferta no está fechada, las configuraciones son antiguas y no se cuantifica ese excedente. No hay base para asumir que constituye hoy un depósito de repuestos, que coincide con el hardware de cada cliente o que está reservado para una recuperación.

La diferencia entre gestionado y no gestionado puede prolongar el segundo reloj. Si Zone Networks entrega un chasis funcional pero el sistema, la base de datos, el cortafuegos o la aplicación corresponden al cliente, la restauración depende de que este disponga de personal, documentación y accesos. La presentación de gestión de servidores describe capas de servicio autónomo, Bronze y Gold y alude a tareas de sistema, base de datos, cortafuegos, supervisión y copias. Sin embargo, las inclusiones exactas son difíciles de extraer de la página y pueden variar con el contrato.

Por eso el comprador necesita una matriz explícita de responsabilidades. Debe indicar quién sustituye la pieza, quién instala el sistema, quién reconstruye RAID, quién recupera la copia, quién configura red y seguridad, quién valida la base de datos y quién decide que la aplicación está de nuevo operativa. Si una fila queda sin dueño o sin plazo, esa fila se convierte en tiempo adicional de caída.

Sídney es un lugar demostrado, no una arquitectura completa

La evidencia física más clara conduce a Sídney. La oferta de colocación de Zone Networks menciona Equinix SY3 y SY4, unidades desde 1U hasta un rack completo, asignaciones eléctricas desde 0,5 A hasta 20 A, jaula privada y un contexto de centro de operaciones en SY3. Es suficiente para tratar esos nombres de instalación como parte de la oferta anunciada. No permite saber cuántos racks ocupa actualmente la empresa, qué contratos conserva, qué espacio está libre ni dónde se encuentra cada cliente.

Equinix publica para SY3, en 47 Bourke Road, Alexandria, una superficie total de 6.894 metros cuadrados, una densidad mínima de armario de 4 kVA y diseños N+1 de electricidad y refrigeración, además de respaldo mediante generadores. Para SY4, en 200 Bourke Road, Alexandria, publica 7.445 metros cuadrados, una densidad mínima de 4 kVA, electricidad N+1 y refrigeración N+20 por ciento, junto con respaldo de generadores. Son especificaciones del edificio entero.

Ninguna de esas cifras puede asignarse a Zone Networks. Los metros cuadrados son de la instalación, no de su superficie contratada. La densidad mínima de un armario no declara su consumo. N+1 en el edificio no demuestra que un rack concreto reciba dos alimentaciones independientes, que cada servidor use fuentes dobles conectadas a caminos distintos ni que una carga esté duplicada entre SY3 y SY4. La redundancia de la instalación solo beneficia a una aplicación hasta el punto en que todos los componentes posteriores la utilizan.

La vista metropolitana de Equinix en Sídney muestra un conjunto más amplio de instalaciones y un ecosistema de interconexión. Esa amplitud pertenece a Equinix. No es una extensión automática de la flota de Zone Networks. Estar presente en una ciudad con varios centros tampoco significa mantener copias sincronizadas, cómputo disponible y procedimientos de conmutación entre ellos.

La separación de responsabilidades vuelve a ser fundamental. Equinix gestiona el edificio, la entrada eléctrica, UPS, generadores, refrigeración y seguridad física. Zone Networks parece componer su servicio minorista dentro de espacio contratado, con servidores, equipos de red, transporte, programas y soporte propios o adquiridos. El cliente contrata con Zone Networks salvo que su pedido establezca otra cosa. Una buena especificación del inmueble no responde cuánto equipo ha reservado el ocupante para absorber un fallo.

Sídney debe describirse, entonces, como centro físico demostrado de la oferta de alojamiento, no como prueba de una plataforma repartida geográficamente. La región global refleja que los servicios por internet pueden alcanzar usuarios de muchos países. No acredita una flota multinacional ni un segundo lugar de recuperación.

Racks y electricidad: la capacidad útil aparece después de restar

La capacidad nominal de colocación dice cuánto podría consumir un cliente dentro de un paquete. La capacidad de recuperación dice qué queda cuando algo deja de funcionar. Entre ambas hay varias restas: espacio ya vendido, circuitos ocupados, límites térmicos, equipos averiados, mantenimiento, cargas que deben migrarse y reservas que no pueden compartirse. La información pública de Zone Networks presenta tamaños minoristas, pero no publica el total de racks, la ocupación, la potencia contratada, el consumo, la alimentación por rack ni las vacantes disponibles.

Un paquete de 20 A no prueba que exista hoy un rack vacío con esa potencia. Tampoco prueba que la alimentación permanezca disponible si falla el camino que usa otro rack. Para conocer la resiliencia de una máquina colocada haría falta identificar su armario, las unidades que ocupa, las dos rutas eléctricas si existen, la conexión de cada fuente, la distribución de PDU y el comportamiento ante la pérdida de una entrada. Para un servicio virtual habría que añadir la colocación de hosts, almacenamiento y red. Ninguna de esas relaciones se desprende de una tabla comercial.

El fallo de electricidad no tiene que abarcar todo un edificio. Puede afectar a una PDU, un circuito, un rack o una fuente. En ese caso, la redundancia general de SY3 o SY4 puede seguir funcionando mientras el servicio del cliente permanece interrumpido por un componente situado después de la infraestructura común. También puede suceder lo contrario: el edificio sostiene las cargas, pero la recuperación requiere trasladar equipos a un espacio que no tiene potencia reservada. La cifra relevante es la capacidad alimentada y utilizable bajo esa condición concreta.

La misma lógica se aplica a la refrigeración. N+1 o N+20 por ciento son propiedades de diseño del operador de la instalación. No indican la distribución térmica del rack, la densidad real de los equipos de Zone Networks ni la posibilidad de agregar carga migrada sin superar límites. Mover máquinas virtuales a menos hosts aumenta su utilización y su calor. La reserva informática solo es real si también existe reserva eléctrica, térmica, de almacenamiento y de red.

Por ello, una respuesta de compra no debería conformarse con “alojado en Equinix”. Necesita saber en qué instalación y dominio de fallo está cada componente; si la copia se encuentra fuera de ese dominio; si hay una segunda ubicación con espacio, electricidad y conectividad contratados; y cuánta carga puede aceptar. La declaración debe ser fechada porque la ocupación cambia. Un diseño que fue suficiente cuando se vendieron pocos servicios puede dejar de ofrecer margen sin que cambie la descripción de la página.

Esta es la primera gran capacidad sin demostrar: no cuánto espacio tiene Equinix ni qué paquetes anuncia Zone Networks, sino cuánta infraestructura propia o contratada permanece libre, encendida y accesible después de una avería de rack o alimentación. Hasta que ese valor se documente, la recuperación entre instalaciones es una posibilidad que debe probarse, no una conclusión.

Dos sistemas autónomos no equivalen a dos caminos físicos

La red ofrece otra forma de confundir visibilidad con reserva. Zone Networks está asociada públicamente con AS56106 y AS45152. El registro de AS56106 en PeeringDB declara presencia en varias instalaciones de Sídney, entradas en Singapur, un puerto de 10 Gbps en NSW-IX y una banda declarada de tráfico de 1 a 5 Gbps. El registro de AS45152 declara instalaciones de Sídney, un puerto de 10 Gbps en el intercambio de Equinix y la misma banda general. Es evidencia útil de interconexión. No es un mapa de cargas ni un balance de capacidad libre.

Las observaciones de bgp.tools para AS56106 mostraban ocho rutas IPv4 originadas, cuatro redes ascendentes observadas y una relación con NSW-IX. Las de AS45152 mostraban siete rutas IPv4 y relaciones ascendentes, entre ellas AS56106 y Vocus. BGP explica qué sistemas anuncian y alcanzan prefijos en un momento dado. No revela por qué conducto entra la fibra, si dos enlaces comparten una canalización, una bandeja, un cruce o un operador, ni si el camino alternativo puede recibir toda la carga tras un fallo.

Cloudflare Radar asocia AS56106 con el nombre ZONENETWORKS-AU, Australia, el sitio de la empresa y AS45152 como parte de la misma organización. Su perfil de AS45152 establece una asociación semejante con la actividad de alojamiento gestionado. Esa corroboración eleva la confianza en que las dos identidades de red pertenecen a la operación australiana. No aporta tráfico por cliente, número de servidores, productos disponibles ni rendimiento durante una contingencia.

Un puerto de 10 Gbps es un límite de interfaz, no un compromiso de transporte limpio ni 10 Gbps libres. La banda de tráfico declarada tampoco indica picos, distribución, sobreasignación o margen tras perder un enlace. Durante un ataque DDoS, la capacidad útil depende además del filtrado, del acuerdo con las redes ascendentes y de si el destino se anula mediante una ruta nula para proteger al resto. En una avería de operador, un puerto que sigue activo puede conducir a un camino que comparte el componente dañado.

La existencia de dos sistemas autónomos no prueba que un producto use ambos. AS45152 puede relacionarse con AS56106 sin que esa dependencia cree diversidad física. El cliente necesita conocer el ASN de su servicio, los operadores ascendentes aplicables, la separación física hasta el edificio, los cruces utilizados y la capacidad que queda si se pierde cada elemento. También necesita una prueba bajo carga, porque una ruta alternativa que acepta anuncios pero no puede transportar el volumen real no cumple la misma función.

Las entradas de Singapur merecen especial cautela. PeeringDB registra presencia de red declarada para AS56106 en instalaciones de esa ciudad. No demuestra que haya servidores de clientes, una réplica de almacenamiento ni copias de seguridad allí. Convertir una asociación de interconexión en una afirmación sobre ubicación de cómputo sería confundir la capa lógica con la física. La evidencia revisada mantiene a Sídney como centro demostrado de alojamiento y deja sin identificar un segundo lugar de recuperación.

Almacenamiento compartido: el fallo que puede inmovilizar la movilidad

Una máquina virtual parece móvil porque su cómputo puede arrancar en otro host. Esa movilidad depende del estado del almacenamiento, la red y el plano que coordina el traslado. Las páginas de Zone Networks describen SAN, vigilancia y migración de nodos, pero no publican la topología actual del sistema, su capacidad bruta y utilizable, la replicación, el número de controladores, los dominios de fallo ni el margen que queda en una emergencia.

Si un host falla y el SAN permanece íntegro, otro nodo con CPU y memoria libres podría recibir la carga. Si el problema afecta al almacenamiento compartido, todos los hosts que dependen de él pueden conservar potencia y red sin poder acceder a datos coherentes. En ese escenario, “auto recuperación” a nivel de cómputo no resuelve la causa. Haría falta otra copia consistente, un camino de almacenamiento sano, capacidad de lectura y escritura suficiente y un procedimiento para decidir desde qué punto se recupera.

La reconstrucción RAID ilustra el desfase de relojes. Encender un servidor sustituto no reconstruye de inmediato el conjunto. Durante la reconstrucción puede existir rendimiento reducido o riesgo adicional si aparece otro fallo. Si además la copia debe regresar por red, el plazo depende del volumen, del rendimiento del repositorio, del ancho de banda, de la concurrencia con otras restauraciones y de la validación final. Ninguno de esos factores cabe en el instante contractual en que el chasis recibe corriente.

El comprador tampoco puede deducir capacidad física sumando vCPU o gigabytes anunciados. Los recursos virtuales pueden estar compartidos. Un conjunto de planes de 8 vCPU no revela cuántos núcleos existen ni cuántas máquinas compiten por ellos. La reserva para una migración masiva tiene que calcularse después de considerar sobreasignación, cargas máximas y el mayor dominio de fallo. Si todos los clientes de un host deben moverse a la vez, el margen necesario es distinto del requerido para una sola máquina.

La prueba decisiva no consiste en observar que una consola permite pulsar “restaurar”. Debe medir el proceso completo con un conjunto representativo de datos: localizar el punto correcto, recuperar, comprobar integridad, arrancar servicios en orden, reconciliar transacciones y validar desde el exterior. También debe establecer qué ocurre si el repositorio principal o sus credenciales se han visto afectados. Sin ese ensayo, una copia es una esperanza almacenada, no una capacidad de recuperación demostrada.

La pieza de repuesto solo resuelve una parte de la avería

La recuperación de hardware depende de inventario y trabajo. Para un servidor dedicado puede hacer falta un chasis, una placa, memoria, discos, una controladora RAID, fuentes o cables compatibles. Para una plataforma virtual, la sustitución de un host puede exigir capacidad adicional ya instalada. Las páginas comerciales de Zone Networks no publican la cantidad de repuestos, su antigüedad, su compatibilidad, el lugar donde se guardan ni el tiempo de acceso fuera de horario.

La expresión “exceso de existencias” de una oferta antigua no puede convertirse en una promesa actual. Incluso si todavía hubiera unidades, el cliente necesitaría saber si están probadas, alimentadas, reservadas y preparadas con la conectividad adecuada. Una caja guardada sin discos correctos, firmware compatible o acceso inmediato puede reducir el tiempo de compra, pero no equivale a un servidor listo para recibir una carga.

El trabajo humano es otra forma de capacidad. Una intervención aislada puede atenderse rápidamente; varios fallos simultáneos compiten por las mismas personas. Una incidencia de edificio, almacenamiento o red puede generar muchos casos, diagnósticos y peticiones de restauración. El plazo real dependerá de cuántos técnicos estén disponibles, qué acceso físico tengan, qué tareas cubra cada modalidad de gestión y cómo se prioricen clientes. Nada de eso se desprende de un porcentaje de disponibilidad.

La distinción entre reparación y recuperación también evita asignar culpas de forma simplista. Zone Networks puede cumplir la tarea de sustituir un componente, mientras el cliente carece de una copia utilizable o de personal para reconstruir la aplicación. El cliente puede tener un buen procedimiento, pero no recibir a tiempo el acceso, la capacidad o los datos necesarios. La resiliencia se produce en la unión de ambos trabajos. Si la unión no está descrita, cada parte puede terminar su obligación sin que el servicio vuelva.

Un acuerdo maduro debería nombrar los hitos. Entre ellos están la detección, el reconocimiento del caso, el diagnóstico, la disponibilidad del repuesto, el encendido, el acceso al almacenamiento, la recarga del sistema, la restauración, la validación y la reapertura al público. Cada hito necesita propietario, plazo de comunicación y evidencia. Así se evita que “hardware operativo” se interprete como “negocio recuperado” cuando aún faltan horas de trabajo.

También conviene preguntar por fallos correlacionados. ¿Qué inventario queda si se dañan varias unidades del mismo modelo? ¿Puede el repuesto utilizarse sin consumir la reserva necesaria para otro servicio crítico? ¿Se ha probado un cambio a hardware diferente? La capacidad de recuperación no es el número de piezas en un estante, sino la cantidad de cargas que pueden volver en el orden y el tiempo comprometidos.

La copia diaria no nombra el destino ni prueba el regreso

Las copias son el puente entre ambos relojes, pero solo si sobreviven a la causa del incidente y regresan a una velocidad útil. La política de uso aceptable indica que se crean imágenes diarias para determinados servicios y atribuye al cliente la responsabilidad de conservar copias locales o externas. Esa formulación tiene dos efectos. Delimita qué productos reciben una práctica anunciada y deja claro que el cliente no debe tratarla como su única protección.

Una programación diaria no demuestra que todos los trabajos hayan finalizado. Tampoco identifica el último punto íntegro, la consistencia de aplicaciones con escritura activa, el cifrado, la separación de credenciales ni la resistencia a una eliminación accidental o maliciosa. Si la copia comparte el mismo sistema de administración que la carga, una cuenta comprometida puede alcanzar ambas. Si está en el mismo edificio o dominio de almacenamiento, una avería común puede impedir acceder a las dos.

Zone Networks anuncia opciones locales y externas, pero no publica el nombre de la segunda instalación, la ciudad, la distancia operativa, la red utilizada, la tasa de restauración, la capacidad total, la ocupación ni el historial de pruebas. “Externa” es una relación con un lugar de origen, no una arquitectura completa. Puede significar otro equipo, otro rack, otro edificio o una ubicación más distante. Cada posibilidad protege contra un conjunto diferente de fallos.

La orientación australiana sobre copias periódicas y restauración pone el acento en coordinar las copias, probar su recuperación y protegerlas frente a modificaciones o eliminaciones por usuarios sin privilegios. Es una referencia general, no una evaluación de Zone Networks. Sirve para formular la prueba que falta: no basta con mostrar que el trabajo se ejecutó; hay que demostrar que el contenido puede recuperarse y que el camino de retorno no depende del componente que se intenta reemplazar.

La velocidad importa tanto como la existencia. Una copia de 1 TB puede ser una opción comercial anunciada, pero el dato de capacidad no dice cuánto tarda en volver. El tiempo depende del rendimiento del repositorio, del enlace, de la escritura en destino y del número de clientes que restauran a la vez. Una prueba hecha con pocos gigabytes en un periodo tranquilo no mide una avería compartida. El comprador necesita un volumen representativo y un supuesto de concurrencia.

También debe definir el punto de recuperación aceptable. Una imagen nocturna puede perder cambios realizados desde la última ejecución. En una base de datos, recuperar archivos sin coordinar registros y transacciones puede producir inconsistencias. La continuidad empresarial exige decidir cuánto dato se puede perder, comprobar que la frecuencia lo permite y documentar cómo se valida la aplicación. El objetivo no puede deducirse de la palabra “diaria”.

Por último, el cliente necesita una salida independiente. Una copia local bajo su control o en otro destino reduce la dependencia del portal, la facturación y el personal del mismo prestador. Debe incluir datos, configuraciones, claves, certificados, instrucciones y versiones necesarias. Si solo se conserva el contenido pero no el contexto para arrancarlo, la restauración puede terminar técnicamente mientras el servicio sigue inutilizable.

Las exclusiones cambian el significado del porcentaje

Las páginas de Zone Networks emplean expresiones de 99,9, 99,99 e incluso 100 por ciento en distintos contextos. Esas cifras no deben combinarse ni elegirse por apariencia. El documento aplicable, el producto contratado y el calendario de medición determinan qué objetivo rige. El acuerdo público data de enero de 2018, y un calendario firmado más reciente podría modificarlo. La única lectura responsable es pedir el texto vigente y reconciliar cada afirmación comercial con él.

Además del límite sobre la avería de hardware, el acuerdo reduce o excluye remedios en varias situaciones: mantenimiento, demoras de redes ascendentes o terceros, problemas de suministro o electricidad, DNS externo, DDoS y determinados servicios que no son HTTP. Cada exclusión puede coincidir con una interrupción real para el cliente. Que un periodo no compute para un crédito no significa que la aplicación haya seguido disponible.

Los créditos exigen una acción del cliente y se presentan como remedio exclusivo. Eso convierte la observabilidad en una responsabilidad práctica. El cliente necesita registros externos, horas precisas, alcance del fallo y un procedimiento para reclamar. Pero el valor financiero del crédito no compensa necesariamente ventas perdidas, trabajo de recuperación, daño reputacional ni obligaciones propias. El remedio contractual y el impacto económico miden cosas distintas.

Una demora de una red ascendente ilustra el problema. Desde el punto de vista de la aplicación, los usuarios no llegan. Desde el texto contractual, parte del incidente puede depender de un tercero y quedar fuera. Algo parecido ocurre con DNS: el servidor puede estar sano mientras el nombre no resuelve, o puede haberse migrado la carga sin actualizar los registros. El segundo reloj sigue avanzando porque el servicio de negocio incluye todas las dependencias necesarias para que el usuario complete su tarea.

El ataque DDoS añade una decisión de protección colectiva. La red puede filtrar, limitar o anular el destino para preservar otros servicios. El resultado puede ser razonable para la plataforma y aun así dejar inaccesible al cliente afectado. Una promesa de mitigación necesita detallar capacidad limpia, alcance, desencadenantes de ruta nula, comunicación y opciones de recuperación. Un puerto anunciado o una mención comercial a DDoS no proporciona esos valores.

Por eso el porcentaje debe acompañarse de una lista de escenarios y de los relojes que se aplican a cada uno. Fallo de host, almacenamiento, rack, alimentación, instalación, red ascendente, intercambio, DDoS, DNS y copia corrupta no son equivalentes. Si el contrato solo mide una parte estrecha, el cliente debe establecer su propio indicador de recuperación de extremo a extremo y ensayarlo.

Soporte, cuenta y acceso también son infraestructura

Una recuperación puede atascarse aunque haya espacio, electricidad y repuestos. El cliente debe poder autenticarse, abrir un caso, demostrar autoridad, recibir respuesta y coordinar cambios. Si las credenciales estaban en el sistema caído, si la persona autorizada no está disponible o si el segundo factor depende de un dispositivo perdido, el tiempo de soporte comienza antes de que alguien examine el servidor.

La modalidad de servicio modifica quién tiene permisos. En un equipo no gestionado, Zone Networks puede limitarse al hardware y la conectividad. En uno gestionado, ciertas tareas del sistema o la base de datos podrían formar parte de la atención, pero deben confirmarse por escrito. Los nombres Bronze y Gold sugieren capas distintas; no sustituyen una enumeración de acciones. El comprador necesita saber si la recuperación desde copia, el cambio de cortafuegos, la reparación de una base de datos y la actualización de DNS están incluidos, disponibles con coste adicional o fuera del alcance.

La facturación también puede convertirse en un punto único de fallo. Las condiciones contemplan suspensión, terminación y eliminación de datos. Una tarjeta caducada, una disputa o una notificación que no llegue puede coincidir con una incidencia técnica. El plan de continuidad debería mantener contactos alternativos, métodos de pago, avisos a más de una persona y un procedimiento de escalado. No se trata de suponer mala actuación, sino de reconocer que el acceso comercial controla recursos técnicos.

La terminación plantea la recuperación más amplia: salir. El cliente debe conocer el formato de exportación, el plazo para retirar datos, la asistencia disponible y el comportamiento de las copias después de cancelar. Una aplicación atada a direcciones IP, licencias o dispositivos específicos puede no arrancar en otro lugar aunque sus archivos sean portables. Preparar la migración antes de necesitarla reduce el segundo reloj.

En una avería regional o compartida, el soporte es una reserva tan tangible como un servidor libre. Si muchas personas llaman a la vez, aumentan las colas. El contrato debería definir prioridad, actualización de estado, responsables de decisión y frecuencia de comunicación. También debería separar el canal de estado del mismo sistema que puede fallar. La existencia de navegación de soporte y estado en el portal es útil, pero no prueba su independencia ni su rendimiento durante una crisis.

El cliente puede ensayar esta capa sin provocar una caída: revisar contactos, recuperar una cuenta, abrir un caso de prueba, pedir una exportación, verificar autorizaciones y simular una llamada fuera de horario. Esas acciones descubren dependencias humanas que no aparecen en los diagramas de red. La continuidad real combina infraestructura, contrato y capacidad de coordinación.

La localidad australiana ayuda, pero no cierra la soberanía

Alojar en Sídney puede reducir distancia y facilitar una preferencia por ubicación australiana. No basta para afirmar que todos los datos, accesos y derivados permanecen en Australia. La política de privacidad de Zone Networks dice que la mayor parte de la información personal que recoge se almacena en Australia, pero permite cierto almacenamiento en el extranjero. Esa declaración se refiere a información de cuenta en manos de la empresa. No localiza automáticamente la carga del cliente, sus copias, registros, tickets, accesos de soporte o subcontratistas.

El marco federal se encuentra en la Privacy Act 1988, cuya aplicación concreta depende de la entidad, los datos y las circunstancias. La orientación de la OAIC sobre APP 8 distingue cuestiones como divulgación en el extranjero, almacenamiento por contratistas bajo control efectivo y tránsito. Una ruta que cruza otro país no es necesariamente lo mismo que entregar datos a una entidad extranjera, y una presencia de red en Singapur no demuestra por sí sola ninguna de esas situaciones.

La orientación de la OAIC sobre APP 11 subraya medidas razonables de seguridad, riesgo de terceros, controles físicos y deberes durante el ciclo de vida de la información. Es orientación general, no una conclusión sobre el cumplimiento de Zone Networks. Para el comprador, significa que elegir un alojamiento australiano no elimina su deber de entender quién controla la información, quién puede acceder y cómo se destruye cuando deja de ser necesaria.

La soberanía debe descomponerse en preguntas contratables. ¿Dónde está la instancia principal? ¿Dónde se escriben las copias? ¿Dónde viven los registros y tickets? ¿Desde qué países puede entrar el soporte? ¿Qué terceros transportan, filtran o almacenan datos? ¿Qué información de cuenta sale al extranjero? ¿Cómo se notifica un cambio? Una respuesta válida puede ser diferente para cada capa.

Las organizaciones reguladas por APRA tienen además sus propias obligaciones. CPS 230 exige a las entidades alcanzadas mantener operaciones críticas y gestionar el riesgo de prestadores de servicios. La norma recae sobre el comprador regulado; no demuestra que Zone Networks atienda a una entidad de ese tipo ni que satisfaga sus controles. Utilizarla como lista de preguntas es razonable. Presentarla como certificación del alojamiento no lo sería.

La localidad sigue teniendo valor. Una ubicación conocida en Sídney puede mejorar latencia, jurisdicción contractual y claridad sobre el centro principal. Su valor aumenta cuando se acompaña de compromisos que cubren producción, copias, registros, soporte y subcontratación. Sin esos compromisos, “australiano” describe un centro demostrado y una identidad empresarial, pero deja abiertas partes esenciales de la cadena de datos y recuperación.

Nueve fallos que cruzan la frontera contractual

Un fallo de alimentación de instalación o rack pregunta si el servicio usa caminos redundantes hasta el equipo concreto. El edificio puede tener N+1 mientras una PDU o una alimentación única deja fuera al rack. El cliente necesita saber dónde termina la protección de Equinix y cómo continúa dentro del diseño de Zone Networks.

Un fallo de almacenamiento compartido o hipervisor pregunta si la movilidad anunciada conserva acceso a datos. Puede haber hosts encendidos sin un volumen sano. La recuperación exige otra copia, capacidad de lectura y un orden de arranque, no solo un destino de cómputo.

Un fallo de red ascendente, intercambio, cruce o encaminamiento pregunta por diversidad física y margen. Varias relaciones BGP pueden converger en el mismo conducto. Un puerto alternativo puede aceptar rutas sin disponer de capacidad suficiente para toda la carga.

Un ataque DDoS pregunta por capacidad limpia y decisiones de filtrado. El servicio puede quedar anulado para proteger la red, y esa interrupción puede recibir un tratamiento contractual distinto. El cliente necesita conocer umbrales, comunicación y alternativas.

Una escasez de repuestos pregunta por inventario compatible y acceso humano. El acuerdo puede medir el hardware, pero no publica las piezas ni la reserva. Si varios equipos fallan, cada restauración compite por material y técnicos.

Una demora de soporte pregunta quién es responsable de cada acción. El equipo puede estar disponible mientras nadie instala, restaura o valida. Una modalidad no gestionada y una gestionada crean fronteras distintas, que deben estar escritas antes del incidente.

Una suspensión de facturación o pérdida de portal pregunta si el cliente conserva control operativo. Sin acceso a la cuenta puede no abrir casos, cambiar servicios ni extraer datos. La continuidad necesita contactos y canales alternativos.

Una copia corrupta o inaccesible pregunta si se ha probado la restauración. La fecha de un trabajo no garantiza integridad. Si el repositorio comparte sitio, credenciales o administración con la carga, la misma causa puede alcanzar a ambos.

Por último, DNS, licencias, secretos y listas de direcciones IP permitidas preguntan si una aplicación puede vivir fuera de su entorno original. Mover datos y cómputo no actualiza todos esos vínculos. El reloj empresarial termina únicamente cuando el conjunto vuelve a funcionar para usuarios reales.

Estos nueve caminos no afirman que Zone Networks haya sufrido cada fallo ni que carezca de controles. Muestran por qué las pruebas disponibles no bastan para asignar un tiempo completo de recuperación. Cada camino cruza una frontera entre edificio, red, hardware, sistema, contrato y cliente. Cuantas más fronteras atraviesa, menos útil resulta medir solo una de ellas.

La prueba de recuperación debe terminar en una transacción válida

Una prueba convincente comienza con un escenario, no con un botón. El cliente debe elegir una pérdida concreta: un host, un rack, un almacenamiento, una ruta o el centro principal. Después debe documentar qué detecta Zone Networks, qué detecta el cliente, quién decide recuperar y desde qué copia. El objetivo es observar los dos relojes sin mezclarlos.

El primer conjunto de tiempos pertenece a la infraestructura: reconocimiento, diagnóstico, disponibilidad de capacidad, sustitución, encendido y conectividad. El segundo pertenece al servicio empresarial: acceso a datos, reconstrucción, arranque, resolución de dependencias, validación y reapertura. Registrar ambos permite identificar si la mayor demora está en el metal, en el movimiento de información o en la coordinación.

La restauración debe usar un volumen y una complejidad representativos. Una aplicación con base de datos requiere comprobar consistencia, no solo que existan archivos. Una web con pagos, correo o identidad necesita probar conexiones externas. Una máquina con licencias debe demostrar que puede reactivarse en otro equipo. Las listas de IP, secretos y certificados deben estar disponibles sin depender del servidor perdido.

La validación final debe observarse desde el punto de vista del usuario. No basta con que el sistema responda a una comprobación interna. Hay que completar una transacción válida, confirmar que los datos recientes corresponden al punto elegido, revisar errores y medir rendimiento. Solo entonces se detiene el reloj empresarial.

La prueba también debería hacerse con la copia que se utilizaría de verdad y desde el destino declarado. Si se ensaya con una copia local rápida pero el plan de desastre depende de una copia externa, se mide otro camino. Si se usa capacidad temporal no reservada, el resultado no garantiza disponibilidad durante un incidente compartido. El informe debe identificar cada recurso prestado y cada supuesto.

Por último, el ensayo necesita repetición. Cambian el tamaño de los datos, las versiones, las personas y la ocupación. Una prueba antigua puede demostrar que el proceso funcionó una vez, pero no que sigue dentro del objetivo. La fecha, el volumen, el punto recuperado, los tiempos de cada hito y los problemas encontrados convierten el ejercicio en evidencia útil.

Esta práctica no contradice un SLA. Lo completa desde la perspectiva del cliente. El acuerdo puede seguir midiendo la parte bajo control del prestador, mientras el comprador mide su operación de extremo a extremo. La diferencia entre ambos resultados es precisamente el trabajo que debe reducirse, contratarse o aceptar como riesgo.

Qué debe demostrar una reserva de recuperación

La reserva de cómputo debe expresarse después del mayor fallo previsto. Si se pierde un host, ¿cuánta CPU y memoria libre queda? Si se pierde un rack, ¿puede otro recibir todas las máquinas prioritarias? La respuesta necesita una fecha, una carga máxima y una regla de prioridad. Un total instalado sin descontar lo vendido no es reserva.

La reserva de almacenamiento debe distinguir capacidad bruta, utilizable, ocupada y disponible durante reconstrucción. También debe identificar la réplica y sus dominios de fallo. Un SAN con espacio libre puede seguir siendo un punto común. Una segunda copia sin rendimiento suficiente puede proteger los datos y aun incumplir el tiempo.

La reserva de red debe separar intercambio, transporte y mitigación. La velocidad del puerto no equivale a compromiso del operador ascendente. La diversidad lógica no equivale a separación de conductos. La prueba debe perder un camino y medir el tráfico real por el restante, incluidos los filtros necesarios.

La reserva eléctrica debe llegar hasta el servidor. Importan las alimentaciones del rack, las PDU, las fuentes del equipo y la capacidad térmica. La redundancia del edificio es condición necesaria, no resultado final. La información de Equinix debe combinarse con el diseño particular contratado por Zone Networks y con la conexión concreta del cliente.

La reserva de repuestos debe identificar modelos, compatibilidad y tiempo de acceso. Para configuraciones antiguas, una pieza exacta puede ser difícil de conseguir; para una sustitución distinta, aumenta el trabajo de programas y controladores. El objetivo debería medir no solo el encendido, sino el momento en que el sistema puede empezar una restauración fiable.

La reserva de copias debe indicar ubicación, aislamiento, retención, integridad y velocidad. Debe sobrevivir al escenario que obliga a utilizarla. También debe existir capacidad para varias restauraciones concurrentes, porque una avería compartida no respeta una cola diseñada para un solo cliente.

La reserva de soporte debe describir personas, turnos, acceso físico y escalado. En una crisis, la comunicación consume tiempo de los mismos equipos que reparan. Un estado claro y actualizaciones previsibles reducen consultas repetidas, pero no sustituyen suficientes manos para ejecutar el trabajo.

No se dispone públicamente de estos totales para Zone Networks: racks ocupados, potencia contratada, hosts, utilización, sobreasignación, SAN bruto y utilizable, replicación, repuestos, ocupación de copias, inventario vendido y margen durante fallos. La ausencia de cifras no prueba ausencia de capacidad. Sí impide tratarla como demostrada y obliga al comprador a obtener evidencia específica.

Un pliego de continuidad para el comprador

El primer documento que debe pedir un cliente es un calendario de servicio fechado que nombre a Zone Networks Pty Ltd, el producto, la instalación y la métrica aplicable. Debe resolver las diferencias entre los porcentajes de las páginas y establecer qué interrupciones se incluyen. También debe conservar separados el objetivo de reparación de infraestructura y el objetivo de recuperación empresarial.

El segundo documento debe dibujar los dominios de fallo. No necesita revelar información que comprometa seguridad, pero sí identificar si producción, copia y administración comparten edificio, rack, alimentación, almacenamiento, red o credenciales. Para una carga repartida entre SY3 y SY4, debe probarse la duplicación real, no solo la presencia comercial en ambos nombres.

El tercero debe cuantificar reserva. Debe incluir capacidad de hosts, almacenamiento, red, potencia y restauración después de perder el componente acordado. Una frase como “hay redundancia” es insuficiente sin saber qué se pierde, qué queda y qué carga debe soportar.

El cuarto debe describir repuestos y trabajo. Conviene obtener los plazos para hardware compatible, acceso fuera de horario, número de intervenciones concurrentes y responsabilidades de cada nivel de gestión. El punto contractual donde deja de medirse la avería debe aparecer al lado del trabajo que todavía queda.

El quinto debe localizar las copias. El cliente necesita instalación o región, retención, cifrado, control de acceso, separación de cuentas, proceso de borrado y rendimiento de restauración. Si existe una opción externa, debe nombrarse su dominio de fallo y probarse con el volumen real.

El sexto debe definir recuperación y escalado. Debe fijar cuánto dato puede perderse, cuánto tarda cada aplicación, qué orden sigue y quién valida. Los contactos, canales alternativos, frecuencia de comunicación y autoridad para decisiones deben estar probados.

El séptimo debe preparar la salida. Formatos, exportación, costes, plazos, DNS, licencias, secretos y listas de IP forman parte de la portabilidad. Una copia que solo puede arrancar dentro del mismo entorno no proporciona una salida completa.

El octavo debe cubrir localidad y acceso. Si el requisito es Australia, el compromiso debe nombrar producción, copias, registros, tickets, información de cuenta, soporte y terceros. La dirección de un centro principal no basta para las demás capas.

El noveno debe ser una prueba observada. Debe registrar la fecha, el fallo simulado, el volumen, el punto recuperado, el tiempo de hardware y el tiempo de negocio. Los resultados tienen que alimentar cambios concretos en capacidad, procedimiento o contrato.

Estas peticiones no presuponen que Zone Networks vaya a fallar ni que sus controles sean débiles. Son la diligencia necesaria cuando la evidencia pública solo permite una confianza media en la operación de red y baja en escala, capacidad libre, ubicación de cargas y rendimiento de recuperación. Una relación pequeña puede responder bien si sus límites están claros y ensayados. También puede concentrar dependencias que solo se descubren durante una interrupción.

El servicio vuelve cuando vuelve la actividad

Zone Networks ofrece señales coherentes de una empresa australiana operativa, de dos identidades de red visibles y de una asociación de alojamiento con Sídney. Esas señales justifican estudiar el servicio. No justifican asignarle los racks, la electricidad y la redundancia de todo Equinix, ni convertir puertos de intercambio en transporte libre, ni convertir una frecuencia de copia en un tiempo de restauración.

El documento más revelador no es la tarjeta de un VPS ni la superficie de SY3 o SY4. Es la frase contractual que separa el encendido del reemplazo de la recarga, la reconstrucción RAID y la recuperación de datos. Esa frase obliga a preguntar quién gobierna la hora restante. En ese intervalo viven el almacenamiento, la copia, la red, los técnicos, el DNS, las licencias, los secretos, la validación y la capacidad del cliente para tomar decisiones.

La resiliencia no se obtiene sumando características nominales. Se obtiene restando los componentes perdidos y comprobando qué queda. Un rack anunciado no es un rack libre; 10 Gbps de interfaz no son 10 Gbps de margen; N+1 en un edificio no es doble alimentación hasta la aplicación; dos ASN no son dos conductos; una copia externa sin destino no es una segunda ciudad; un servidor encendido no es una empresa recuperada.

La conclusión no requiere especular sobre la escala de Zone Networks. La evidencia permite tratarla como un operador australiano de alojamiento y red con confianza media. Al mismo tiempo, obliga a mantener baja la confianza sobre flota, capacidad, ubicación exacta de cargas y margen utilizable durante fallos. Ese juicio puede mejorar con documentos fechados, cifras posteriores a una avería prevista y una restauración completa observada.

Hasta entonces, el cliente debe mantener los dos relojes a la vista. El primero mide cuánto tarda Zone Networks en devolver hardware y conectividad dentro de los límites acordados. El segundo mide cuánto tarda la organización en recuperar una actividad válida para sus usuarios. El riesgo más importante está en creer que ambos se detienen juntos. La continuidad empieza cuando se contrata y prueba todo lo que ocurre entre uno y otro.