Estos son dos correos que mande el 1 de febrero, mas de seguimiento a los respaldos. Aviso que edito el nombre de las soluciones (A) y (B), y que el sistema de tickets es un software propietario, que no hice yo, y del que dije en junio del año pasado que consume muchísima memoria.
El usuario root2 no se llama así pero el problema es real.
Por mail masivos son notificaciones, cientos al día, a clientes de nuestro SAAS.
=========================================================
El respaldo de la base de datos, en condiciones óptimas, se tarda poco mas de 5 horas y media con una conexión amplia. Debemos pasar parte de su material a otra base de datos, otro dominio, y otro server porque el riesgo va creciendo, sumandolo al consumo de memoria reportado anteriormente.
Si de mi dependiera:
a ) manejaría un servidor extra para hacer las pruebas de respaldos en frio.
b ) Pasaria el sistema de tickets a otro dominio (¿ el mx?) en el servidor de la empresa C. Este server no puede manejar ftps mas ssh de root2 mas usuarios de ticktes mas mail masivos.
c ) Crecería el servidor actual. Estamos llamando al desastre.
Me parece prioritario el hacer un plan de continuidad de negocio o un simulacro. Se necesita mas material a nivel de socios, porque no podemos arreglar con curitas un problema que sigue creciendo de manera exponencial. Esto incluye los planes de respaldo que hice en el 2010, no solo de abuelo hijo nieto, sino de respaldos externos en las oficinas de
la empresa B o casa de uno de los socios, que evidentemente ya no caben en un usb, ni siquiera la base de datos compactada.
================================================
Aunque subimos de tamaño el servidor a un plan mayor, no fue la solución que sugerí que cuesta * USD mensuales.
Por el uso de tickets y las sesiones de ftp estamos manejando un load de 13, 16, 15, variable en diversos momentos del día. Tenemos los siguientes síntomas de problemas:
1 ) Nuestro tráfico de ftp son 300-3000 gb mensuales. Eso no creo que lo soporte el server pedido por fuera de XX mil al mes.
2 ) La memoria actual de giga y medio se está viendo saturada ya , principalmente por dos factores que comento mas adelante. Esto causa lentitud en la salida, que nos lleva a que fabiola o yo no podamos a veces abrir siquiera la base de datos en phpmyadmin, o ni siquiera entrar a cpanel.
3 ) Tenemos un mensaje por hora de uso excesivo de recursos por el usuario root2, que por lo que se es el que se conectan desde las maquinas virtuales. Pueden consultar los correos al respecto en la cuenta de correo del server +++++++++++++ en el servidor ************, la ultima vez que vi eran miles de mensajes.
Por la proyección de uso de memoria y el tamaño actual de nuestro server, , solamente podemos seguir con l esquema actual de memoria para subir un 15% de memoria por **+ usd mas, lo cual significa que si tenemos mas personas revisando tickets, o mas usuarios ftp, simplemente el servidor va a tronar como ejote. No puedo decir que, pero si que 15% es nuesa opción de crecimiento si no consideramos tickets.
La alternativa es la opción B que nos da un margen de aproximadamente 40%, no son datos duros.
Los dos principales consumos actuales de memoria son el usuario root2, y el sistema de tickets.
En cuanto a los espaldos, como mencioné en noviembre del 2010 y en varias oportunidades en medio, necesitamos hacer una prueba de respaldos en frio, y sacar respaldos de una manera mas normal.
Corolarios:
1 ) No podemos sacar respaldos de servidor a servidor por el usuo de memoria y cpu, y nuestro server ya esta justo de espacio para un respaldo, incluso despues de borrados los temporales.
2 ) No es posible implementar sistemas nuevos en este servidor, porque tiramos el cpu. No pueden evaluarse de manera correcta funcionalidades de software en elserver, estando el server en las condiciones de uso en que está por el uso de cpu y ftps diversos.
========================================
Como dato idiota, uno de los destinatarios se enojó pero nadie ha hecho nada. Estamos llamando al desastre. (y ayer vi algo peor pero en software, luego comento.)