Carbonite Failover
Cuando hablamos de Recuperación en caso de una Contingencia, lo más importante es minimizar el tiempo perdido: {simplepopup link=”rto-rpo”}RTO.{/simplepopup} La funcionalidad que permite conseguir unos RTOs mínimos es el Failover.
Las pruebas periódicas de Failover garantizan que en un momento de crisis todo funcione perfectamente.
La agilidad del Failover y su alto nivel de automatismo son decisivos para lograr la operatividad de los usuarios en el Backup Server en un tiempo muy corto.
Visita el post en nuestro Blog: Dormir tranquilo con una solución de continuidad
En la solución Carbonite Availability existen dos tipos de Failover:
Failover aplicativo
Activa la aplicación (Exchange, SQL, Sharepoint, BES y Servidores de Ficheros, entre otras) en el Backup Server y conmuta a los usuarios. Soporta entornos Cluster y replicación de modificaciones en los datos de usuario.
Ver en la siguiente animación los pasos del Failover aplicativo, y la vuelta a la situación original: el Failback.
Full-Server Failover
Failover del sistema completo, desde servidores de ficheros hasta servidores de aplicaciones y controladores de dominio. Realiza la replicación en tiempo real de los cambios en el SO, las aplicaciones y los datos, y en caso de contingencia, realiza el Failover completo.
Ver la animación del Full Server Failover:
- Minimiza el tiempo perdido
- Agilidad y automatismo
Los Servicios de Mantenimiento de Software Greenhouse incluyen pruebas periódicas de Failover. Dichas pruebas garantizan que en un momento de crisis todo funcione perfectamente.
{simplepopup popup="false" name=”rto-rpo”}
Definiciones de RTO y RPO
RTO indica el tiempo a partir del cual la inactividad de las aplicaciones se vuelve insostenible: Recovery Time Objective expresa el tiempo durante el cual una organización puede tolerar la falta de funcionamiento de sus aplicaciones y la caída de nivel de servicio asociada, sin afectar a la continuidad del negocio.
RPO indica el umbral sostenible de pérdida de transacciones: Recovery Point Objective se refiere al volumen de datos en riesgo de pérdida que la organización considera tolerable. ¿Las transacciones de cuánto tiempo estamos dispuestos a perder, o a tener que reintroducir al sistema?
Los dos parámetros indican, de diferentes formas, el nivel de criticidad de las aplicaciones. Son esenciales para darle una dimensión correcta al proyecto y hay que definirlos en una fase incipiente del proyecto.
{/simplepopup}