R1Soft, backup y/o mirror

[Eduardo Mena]

Gracias Aldrin por tu respuesta.

Para la solucion de las aplicaciones me parece bien si existe un solo
servidor. En mi caso son tres servidores y no puedo tener 3 otras maquinas
en espera.

Para el caso 2, cual respaldo en linea tu recomendarias ?

Gracias una vez mas.

Eduardo

2011/6/8 Aldrin Martoq <amartoq en dcc.uchile.cl>

>
> On Jun 6, 2011, at 5:47 PM, Ricardo Munoz wrote:
> > El 6 de junio de 2011 16:02, Eduardo Mena <lemena en gmail.com> escribió:
> >> Gracias Carlos  por tu respuesta.
> >> Mi preocupacion principal es si el S.O y disco duro con todas sus
> >> particiones se danhan.
> >> Mi idea es tener un plan de contingencia para que todo vuelva a la
> >> normalidad inmediatamente.
> >> Yo uso MySQL, pero no tendria problema con la base de datos.
> > creo que MySQL Cluster es tu unica opcion.
>
> Hacer el respaldo al estilo "rsync" no es óptimo, y como dice Victor un
> condoro en el servidor principal se replica en el servidor standby.
>
> Lo importante no es respaldar el tarro completo bit a bit con particiones,
> sistema operativo y todo. Lo que debes respaldar es:
> 1- las aplicaciones
> 2- los datos
>
> Para el 1, arma servidores de espera que tengan el mismo software que el
> original y los dejas al agüaite. Ojo que debes validar con cierta frecuencia
> que el respaldo completo funciona acá.
>
> Si realmente necesitas disponibilidad 99.9999999999% como indicas, tienes
> que usar alguna solución del estilo cluster tanto en la base de datos como
> en las aplicaciones. Esto te garantiza que si hay una falla de red/hardware
> o incluso software, otro tarro que no esté enfermo pueda atender clientes.
> Hay sistemas que automatizan todo esto, lo malo es que es MUY complicado de
> lograr bien y usualmente requieres ayuda del código de la aplicación para
> que funcione de maravillas (o al contrario, una aplicación no
> preparada/pensada para funcionar en un cluster es un dolor de cabeza).
> Muchas veces uno no necesita esto o no tiene la capacidad para lograrlo.
>
>
> Para el 2, lo que te recomienda es utilizar un respaldo "en línea" basado
> en los registros o deltas que se hacen en la base de datos. Esto es: cada
> vez que hay un INSERT, UPDATE o DELETE en la base de datos, esta información
> viaja casi inmediatamente a un servidor remoto que ejecuta la misma
> sentencia al otro lado. Esto te garantiza no solo que tienes la base de
> datos casi en línea en un servidor remoto, sino que además puedes guardar el
> historial de cambios y moverte en cualquier punto (por ejemplo, puedes
> deshacer un DELETE). Si la data es importante (casi siempre lo es!) deberías
> conseguir que dicho server esté en otro datacenter a varios Km del servidor
> principal.
>
>
> Cada base de datos tiene su terminología/nombre_vendedor para esto, por
> ejemplo en oracle creo se llama DataGuard. Bueno, con replication en la base
> de datos y servidores de espera es mucho más fácil levantarse de una caída
> fea, yo prefiero esta ruta.
>
>
>
> Aldrin Martoq
> http://aldrin.martoq.cl/
>
>
>
>
>
>