Correo a la unidad que usa el server dedicado con problema de los respaldos

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.

Problemas de respaldos en el trabajo

Hoy tuvimos un problema con los respaldos, mismos que son mi responsabilidad asumida voluntariamente. Se solucionó pero mandé este correo (alteré algunos datos basicos pero este es el problema):

Resumen Breve:

Solo para informar que me pidió David un respaldo de la base de datos del 26 de julio, (para ver algo de pq) y aunque tengo el archivo, no se puede abrir con windows ( ruta demasiado larga dentro ) y probablemente si desde linux. No es importante y ya fue solucionado por David contactando al cliente para ver lo del registro, pero quiero sugerir, de la manera mas enfática, que contratemos otro servidor dedicado para poder hacer pruebas en frio para verificar que tenemos respaldos y no ilusiones, normalmente estoy pasando el respaldo total al disco duro de mi casa, y a uno de mis servidores, mas el que ocasionalmente descargo aqui, pero probar un respaldo de 3.5 gb de tamaño resulta muy complicado y tampoco tenemos la garantia que el respaldo del sistema funcione y que sea suficiente para levantar en otro server( tendriamos que recrear los ajustes de puertos abiertos, etc)

Consideraciones:

a ) En una empresa como la de nosotros, enfocada a información sensible, los respaldos deben realizarse regularmente (cosa que hacemos) y probarse regularmente (no lo hacemos) además de amacenamiento externo (en este caso el nuevo server)

b ) (confidencial)

c ) No tenemos la estructura montada alrededor de continuidad de la empresa si nos cae un rayo a los que conocemos el «know how» o los datos de pago. Creo que es importante, por continuidad de la empresa y detectar nuestros puntos débiles, hacer un plan de continuidad de negocio.

Detalle:

Aunque hemos hablado de un script para automatizar respaldos (del que voy a medias), no es aconsejable automatizar la verificación del respaldo, sino probarlo ocasionalmente para ver que tenemos mas que aire.

Yo asumo que el supuesto error del archivo se puede deber a que nos desconectamos de la red a mitad de su descarga, o a que tenemos directorios con mas de 2 mil archivos.

Lo que haré ADICIONAL a partir de HOY es respaldar la base de datos principal de manera manual y adicional a lo actual, y revisarla manualmente. Estoy respaldando de un modo lento, pero que funciona de manera segura y que me permite verifcar manualmente al terminar, aunque la conexion me hace reiniciarlo. El respaldo de esa base de datos hoy no puede sacarse en formato zip normal, o en horas normales de oficinas, porque mide mas de 1.2 gb pero por lo menos no cabe ya en un cd, y eso es la base de datos PRINCIPAL, de manera independiente al contenido del sitio, y a las bases de datos secundarias. Van cinco veces seguidas que se cae el internet a mitad de la descarga, por lo que no me fue posible descargarla manualmente.

Esto evidentemente me ha obligado a ir borrando varios de los respaldos anteriores, por limitaciones de espacio del disco duro de mi portatil que uso aquí, y de la computadora de escritorio de mi casa.

Que recomiendo:

1 ) contratar otro servidor dedicado para pruebas en frio y almacenar respaldos.

2 ) por lo menos quincenalmente verificar que un respaldo completo levante en frio.

Que voy a hacer:

1 ) Verificar a partir de hoy los respaldos de base de datos manualmente.
2 ) Hacer bitácora de respaldos existentes, describiendo si son aire o probados, incluyendo fecha programada para su borrado.
3 ) proseguir con el script de respaldos del servidor automatizado (no se puede respaldar por ftp por exceso de archivos, debe ser via tar)

SIstemas de pago

Llevo unas semanas batallando con sistemas de autentificacion de clientes JSON. Hoy mismo encontré el problema que cambió de proveedor de proceso de tarjeta de credito el datacenter al que rento este servidor, y ese nuevo proveedor bloqueó el pago del server porque le pareció raro que una tarjeta de crédito internacional de México pague servidores en ese país.

Asunto arreglado.

No es la primera vez que me pasa: Cada vez que estados unidos tiene un problema en su calificación de credito, parece que los proveedores de pago directo con tarjeta se ponen sus moños.

Es mejor Paypal.

Post, get y request

Una de las señales para mi, de que alguien no tiene experiencia programando con php, es el uso de request de manera indiscriminada.

El día de hoy, depurando un script del colegio, como parte del jquery que no me autorizan a rehacer, confirmé que el jquery pasa los datos via get, los lee un request (¿?) y finalmente hace la inserción en las doce tablas que pudieron ser una.

Ahora estamos teniendo un problema en la pc del socio técnico. En mis laptops y las del cliente funciona bien, pero parece que el problema debe ser de el largo de los gets que recibe por jquery, ya que el limite que yo recuerde no esta establecido por RFC (request for comments)o es muy bajo (1024), pero juraría que son casi 2048, y sus versiones optimizadas de firefox para linux deben tener el problema.

Basicamente asumo que como firefox tiene binarios diferentes en linux y en windows, es probable que la version linux si le haga caso a esos estandares, que el diseñador original no contempló y mucho menos el «programador» original.

Nota Aclaratoria 2013:

En respuesta a un correo que me mandó una persona el 22 marzo 2013, hago notar que , por lo menos según yahoo, lo que deben usarse son GETS y no REQUEST. Por principio de cuentas los POST son para poner información, pero llamadas a OBTENER información por default deben ser GET. Sin embargo, usar POST tiene sentido cuando no quieres que aparezcan parámetros en el log de navegación. Por ejemplo el sistema administraor de base de datos de un archivo usa adminer.php usa GETS lo cual es malo porque se guardan los passwords en el log de apache en texo plano.

El punto fino aqui es, que si pasas un get (parámetro en el URL), no vas a leerlo usando un request, es ilógico, tiene problemas de seguridad y claridad de código, se presta a exploits (parameter pollution donde un atacante puede sobreescribir parámetros GET con POST o cookie), y por lo general se usa para tratar igual POST que GETS, lo cual desde el punto de vista de programación WEB es absurdo en tiempos de SQL injection. No importa como lo pases, no lo pasas con un request, y si sabiendo que lo pusiste como POST/GET lo lees como request, habla de malos estándares.

Esperando a ventas

Esta semana me la pasé haciendo cambios a un verificador, y adaptando un sistema hecho para ORACLE para cumplir los requermientos supuestos del RVM.

Se supone que en quince minutos debo entregar una información que se supone no puedo tener yo. De entrada a eso de las doce me pidieron que les tradujera que quería decir un requerimiento técnico de una dependencia federal. Lo leí y les dije es esto y esto, pero tal y tal información me la tiene que dar ventas para que yo ASIGNE quien es el responsable.

Basicamente es un flujo de información y documentación recibida de los clientes de lo que yo no tengo ni idea, para definir quien es el responsable de la custodia de la información del cliente , y evaluar su grado de riesgo.

En quince minutos no lo tengo, ya lo pedí tres veces aunque el compromiso era que me lo dieran hace una hora.

Por cierto que le pusieron un titulo de «gerente» al vendedor que era primo del socio tecnico, pero pro el momento hasta que no se tenga la nueva certificación federal, no vamos a vender nada seguramente.

Doce mil correos rebotados… y analizados… y algo fascinante

El Pasado Jueves vi que tres personas que ayudan al socio tecnico le estaban ayudando a analizar una serie de 12000 correos rebotados uno por uno, por parte del colegio de profesionistas. Le sugeri hacer un programa pero me dijeron que no.

Unas horas despues me dijeron que si, asi que hice un sistem que analizo el buzon imap para detectar porque eran rebotados los correos. Es impresionante lo IDIOTAS que pueden ser profesionistas. Correo como hayoo.com en lugar de yahoo, dominios imposibles (hotmail.es.mx) etc.

Hice el analisis y resolvi el problema, 11 mil el viernes y 1000 en la mañana, entregando una hoja de excel explicando renglon por correo, cuenta de correo rebotada, porqué , y tipo de bounces(hard, soft, etc). Sin embargo, me sorprender que sigan personas utilizando latinmail. Sería lo mismo que starmedia a estas alturas.

Despues nos quedamos sin internet ni luz por varias horas. Empezando mi trabajo normal de repente, me encontré un link fascinante sobre stuxnet (virus / malware especificado para dañar PLCs)

Es uno de los mejores textos de carácter técnico que he leído en mi vida:
http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1

El archivo de texto de mega y medio

Hoy me puse a ver uno de los dos ejemplos que me enviaron para preparar lo de rvm, son dos archivos de texto que se supone van a alimentar el sistema con datos de ejemplo.

Uno de los dos archivos es de mega y medio y se ve normal al abrirlo, excepto que es una sola linea de texto.

Parsear o que ?

Es cierto que un mega y medio de texto no es demasiado, pero es estupido que lo pongan en una sola linea de texto, seguramente no es un layout ni algo ortodoxo. Puedo hacer explodes en php para tratar de encontrar que es, pero lo extraño es que no hay herramientas obvias para saber que hicieron o que representa que fragmento de información… que son en su mayoría espacios en blanco (943 registros de 1681 bytes aprox en una linea todos).

Y hay gente a las que les pagan por eso.

Derivados del ftp

He notado que el servidor del trabajo desconecta a los 10 minutos aunque haya actividad. La mejor solución para no perder tiempo es descargar los respaldos de 2 gb con winscp.

Otra cosa que voy a tener que hacer es modificar un script de respaldo para que no use ftp sin tar, debido a que algunos directorios miden mas de 2000 archivos y es limitación del pure-ftp de mostrar solo 2000 podría provocar problemas si se usan ftp para respaldos.

Du Bloqueado en server del corporativo

El servidor está lleno. Se supone que son 60 gb de espacio en ese server por raid, solo estamos usando 30.

Hago un scipt de php, lo subo y no corre du (linux) desde php ¿?

Son 60 gb, de los que usamos 25… 7 de sistema operativo y 20 estan perdidos. Es una tomada de pelo del proveedor. Siempre ha sido ese proveedor mi tercera opción, pero para la otra ya se que no conviene para necesidades de ese tamaño. Sin embargo probablemente pase a un cliente de las PYME con ese proveedor.

Interesante.

Update:
Ftp log era de 23 gb.

Una Tienda Online en cuatro horas, mas unos extras

El viernes pasado me encargaron consolidar cinco formatos html en uno.

No era solamente eso. Necesitaban hacer que funcionaran. Era una serie de tipos de productos diferente segun la persona a la que se vendiera el mismo articulo.

Acabe creando un motor de tienda virtual para pagos de los cinco artículos, aunque aplicando las reglas de negocio.

Y mientras yo hice eso, recibí cinco correos de una persona a la que di soporte UNA SOLA VEZ el 31 de diciembre en el corporativo. Asi que he recibido por parte de el unos 300 a 400 mb de correo basura.

Hoy borré uno de 8, otro de 7 y dos de 6 mb… e iban dirigidos a CINCO personas del corporativo en su lista de correo basura.

Que diferencia de lo que se hace por un sueldo.