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.)

La semana pasada estuvo a punto de pasar una desgracia en el trabajo, pero mi forma de respaldos funcionó.

Acabo de enviar este correo a varias personas relacionadas con el evento:

========================================================================

En vista de los acontecimientos de la semana pasada, creo que no podemos retrasar mas lo de hacer unas pruebas en frio de respaldos.

El proceso de copia de respaldos es mucho mas efectivo si el sitio y su base de datos está suspendido / detenido, para asegurar integridad de la base de datos. Por lo mismo, creo que una prueba de respaldos con el servidor detenido es lo mejor que puede hacerse, Queda evidente que los clientes probablemente no podrían accesarar antes de las 11 de la mañana ese día, y como hablamos antes este viernes sería ideal.

Este sería el proceso:

1 ) Me levanto a las 3 de la mañana , detengo el servidor y empiezo a sacar respaldo, en el servidor alterno, de dos formas:

a ) local en ese server
b ) replicado en tar.gz

2 ) El respaldo replicado termina entre 3 y 4 horas después, porque el proceso necesita primero comprimir y despues copiar unos 8 gb de información

3 ) Aproximadamente a las 8 de la mañana , levanto el respaldo replicado para que ABG, SAEM, AG y XFBP puedan revisar que esta completo, y haciendo las pruebas que quieran MENOS las referentes a redireccionamiento de puertos ( que ese server no tiene )

4 ) Saco un respaldo local empezando a las 8 de la mañana, que debe durar aproximadamente 3 horas.

5 ) A las 11 de la mañana verifico que el servidor esté respaldado en local, y una vez que vea que el respaldo es integro, (10 minutos maximo) se abre el server para los clientes.

========================================
Notas:
1 ) Quedaría pendiente descargar el respaldo local en frío, cosa que yo puedo hacer el viernes en la noche en mi casa.

2 ) Como empezaría a trabajar en esto a las 3 de la mañana, no me presentaría en las oficinas ese día

3 ) Este respaldo tiene demasiados archivos para hacerse por FTP o por rsync, y es independiente de que la UTILIDAD mayor de este respaldo es con server detenido, no el método en sí.

Hace un rato confirmé uno de mis temores. Básicamente el problema es la cantidad de trabajo realizada lo que quieren impedir.

No puedo dar mas detalles por razones obvias, pero la primera medida es empezar a documentar lo que esta pasando desde respaldos hasta falta de imagen corporativa en los documentos independientes.

Afortunadamente el estilo de trabajo que me resulta mejor, me resulta asignado desde mañana.

Varios de los sistemas que he desarrollado se autentifican por CURL contra passport de microsoft.

Una de las dos claves que uso, no relacionadas con hotmail, no funciona. Probablemente desactivada por no entrar al messenger en esa cuenta. La otra lo usa incidentalmente cuando skype falla. Y son dos dominios desconocidos.

Interesante.

Sea l oque sea no usare la autentificacion por “passport de facebook” jamas.

Como no tiene el asunto para cuando, tomé la decisión drástica de enviar este correo, para preparar el alto.

Asunto :Que respaldos estaran disponibles de servidor de la empresa

Me puse de acuerdo con Alejandro y G para sacar respaldos del servidor de ******* ******, por el metodo de cpanel, y esto es lo que se hará a partir del 15 de agosto.

Puntos importantes:
* Sacaré respaldo diario del servidor ******* ****** a uno de mis servidores propios
* y estarán disponibles online 5 versiones correspondientes a la semana anterior (lunes martes miercoles jueves viernes ), incluyendo base de datos.
* Conservaré respaldos diarios en mi pc de los ultimos 15 dias naturales
* Se guardará además el respaldo del dia 15 y ultimo de cada mes
* por fines de control, se eliminarán el 31 de agosto de este año la mayor parte de los respaldos anteriores al 15 de agosto del presente.

Saque un respaldo de ayer a hoy en mi casa, metodo normal de cpanel , mide 3.5 gb Tengo dos conexiones, en una se tarda 7.5 horas y en otra 2 horas

Lo copie a mi servidor personal mediante copia directa via ftp, se tarda UNA HORA Y MEDIA EN GENERARLO, y en subirlo poco menos de una hora, el archivo subido de restore cpanel fue de 2 gb, porque desaparece el contenido de tmp del respaldo en ese tipo de copia.

Me resulta evidente que esa es la unica manera posiblle de sacar respaldos que incluyan en un solo paso una cifra de verificacion (creo que es md5), pero ese archivo final, copiado a otro servidor y despues restaurado para la prueba en frio, es el que debe quemarse regularmente o guardarse en los hipoteticos usb.

Notas :

1 ) Tenemos demasiados archivos. Que pasa si creamos una base de datos nueva llamada “boveda” y adapto un script que tengo para que guarde el archivo que definamos a esa boveda, despues de cierto tiempo. Si Redirigimos el error 404 a boveda.php y ese devuelve el archivo descargando de la boveda, no hay que alterarar la programación y es mucho mas rapido de respaldar o verificar una base de datos con blob, que pinche mil archivitos.

2 ) no esta documentado de que es cada directorio ni cada base de datos, se lo que habìa a Octubre del año pasado.

Recomendaciones:

1 ) Ver que hacemos para disminuir el uso de disco duro (¿maquina virtual o algo asi para descarga en otro sitio que no respaldemos?)
2 ) compra de software getright ( http://getright.com/ 19.95 usd y es mas barato) para poder descargar en parcialidades el archivo de 2 gb con nuestra eficaz conexión de internet. WINSCP no le tengo confianza y por lo menos en un caso me ha bajado archivos corruptos por el tamaño.

LLevo unas dias teniendo problemas al sacar respaldos del sitio del corporativo donde trabajo. Cuando lo saco desde mi casa, sale bien pero desde el trabajo no. Ya probe con diferentes passwords , ips, laptops, pero es igual. Creo que hay un caso de MITM o de paquetes perdidos por errores de configuración de Linksys, o por exceso de puertas de enlace. Algunos sitios tardan bastante en responder.

Por si las dudas, deberé cambiar todas mis passwords de acceso a servidores, ya que utilizo a veces para hacer pruebas esta conexión.

Las implicaciones básicas serán escribir en la noche, no de día. Probablemente también deba migrar algunos sitios extras al cluster lobonegro.