Webinar: Asegura la continuidad de la operación de tu negocio

La agenda del día de hoy, iniciaremos con ¿Quiénes somos? ¿Quién es Compuclo? ¿A qué nos dedicamos, cuáles son las principales amenazas y peligros que corren las empresas en el día de hoy, principalmente por medio de tecnologías y demás? Seguido por las consecuencias de ser vulnerables a las amenazas y no contar con un DRP, que en este caso es el tema principal del webinar, que es una de las soluciones que nosotros consideramos que ayuda muchísimo a las empresas para en cualquier caso de algunas contingencias y poder tener su información a la mano y no tener como grandes pérdidas. Seguido de esto, tendremos medidas de prevención para la continuidad de la empresa, qué es un DRP qué y lo que es nuestra solución Sarpilot Live, que en este caso es el lanzamiento de esta nueva solución que esperemos que les sea de utilidad y poder contar con ustedes para mayores temas. Entonces, en este momento le cedo la palabra a mi compañera Karen Delgado, quien dará continuidad de este webinar.

Hola, muy buenos días a todos, muchas gracias por acompañarnos y tal como lo comenta mi compañera Bianca, mi nombre es Karen Delgado y soy analista comercial en la empresa de Compuclau. Y bueno, pues para comenzar, ¿Quién es Compuclaud? Para que nos conozcan un poco, pues somos el proveedor líder de servicios administrados en la nube. Tenemos presencia en lo que es México y Latinoamérica. Ofrecemos soluciones integrales de asesoría, monitoreo de infraestructura, seguridad, herramienta de productividad, colaboración, respaldo y servicios especializados. Trabajamos en conjunto con líderes en el mercado a nivel mundial como es Amazon Web Services, de hecho actualmente somos Partner Bands, este año conseguimos ese privilegio y además contamos con más de 7 años de experiencia en el mercado que nos respaldan. Y para dar inicio, digo, ¿Cuántos de nosotros no nos hemos preguntado qué tan vulnerables somos ante un ataque o robo de información? Y déjenme comentarles que México se encuentra en los primeros lugares de vulnerabilidad que son los fraudes y ataques cibernéticos. De hecho, de diciembre 2018 a enero del 2019 aumentó hasta un 61% los ataques de malware. Esto nos deja con, como bien lo dice aquí la información en México nos deja con un 54% de ataques sufridos durante todo un año. Entonces, el chiste de este webinar para nosotros es hacer un poco de conciencia sobre ustedes y sobre todo generar una cultura de prevención porque muchas veces no lo tenemos y nos esperamos hasta que nos pase algo malo para reaccionar y ese no es el caso, nos gustaría que tuvieran ya una prevención antes de que nos pasara algo malo. Entonces aquí nosotros les enumeramos nuestras principales amenazas que abundan en el mercado, que al final de cuentas estas amenazas son el motivo por el cual debemos de tener un sistema de respaldo o bien un DRP dentro de nuestra empresa, porque al final de cuentas existen muchísimas amenazas y cada día van haciéndose más y más y nosotros estamos muy vulnerables y perceptibles a sufrir un ataque. Entonces nuestras principales amenazas aquí que nos ofrecen les queremos exponer es el uso de redes públicas, también un daño físico del servidor que cuántas veces no pasa que se nos daña una tarjeta madre, se nos puede llegar a caer incluso el servidor o les da un golpe y ya falló. También pues los errores humanos que es cuando accidentalmente se comete el borrado de información, puede ser tanto de un administrador o de un usuario y es muy difícil recuperar esa información sin no tenemos un respaldo. También esos correos maliciosos que pueden ser tanto como de malware, gusanos, troyanos, cusomware y lo que hacen es dañar la información que tenemos, a veces no la pueden encriptar y de hecho sucede que hasta la pueden secuestrar y pues ahí sí se pueden perder cantidades valiosas de información que al final de cuentas se puede representar también en costos. También una mala configuración de nuestra seguridad, un desastre natural que nadie estamos exentos a que pase esto y lo puede sufrir desde un temblor, una inundación que puede suceder que por estos casos no podamos ingresar a nuestras oficinas y no tengamos acceso al trabajo de que día a día desarrollamos, entonces también es importante tenerlo en cuenta. También ataques internos, personas que a lo mejor ya sospechan que van a salir de la empresa y gente maliciosa. También pues el robo de equipo que la seguridad de nuestro país lamentablemente en crece y tampoco estamos exentos a que un día nos queramos llevar nuestra computadora a nuestra casa, seguir trabajando y ya nos tocó como un asalto o un robo en nuestro carro cuando dejamos ahí nuestras pertenencias. También las consecuencias de ser vulnerables a las amenazas y por lo tanto no tener un respaldo de lo que ya tenemos, pues es el secuestro de nuestra información por un hacker, que esto suena como una película, pero es muy normal, es muy común. De hecho una de las principales amenazas que está dentro de este año y del año pasado, de hecho iniciando el año tuvimos un caso de un prospecto que ya teníamos ahí trabajando un proyecto precisamente de ERP de respaldo para su empresa, se había ido posponiendo un par de meses por cuestiones de que le daban prioridad a otras cosas, como normalmente lo hacemos, que le damos prioridad a algo que creemos que no vamos a necesitar, hasta que un día nos llama y nos dice que le secuestraron una parte de su información y que le están pidiendo una remuneración a cambio. Entonces sí era como de no, pues ahora qué hago, o sea no tengo absolutamente nada respaldado y pues tampoco les voy a pagar el casi millón y medio de lo que me están pidiendo por recuperarlo. Entonces sí hay que tener en cuenta estas cosas sí suceden, sí pasan y hay que crear conciencia si es que dentro de nuestra empresa no tenemos algo que nos respalde. ¿Y bueno, cómo cuáles son las consecuencias de ser vulnerables, las consecuencias de no contar con un ERP? La principal pues es la pérdida de información, que cada información que perdemos es contado en tiempo y sobre todo en costos, porque a veces mucha información puede ser nuestra facturación, nuestras nóminas cuando nos atacan, también la parte de las compras de las empresas y también está la estafa mediante correos, que a quién no nos llega ahora nuestros correos, esos correos que según esto es tu nómina de tu trabajo o que es una factura con su XML, o que ya nos ganamos un viaje y al momento de abrirlo es cuando entran estos bichos en nuestras computadoras y hasta nos pueden llegar a robar la información de nuestras cuentas bancarias, que es ahí ya cuando se comente. También los fraudes a tarjetas de crédito, tarjetas de débito y pues nadie queremos eso. Y creo que el último y el más importante, aunque se escucha muy dramático el escenario, es el cierre de las empresas, porque aquellos que son atacados fuertemente, que es como un secuestro que les comento que se está usando muchísimo, normalmente llegan a secuestrar todo lo que encuentra y no te lo encriptan y no te lo regresan si no es que pagas y muchas veces aunque pagando no te lo recuperan al 100% o si no es que absolutamente nada. Entonces sólo el 6% de estas empresas que sufren este tipo de pérdida, solamente el 6 % continúan con la operación porque los otros se ven en necesidad de cerrar porque ya no pueden seguir con su continuidad y su negocio. Entonces, ¿Cómo es la manera en la que nosotros podemos prevenir este tipo de desastres? Existen varias maneras y una de ellas es contar con los respaldos diarios, lo que nosotros creemos que son archivos de importancia, que son críticos, también tenemos que asignar responsables que se encarguen de hacerlos. Necesitamos evaluar los riesgos que corremos dentro de nuestro empresa. También podemos utilizar lo que son los respaldos híbridos que es dentro de nuestra infraestructura y mandarlos a la nube. Tenemos que hacer una planeación y gestión de respaldos, métodos de autenticación que muchas veces no los tenemos por falta de costumbre, dejamos que a lo mejor cualquiera pueda dentro de la misma empresa pueda entrar con una sola credencial y se comparten las credenciales. También debemos de contar con los pardos acordes a nuestro RPO de la organización, un monitoreo y sobre todo ejercicios de recuperación para saber que lo que estamos utilizando realmente funciona como debería. Y pues el DRP es aquel que nos va a permitir recuperarnos con la menos pérdida de información y además nos puede habilitar un nuevo escenario lo más parecido previo a la falla que nos sucedió o la contingencia que tuvimos. Y bueno, le voy a ce la palabra a mi compañero Obed que es el ingeniero encargado y especialista en soluciones de DRP para que nos pueda explicar un poco más a fondo y a detalle lo que viene siendo un BRP.

¿Qué tal? Muchas gracias a mi compañera Carla, perdón Karen por la introducción y en efecto el tema que nos compete el día de hoy es hablar un poco de lo que es un DRP. Y bueno básicamente un DRP viene de las siglas en inglés de SASTR, que básicamente se define como una estrategia o un conjunto de acciones que nosotros podemos realizar y procedimientos planificados para poder básicamente generar lo que nosotros llamamos continuidad del negocio. Es muy importante como lo comentaba mi compañera Karen, contar con un Disaster Recovery Planning ya que nos va a permitir recuperar cierto dato o en su defecto, o en todo caso prácticamente máquinas completas o datacenters completos en dado caso de que ese sea el alcance de nuestro Doctor Y bueno, básicamente ¿Cómo funciona un Doctor Pues el Doctor Nos va a permitir tener respaldos de nuestra información y a partir de esos respaldos poder habilitar nuestra información o nuestra infraestructura como les comentaba en otra ubicación o en otro servidor o en otro centro de datos? Dos puntos muy importantes a la hora de hablar de un Disaster Recovery Planning son los que están plasmados en la lámina y que básicamente me gustaría que se los pudieran llevar el día de hoy como dos puntos muy importantes que si en nuestra organización aún no tenemos esos dos datos, pues vale la pena prestarle foco y trabajar en ello. El RPO y el RTO, estas dos términos muy famosos a la hora de querer implementar un Disaster Recovery. Pues bueno, RPO viene dado de las siglas en inglés igual Recovery Point Objective y básicamente a mí me gusta traducirlo como el tiempo en información que yo estoy dispuesto a perder. ¿En cuanto yo tengo una contingencia, eso se traduce directamente a un último backup o a una última réplica de información, correcto? En cuanto supongamos que se da una contingencia, simplemente el servidor se apagó o el servidor se quemó la tarjeta madre, cualquier cosa que pudiera afectar la operación de de la infraestructura o de alguna aplicación, nosotros lo vamos a definir como contingencia. De ese momento de tiempo hacia atrás, mi último backup, ese sería mi punto de recuperación. Y bueno, el RTO que viene igual del inglés Recovery Time Objective, es el tiempo en que mi organización, mi empresa necesita estar en marcha de nuevo, es decir que esa aplicación o que todo mi centro de datos o que ese servidor necesita estar operando nuevamente. ¿Igual se da en tiempos, ambos puntos se dan en tiempo, correcto? Estos son como les comentaba, los dos puntos primordiales a la hora de poder hablar de un Doctor Y querer generar un Doctor Si no tenemos estos dos puntos va a ser muy difícil que nosotros podamos armar solución DDR, porque básicamente vamos a estar adivinando estos dos parámetros van a variar mucho, ¿De acuerdo? Básicamente el nivel del negocio, si mi negocio va dedicado al e commerce por ejemplo, o si mi negocio es a lo mejor de manufactura, etc. Vamos a pasar a la parte de los tipos de DRP que se pueden llegar a alcanzar y a configurar o a desplegar. Nosotros los dividimos como cuatro que son de los más básicos a los más avanzados. Primeramente está el tema de Backup and Restore o respaldo y restauración y este, vamos a decirlo así, que este esquema básicamente es como lo comentaba mi compañera Karen, básicamente tener una copia de los datos y tener la posibilidad de restaurarlos en alguna otra ubicación, ya si nosotros tenemos nuestros backups y tenemos manera de restaurarlo, ya estamos hablando de que tenemos un primer esquema DDR muy sencillo, pero ya existe. De igual manera sería primordial que todos aquí entiendo que la mayoría somos ahora sí que responsables de sistemas, entonces nosotros como responsables de sistemas debemos de asegurarnos de la continuidad de nuestras aplicaciones. También para este punto es algo muy importante tener en cuenta la famosa regla o la práctica del tres. Dos minutos. ¿Un que es la primer copia del archivo, una segunda copia que sería tener una copia en físico y una tercera copia que esta tendría que estar fuera de la ubicación de donde yo tengo mi centro de datos o tengo mis datos y la premisa es tenerlo en nube, correcto? El siguiente punto es multisite, Un esquema multisite es un esquema muy avanzado, bastante robusto, porque estamos hablando de tener dos centros de datos operativos en dos ubicaciones diferentes, es decir, si yo tengo mi centro de datos aquí en Guadalajara, pues tener también la posibilidad de, no sé, dentro de la zona metropolitana tener un site alterno, por ejemplo, no sé, Tonalá a lo mejor quizá, y estos centros de datos se tienen que comunicar entre ellos a través de fibra óptica, es decir, la inversión, los que sabemos de infraestructura sabemos que la inversión es por dos, es decir, de un lado tengo que comprar un rack con un switch y mi servidor, pues del otro lado también lo tengo que tener. Entonces en on premise se vuelve bastante complejo poder armar una solución multisite, ya que los costos suelen elevarse muchísimo y como les comentaba, por dos en la nube de AWS es bastante factible o costo eficiente poder tener una solución multiset, ya que podemos manejar cargas de trabajo no al 100% en la nube, sino más bien repartir cargas de trabajo 70 30 60 40, 50 50 y con eso la inversión no es tanta en on premise o nos puede servir para irnos migrando paulatinamente una vez que se nos acabe nuestro arrendamiento o una vez que ya nuestra infraestructura llegó a su tiempo de vida o más bien al límite de su tiempo de vida. Perdón. El esquema Pilot Light habla o asemeja al funcionamiento de un boiler, donde existe una luz o básicamente la llama que tiene el piloto del boiler y en cuanto se tiene o se necesita el agua caliente, el boiler automáticamente enciende esa flama, calienta la hornilla y bueno, tienes agua caliente. Entonces, pilotlight hace una función similar, donde básicamente la flama son los datos, que es básicamente lo que se mueve de manera constante en nuestros sistemas. Recuerden que lo que hay que asegurar primordialmente son la capa de los datos y lo que hace un esquema Pilot es asegurar que los datos se encuentran ya respaldados en la nube y todo el tema de las aplicaciones, mis sistemas, legados, etcétera, se dejan preconfigurados, listos para en dado caso de que exista una contingencia, pues bueno, cambiar DNS, encender estas aplicaciones y mi base de datos o mis datos están actualizados lo más posible. ¿Correcto? Este es digamos a cómo funcionaría un esquema Pilot Lite, un esquema Warm Standby es muy similar al tema de Multisite, a diferenciación de que en este, pues bueno, tenemos ciertas cargas digamos que tibias o en espera, y esto quiere decir que vamos a tener máquinas muy pequeñas ya habilitadas en la nube, en AWS, máquinas muy pequeñas pero ya configuradas que a lo mejor nos van a estar generando un costo mensual, pero que ya nada más es cuestión de que en dado caso de que tengas una contingencia, pues comiences a pasar las cargas de trabajo hacia ese ambiente y en dado caso de que la contingencia sea tal que se requiera mayor capacidad de cómputo, escalar esa capacidad de cómputo y no tienes ningún problema, básicamente ya tienes operando todas tus aplicaciones o hasta tu centro de datos. Muy bien, vamos a pasar cómo funciona o cómo debería funcionar básicamente un Disaster Recovery planning. Aquí en CompuCloud nos gusta dividirlo en cuatro fases, de las cuales digamos que no todas las fases las cubrimos de manera tecnológica, sino que hay que adecuar y el plan debe incluir ciertos procesos que no son únicamente de la parte tecnológica, sino también asegurando en la fase de alerta, por ejemplo, notificar y evaluar los daños que la contingencia pudo haber provocado, en dado caso que haya sido un temblor y ni siquiera podemos entrar al sitio, por ejemplo, etcétera. Simplemente es notificar y ver de qué manera nosotros vamos a podernos desplazar a algún otro lugar a continuar nuestras labores, etc. Y obviamente en la fase de alerta hay que ejecutar el plan y bueno, ya aquí entra el tema de en la fase de transición o la fase 2, ya viene el tema de ver qué se va a hacer con el personal o qué tanto se dañó la estructura del edificio, etcétera, cosas por el estilo. Y ya una vez que nosotros ejecutamos el plan, vamos a proceder a activar nuestro centro de recuperación y en este caso la intención es que sea cloud, es decir, habilitar mis servicios y simplemente validar que todo está funcionando de manera correcta y permitir la conectividad a nuestros usuarios. En el punto de recuperación básicamente son los procedimientos de restauración para llegar a la fase de normalidad, donde hay que validar si se tronó el disco duro y si se tronó el disco duro, pues tengo que mandarlo a pedir, por ejemplo, hablando de un tema on premise o el centro de datos, que tanto hubo el daño, etc. Y tratar de reparar todo ese tema. La fase de normalidad, pues bueno, sería un análisis del impacto que tuvo esto al negocio, lo ideal es que tuviera el mínimo impacto en pérdidas por no producir, porque precisamente ese es el tema del DRP, o sea, de seguir produciendo a pesar de la contingencia, a lo mejor el impacto al negocio serían ya temas a lo mejor de mobiliario o cosas por el estilo, dependiendo la la gravedad de la contingencia. Y por último proceder a volver a la normalidad, es decir, si ya parchamos el disco o ya recuperamos nuestro centro de datos, volver a operar como lo estábamos haciendo de manera cotidiana o algo muy padre que tienen los doctors en la nube, es que prácticamente tú podrías quedarte a operar en la nube sin ningún problema y ya olvidarte de comprar un nuevo servidor, reparar tu centro de datos, etc. Podrías analizar la viabilidad de ese proyecto y básicamente ya estás ahí arriba y no tendrías tantos problemas. Perdón. Muy bien, ¿Cómo se crea un desastre? Recovery Plan básicamente lo dividimos en 7 fases. Cada una de estas fases tiene ciertos aspectos que no son solo tecnológicos, como bien les comentaba, hay algunos que son de políticas, como el caso del punto uno, donde hay que definir como bien les comentaba, el RTO y el RPO. Esto puede ser por aplicación, por servidor o completo del negocio, dependerá de la criticidad de su negocio y de cuánto depende su negocio de sus sistemas. Lo ideal es que pudiéramos hacer esa división por aplicativo. Hay administradores que lo manejan por server, es adecuado también. Digamos que si esa es la manera de trabajar, también se puede analizar. La siguiente etapa es el análisis de impacto al negocio y este es un punto importante. Si aquí hay directivos de organizaciones, este es un punto muy importante porque básicamente a lo mejor como como encargados de sistemas siempre queremos que todo esté protegido, pero a lo mejor Si soy un e Commerce y mi negocio depende 100 % de la venta online, a lo mejor puedo sobrevivir uno, dos, tres días sin correo, no pasa nada, pero mientras mi página no esté caída. Entonces de eso se trata este punto, hay que priorizar y obviamente la intención del Covid planning es poder sobrevivir con lo mínimo y no encarecer una solución. En el tema 3, la identificación de los controles de prevención, pues bueno, aquí es técnicamente todo lo que pudiera causarle un impacto a nuestra infraestructura. Que si tengo que renovar el cooling, que si tengo que poner una planta de energía para que tenga yo backup de energía, si tengo, no sé, mis baterías, tengo doble salida a Internet, por ejemplo, porque si mi página es o si mi servicio es web y reside en mis oficinas y yo solo dependo de un solo proveedor, todo ese tipo de cosas los invitamos a que lo plasmen en ese punto, en la estrategia de recuperación. En el punto 4 es básicamente definir de qué manera nos vamos a recuperar. Es decir, si voy a elegir simplemente tener mis backups y esos backups se los voy a dar a alguien a resguardo y que esa persona se encargue de resguardar esos discos, lo cual digo, no es una práctica correcta, pero si esa es la estrategia de recuperación, de acuerdo, o voy a elegir un sistema o un esquema pilot que me va a poder recuperar en la nube, la estrategia que ustedes deseen va plasmada allí. El punto 5 ya básicamente es una colección de los cuatro puntos anteriores donde ya se define a través de la estrategia de recuperación qué pasos voy a realizar yo para poderme recuperar. Es decir, si básicamente es el backup y no hay más nada más que el backup en un disco, pues bueno, tengo que traer el disco y atacharlo al, básicamente al servidor y toda la estrategia anterior. Pero por ejemplo, si es un esquema pilot, hay que asegurar que las bases de datos estén arriba, encender las máquinas, cambiar DNS, etc. Por el penúltimo punto, tener un plan de prueba y entrenamiento y aquí quiero hacer también mucho énfasis ya que como comentaba igual mi compañera Karen, si tenemos nuestro Disaster Recovery Planning ya hecho y establecido, pues está muy bien, es un best practice, pero qué pasa si no lo probamos, si lo tenemos ahí arrumbado y a lo mejor se da la contingencia, híjole dónde dejé los discos o híjole cuál era mi contraseña, Todo ese tipo de cosas al final del día hacen que no haga sentido tener un desastre Recovery Plan si nosotros realmente no realizamos todo este tipo de pruebas y entrenamientos al personal que va a estar ejecutándolo. Entonces de igual manera la invitación es que se hagan al menos uno al año, de preferencia dos o tres. Y pues por último el plan de material y soporte que básicamente es saber si tienen polis a mis equipos, a quién le Llamo, si tengo un ser 1800 al cual llamar, eso sería perfecto, fabuloso, para que yo no me preocupe, sino más bien le cedo esa responsabilidad a un tercero de que me ejecute mi plan y me pueda habilitar mis sistemas. Muy bien, y bueno, ya entrando un poquito en materia de Las soluciones que CompuCloud está lanzando, el día de hoy manejamos dos soluciones que son integraciones con la nube de AWS, con algunos sistemas que nos van a permitir automatización de los backups y también hasta básicamente generar máquinas completas. Pues bueno, es SAR Pilot Lite y SAR Continuous Backup que pertenecen a la familia de SAR docrp como lo estamos nombrando. Si ustedes conocen o ya son clientes de CompuCloud, bueno, anteriormente tenemos la solución SAR, que es el servicio administrador de respaldos que hace prácticamente la parte de los backups pero a nivel de información. Ahora, estas dos soluciones me gustaría platicarles un poco de qué es lo que hacen y cómo lo hacen y qué ventajas nos pueden llegar a dar. A diferencia de algunas otras, el esquema Pilot Light nos va a servir para poder generar un Doctor o un Disaster Recovery que nos va a permitir subir prácticamente nuestras máquinas hacia la nube de AWS con la posibilidad de desplegarlas con RTOs y RPOs alcanzables y bajos. El RPO que tiene alcanzable Sarpilot Lite es de 12 horas y el RTO es de 3 horas. Entonces si tu RPO y tu RTO te lo permite, SARPILOT Lite puede ser una solución muy costo eficiente para poderte respaldar a nivel tanto de máquinas virtuales como servidores físicos. Para máquinas virtuales trabajamos con vmware y con Hyper V también obviamente te da la posibilidad de habilitar los servidores en la nube y también puedes realizar lo que son las imágenes full o de manera granular de tus máquinas, de tus servidores, no importa si lo tienes en diferentes centros de datos o si los tienes en un solo host, etc. Y bueno también un punto importante que también tocaba mi compañera Karen es el tema del encriptado, que bueno ofrecemos el encriptado más robusto que hay en el mercado que es hasta 256 bits, donde si no existe esa llave no se puede desencriptar de ninguna manera la información. Correcto. Y bueno la parte de SAR Continuous Backup es muy similar a Sarpilot Lite a diferencia de cómo hace el proceso y bueno más adelantito les voy a explicar un poquito de cómo hacen o cómo trabajan ambas herramientas. Y de igual manera básicamente SAR Continuous Backup nos va a permitir igual subir servidores físicos o virtuales a la nube. Solamente hay un tema en el que por ejemplo una restricción que es que máquinas para virtualizadas no las soportamos, pero de ahí en fuera se puede analizar qué tipo de virtualización estás haciendo y ver la factibilidad de si se pueden subir esas máquinas. También Continuous Backup algo muy interesante que tiene es que también nos va a poder permitir el tema de nube a nube que por ejemplo Sarpilot Light no nos va a dar. Continuous Backup sí va a tener la habilidad de podernos generar réplicas de información o backup de información de nube a nube. Esto puede ser de Google Platform hacia AWS, de Azure hacia AWS o AWS AWS, contamos con esa con esa posibilidad. Trabaja de manera diferente a la hora de realizar los backups y es que hace replicación continua y por ello es que nos da estos RPOs y estos RTOs más bajos. Estamos hablando de que con SAR Continuous Backup vamos a poder llegar hasta los 15 minutos en ambos lados, en RTO y en RPO. Esto lo hace una solución bastante robusta en el mercado ya que estamos acercándonos a cero lo más posible y bueno, los que conocen ahí un poco es algo digamos no tan sencillo de lograr. Y bueno también obviamente el tema de la encripción también está habilitado para ustedes. Igual, un punto interesante es que para ambos sistemas, aunque sean un sistema administrado, van ustedes a tener acceso a una consola de AWS completamente suya, la cual ustedes van a poder administrar los recursos adicionalmente a que CompuCloud los pudiera administrar por ustedes, donde se hace toda una configuración previa de de todo el ambiente, hablando de redes, si necesitas un direccionamiento específico, un puerto de conexión específico, todo eso se deja listo, preconfigurado, para que a la hora de que tú tengas una contingencia, simplemente hagas el despliegue de una máquina o de las máquinas que tengas afectadas y continúes la operación lo más pronto o lo más cercano a tus RTOS. Siguiente. Muy bien, ¿Cómo funcionan estas dos herramientas? Pues bueno, básicamente es obtener las imágenes o la data de nuestras máquinas a través de un agente. Aquí hay un tema de diferenciación. Por ejemplo, Continuous Backup necesita un agente por máquina, ya sea virtual o física. No importa si tengo una virtualización a través de un host y ese host, digamos que Continuous Backup, eso no le interesa, más bien es un agente por máquina, a diferencia de Pilot Light. Pilot Light tiene la habilidad de trabajar directamente con el host, y si estás trabajando ya sea con VMware o con Hyper V, tiene la posibilidad de programar las tareas desde el host a todas las máquinas que tú decidas, de los discos que tú decidas. Entonces, a través del agente se sube la información hacia AWS que queda en descanso y posteriormente se puede llegar a ejecutar, dado que se tenga la contingencia, se ejecuta, se habilitan las máquinas y tú puedes acceder nuevamente desde el punto original a esa información. Correcto, Esa es, digamos, la manera más o menos lógica en la cual funcionan ambas tecnologías. Si ustedes tuvieran igual una duda muy específica sobre el funcionamiento de cada uno, o una duda también muy puntual sobre el funcionamiento de cada una, pues lo podríamos tocar o podríamos resolver las preguntas que ustedes tuvieran. Hay temas como toda herramienta, hay temas en los cuales tiene algunas restricciones, como por ejemplo las máquinas que son para virtualizadas, que no se soportan y también el tipo de booteo UEFI no está soportado. Digamos que esto no es por la herramienta, sino más bien es por AWS que es el proveedor, y una máquina en AWS no arranca si tiene, por ejemplo, UEFI. Muy bien, los beneficios que nos va a dar SARDRP en ambas versiones, Pilot Light y Continuous Backup, pues bueno, básicamente son el tema de que vas a pagar por lo que usas, ya que usamos todas las bondades de AWS, entonces nos estamos colgando de ahí para poderles ofrecer el Pay as you go, es decir, que solamente vas a pagar por la información que está subiendo y por las contingencias que tú estés de cierta manera soportando allá arriba. Acceso desde cualquier lugar. Esto también es muy importante, ya que si no puedes acceder a tu Doctor desde cualquier punto, pues bueno, básicamente no tienes un doctor, Yo lo veo así. Y bueno, esto se da a través de ciertas cuestiones, a través puede ser de alguna conexión VPN client to site, por ejemplo, punto, multipunto, etcétera. El tema de los respaldos automatizados, todas las tareas pueden quedar automatizadas, hablando de los backups, para que no estés con la preocupación de, ah, ¿Ya se hizo el respaldo o no? También tienen ciertos temas de notificaciones para que te enteres de cómo está el status. Perdón. El punto también muy importante a la hora de que estamos arquitectando en Cloud Computing y también que tenemos un Doctor En la nube con AWS, es muy sencillo el tema de implementación. Estamos hablando de que podemos habilitar un Doctor Bastante robusto, complejo, en una semana, yo creo en una semana ya tienes tiempo de entrega de tu doctor en AWS con nosotros. Nos da el tema de escalabilidad y flexibilidad, ya que a través de los ejercicios de recuperación, de los ejercicios que hacemos y que ya vienen dentro del servicio, muchas veces hacemos estos ejercicios y sucede que a lo mejor la infraestructura del cliente ya cambió, ya tiene menos servidores o ya tiene más servidores y De repente nos ¿Sabes qué? ¿Puedo agregar este nuevo server? Claro que lo puedes agregar. Oye, ¿Y qué pasa si mejor quito este? OK, lo quitamos. Y también a través de en los ejercicios de recuperación, el mismo cliente se puede dar cuenta de que oye, ¿Sabes qué? La verdad es que no subí la base de datos de mi servidor aquel. Ah, OK, pues si gustas lo podemos incluir dentro del plan. Y esa flexibilidad y escalabilidad, digamos que propia de AWS, nosotros se las trasladamos a este tipo de soluciones. Control de accesos. También es muy importante tener controlado el acceso, si recuerdan a hora de generar el plan hay que definir ciertas políticas y dentro de las políticas es muy importante tener controles de acceso que también lo vamos a poder alcanzar desde estas soluciones y el tema de seguridad, como bien les comentaba ambos trabajan a través de SCL, encripción 256 bits. Por mi parte sería todo respecto a ambas soluciones, le cedo la palabra a mi compañera Karen y bueno si tuvieran alguna duda técnica sobre sistemas operativos soportados, sobre factibilidad de algún proyecto, con gusto si nos dejan su contacto, su número o si nos ponen directamente la pregunta aquí con gusto en la sesión de preguntas las contestamos.

Bien, pues ya para ir finalizando con esta sesión muchas gracias a Obed por por la introducción en lo que es ARDRP y SAR Continuous Backup. Por último les traemos estas promociones de lanzamiento que tenemos, tenemos tres diferentes opciones que van a durar desde el día de hoy hasta el 31 de julio y pues la primera es el 7% de descuento en la implementación, la segunda opción son dos mensualidades sin costo y una tercera última que tenemos son llegaba este almacenamiento gratuito durante los primeros tres meses sin costo, esto haciendo una contratación anual con un contrato y aplica solamente para nuevos proyectos y también tenemos otra promoción que es más corta, dura del 22 de mayo al 7 de junio del 2019 que es el 7% de descuento en la implementación más una mensualidad totalmente gratuita que también aplica con una contratación anual y también para proyectos nuevos. Igual tal como lo comentaba mi compañero Obed, vamos a abrir un espacio para preguntas, si tienen alguna pregunta por favor ponerla por el chat para poder contestarla y poder resolverla en este momento y también si gustan una atención ya más personalizada, hacer un enfoque ya directo en lo que es su administración y cuál de los dos que estamos promocionando se adecua mejor a sus necesidades, nos pueden dejar su nombre completo, su número telefónico y su correo para nosotros poder ponerlos en contacto. Entonces vamos a dar un par de minutitos para que puedan poner sus preguntas y Luis Alberto nos pregunta que si se puede ver alguna demo. Sí, sí tenemos una demo, tenemos de hecho un vídeo muy corto con explicación de cómo es que funciona el servicio o en caso de que lo desees podemos agendar una cita y hacerte una demo en tiempo. Luis, pues si gustas dejarme tu correo electrónico y tu teléfono y yo terminando la sesión me pongo en contacto contigo para empatar agendas con la tuya y con la de nuestro ingeniero y poder hacerle la presentación del sistema. Igual les vuelvo a comentar que esta sesión fue grabada y se les hará llegar mediante correo electrónico para que tengan la información y también junto con nuestros datos tanto míos como del ingeniero para que se puedan poner en contacto también con nosotros y en algún momento en específico lo requieren. El Ingeniero Miguel nos pregunta si hemos realizado proyecto con Microsip, Bueno, en ese.

Caso no hemos tenido algún proyecto directamente con Microsip, pero sí hemos subido algunos sistemas contables, entiendo que este es un sistema contable, digamos que las aplicaciones funcionan a nivel servidor, entonces igual podríamos generar o agendar el tema de una prueba de concepto, quizá igual Ingeniero Miguel si nos deja sus datos lo podríamos contactar para ver puntualmente ese tema.

Gerardo, el costo puede ser mensual o puede ser anual la póliza, nosotros ya tenemos una póliza dentro del paquete, ya sería gratuita totalmente porque lleva dentro de él, tendrían en este ticket ilimitado, les damos una licencia Zendesk para que se puedan comunicar con nosotros, levanten sus reportes y también manejamos reportes proactivos para que ustedes vean cómo es que que va su almacenamiento, sus licencias si es que se llegan a tener algún problema y además dentro del año manejamos dos trills para que puedan ver que su servicio de respaldo está funcionando tal como debería.

Omar, más detalle respecto a Continuous Backup. Claro que sí, digamos que podríamos agendar de igual manera una llamada para poderles proporcionar los detalles o a tu correo igual poderte hacer llegar cierta información. ¿Víctor nos comenta que si SAR está basado en alguna solución conocida de respaldos o es desarrollo propio? Es una integración propia de CompuCloud. Mi estimado, con NOI si tenemos algunos proyectos propiamente digamos no precisamente de Desastre Recovery, más bien ya tenemos sistemas completos habilitados en la nube trabajando directamente, entonces por ese punto no debe haber ninguna restricción a la hora de poder generar una imagen y subirla con el sistema contable con NOI por ejemplo hacia la nube de AWS, entonces funcionaría de la misma manera.

Claro que sí Gerardo, nosotros nos ponemos en contacto contigo y te mandamos más información respecto al backup, de igual manera.

Les ponemos de nuevo los contactos de mis compañeros Karen Delgado y Obed Gutiérrez, quienes dieron este webinar para cualquier información puntual que quieran de estas soluciones, algunas otras soluciones que nosotros manejamos, con todo gusto a través de ellos podemos proporcionarles más información. Y pues con esto damos por terminado este webinar. Esperamos que haya sido para todos ustedes información valiosa y cualquier tema o información adicional que requieran, pues están nuestros datos. Agradecemos muchísimo su tiempo y les repito, haremos llegar un correo donde estará la liga del webinar del día de hoy, más la presentación que tuvimos el día de hoy.

¿Y bueno, Víctor nos comenta que si SAR está basado en alguna solución conocida de respaldos o es desarrollo propio? Es una integración propia de CompuCloud, mi estimado, con NOI sí tenemos algunos proyectos propiamente, digamos, no precisamente de Desastre Recovery, más bien ya tenemos sistemas completos habilitados en la nube, trabajando directamente. Entonces, por ese punto no debe haber ninguna restricción a la hora de poder generar una imagen y subirla con el sistema contable con NOI, por ejemplo, hacia la nube de AWS. ¿Entonces, funcionaría de la misma manera?

Claro que sí, Gerardo, nosotros nos ponemos en contacto contigo y te mandamos más información con respecto al backup.

De igual manera les ponemos de nuevo los contactos de mis compañeros Karen Delgado y Obed Gutiérrez, quienes dieron este webinar para cualquier información puntual que quieran de estas soluciones, algunas otras soluciones que nosotros manejamos, con todo gusto a través de ellos podemos proporcionarles más información. Y pues con esto damos por terminado este webinar. Esperamos que haya sido para todos ustedes información valiosa y cualquier tema o información adicional que requieran, pues están nuestros datos. Agradecemos muchísimo su tiempo y les repito, haremos llegar un correo donde estará la liga del webinar del día de hoy, más la presentación que tuvimos el día de hoy.