Bases de Datos - AYUDA IMPLEMENTACION BD PARA QUE NO FALLE SERVIDOR

Hola gente de la comunidad, estoy un poco desorientado y
agreadeceria muchisimo si alguien me pudiera orientar
un poco sobre una cuestion que luego de pensar mucho todavia
no encuentro una solucion clara a una cuestion que se me presenta
sobre que base de datos o motor de base de datos implementar y consta
de lo siguiente:

1. Necesito desarrollar un sistema de gestion de Backoffice con
puntos de venta de facturacion en red.
(Es decir, una pc Backoffice desde la cual cargar la informacion
administrativa, cambio de precios, facturas de compras, etc y otras PCs
que solo tendran un sistema de facturacion que tiene que usar los
datos de los articulos, clientes, medios de cobro, etc que se administran
desde la PC backoffice, y que posteriormente al cierre de cada jornada
las estadisticas de ventas debera copiarlas a la base de datos del backoffice).

2. La solucion clasica seria un motor de BD tipo mysql, o SQLserver como cliente servidor.
DESDE YA QUE NO PUEDO HACER ESTO, porque:
En el caso que se queme el router, se rompa la pc Servidor, o cualquier otro motivo que
deje fuera de servicio al server, automaticamente SE CAEN todas las PCs de facturacion
ya que no se comunicaran mas con la base de datos y ahi si que ME ESTRANGULAN.

3. Por lo expuesto anteriormente, cual seria la forma mas optima por la cual enviar y
recibir informacion desde y hacia el backoffice y los puntos de ventas para que
si se cae el servidor, los puntos de venta puedan seguir trabajando con una copia de
datos que sea local hasta que se reestablezca la conexion con el server que puede
ser una cuestion de minutos, horas o dias...

En este caso hay algun metodo, o paquete que solucione esta cuestion? Eso es lo que mas me esta volviendo loco y les agradeceria muchisimo si me pudieran orientar un poco.

Saludos y gracias por tomarse el trabajo de leer esto....

Marcelo.

Siempre existe el riesgo que el equipo electrónico falle, que falle un router, un switch, un cable, una tarjeta de red del servidor o el servidor mismo son situaciones que se pueden (y van a ) dar, por ende tenemos que pensar muy bien nuestra estrategia de recuperación ante desastres.

Primero que todo, si su negocio es tan critico, deben pensar en respaldos cada media hora (la frecuencia depende de lo critico que sea para el negocio, pero recuerde que hacer respaldos incrementa el uso de CPU del servidor, por ende disminuye el rendimiento), un cluster de alta disponibilidad, tener switches y routers redundantes, manejar replicación a nivel de base de datos a un servidor ubicado al menos a 50 000 Km del servidor principal, guardar los datos en una SAN que maneje arreglos de discos RAID (para minimizar el riesgo que se queme un disco duro), tener generadores de diesel en caso que se vaya la corriente, UPSs que aguanten un par de horas (si las hay), para que el servidor no se apague mientras alguien arranca el generador a diesel, dos enlaces de salida a internet, lo mejor con diferentes proveedores (para minimizar le riesgo que un proveedor tenga problemas de red en un momento dado) y así podríamos seguir incrementando la lista de cosas que se pueden poner.... y tambien el costo.

Lastimosamente, no hay nada que el software pueda hacer para evitar un fallo de hardware, de hecho, un fallo en el hardware es comparable a cuando se daña el coche, ya que solo cambiando partes puedes volver a hacerlo andar.

Todas las opciones que puse anteriormente son utilizadas en entornos empresariales actualmente, mas no son implementadas absolutamente todas (salvo que sean empresas enormes o sean bancos o afines), ya que generalmente implementando cuatro o cinco de esas los riesgos son tan mínimos (o los costos tan altos) que no es necesario (o conveniente) seguir implementando mas mecanismos.

En lo que respecta a recuperación de desastres, no existen formulas establecidas, por ende tienes que valorar mediante costo/beneficio que opciones te es util implementar, ya que, por ejemplo, un segundo servidor para manejar un cluster de alta disponibilidad va a ser mas caro que el primero, ya que el segundo debe ser un servidor con las mismas prestaciones que el primero, con la desventaja que puede que nunca sea necesario usarlo (por lo que ocuparías tener una contraparte financiera igual de paranóica para que aprueben esa compra, despues todo el equipo redundante va a hacer que los contadores o administradores se quejen, por ende tienes que tomar las opciones que mejor te cubran en caso de emergencia y que sean mas fáciles de justificar.

A pesar que yo siempre he apoyado ampliamente el open source, pero, si la persona que pueda tener que llevar a cabo la estrategia de recuperación es muy novata, lo mejor será usar SQL Server; así se minimiza el riesgo que la persona encargada de ejecutar el pla de recuperación no pueda hacerlo por ser las herramientas muy complejas.

En sintesis, sobre recuperación ante desastres no hay nada escrito, hay practicas comunes ante riesgos probables, pero debes elegir bien cuales implementas en tu empresa, ya que, entre mejor es la solución, mas costosa resulta, por ende tienes que ver de cuanto dinero dispones antes de elegir las opciones (o la opcion, si no hay mucho dinero), ya que los contadores generalmente no son felices cuando uno propone una multi millonaria estrategia "contra supuestos".