David.. Debo comentar que el diseño de BD de la solucion, NO contemplaron ningun campo last_modified, mas bien intente buscar en el information_schema de MySQL, en la tabla TABLES en el campo last_update el dato, pero me encontre con que en algunos registros se almancena <NULL> (ya no segui buscando !)
En el caso de los respaldos, como tu me recomiendas, genero los DMP (mysqldmp) y con rsync loes envio a otro servidor, estos tienen una duracion de 1 semana y cada fin de mes los saco a DVD, asi que siempre tengo una semana atraz + un mes, creo suficiente !. En el caso de tomcat, los respaldo utilizo el argumento --exclude del tar con la finalidad de que no sean tan grandes y tenga varis "chiquitops" que quepan en DVD's, pero excluire los directorios que me recomiendas Pondre en practica lo de la restauracion de la instalacion completa, eso sinceramente NO lo habia contemplado.. muchas gracias ! 2009/10/9 David Martinez <da...@hackerdude.com>: > Hola Angellyx, > > En MySQL es preferible hacer un dump de toda la db. Si quieres borrar lo no > utilizado, necesitas usar SQL para ver cuando se usaron los registros > (esperando que tengan campos de "last modified" o algo así) y deja las > tablas en paz (aplicaciones típicamente se "enojan" cuando faltan tablas, se > enojan menos cuando faltan registros). Pero requiere que sepas cómo fué > diseñada la aplicación para no eliminar nada. Tengo una base con varios > millones de registros a la que hago un backup de noche y si utilizas el > comando "nice" no interrumpe nada y funciona más o menos bien. Si no > diseñaste tú la aplicación y no la conoces muy bien es muchísimo más seguro > no tocar la base de datos y tratarla como "los datos de tu empresa" y > dejarlo así. > > En vez de quemarlos a un DVD, puedes utilizar la red? Aún con muy poco > dinero, puedes hacer un backup a otra máquina en tu oficina usando rsync. O > puedes usar una máquina en tu casa (incluso en Windows puedes instalar > cygwin y sshd) o en algún otro lugar físico para tener la redundancia que > necesitas. Rsync te permite limitar la cantidad de ancho de banda que usas. > Si utilizas como 10% de tu ancho de banda lo puedes copiar y puede ser que > tarde unas horas pero lo vas a tener en dos lados físicos diferentes.. > > Si no se puede, y debes utilizar DVDs por otros motivos, utiliza "tar" con > opción -l que limita el tamaño de cada archivo (man tar) para hacer un tar > del bzip > > En Tomcat, es muy sencillo hacer un tar de todo el directorio Tomcat. No sé > cómo lo tengas inicializando, si inicializa con la máquina con > /etc/rc.d/tomcat o algo así también guarda ese archivo por si las moscas. > Normalmente puedes excluir tomcat/tmp y work. En particular quieres la > instalación de tomcat, la configuración, lib y webapps. Pero si no estás > segura y el directorio de tomcat no es muy grande, es más sencillo agarrar > todo. Checa la versión de Java que se usa (java -v como el usuario que está > corriendo Tomcat) y haz nota de ella (por ejemplo 1.6.0b3 o lo que sea) para > saber qué versión restaurar (que Java es muy compatible, pero por si las > dudas). Si es la misma versión que el RPM no te preocupes mucho. Si viene de > /usr/local o algo así, añadela al backup también por si las moscas. > > Esto es para resolver la "emergencia" de respaldos que tienes ahorita. Ahora > a mejorar las cosas permanentemente, para que no te preocupes por las > sorpresas: > > En mi opinión la mejor opción para la aplicación es que sea fácil de > instalar. Los desarrolladores de la aplicación pudieron haber creado muchas > dependencias en varios lugares del disco, entonces el "sin sorpresas" puede > ser difícil. Hablar con ellos acerca de lo que hicieron puede darte pistas > pero a veces se les olvida. Preguntas relevantes (para Java) son: > > - Hay scripts o dependencias de archivos fuera del arbol de Tomcat? > - Usan JMS u otros servicios que no se encuentran dentro de tomcat? Cómo se > configuran? > > Evitando Sorpresas: > Lo mejor que puedes hacer a este punto es crear un VirtualBox en otra > máquina y tratar de restaurar en esa, para "practicar reinstalar la > aplicación" y saber que tus backups son restaurables. Crea un virtualbox, > ponle el mismo sistema operativo que hay en la máquina real, haz un > "snapshot" y reinstala la aplicación. Cuando te trabes, añade los archivos > que te faltaron al backup y restaura el snapshot para que vuelvas a > intentarlo de "nuevo sistema", enjuaga y repite hasta que todo salga bién. > Mientras haces esto es bueno crear un script que vaya restaurando del backup > automatizado. Incluye este script en tu directorio de backup. Pruébalo todo > muy bien y mide el tiempo que te toma restaurarlo. > > En general quieres escribir un script que haga todo esto en el disco (backup > mysql, backup tomcat) y lo ponga en un directorio. Después haces tar de ese > directorio y lo escribes a otro lugar físico (DVD, otra máquina). Los > principios de donde ponerlo son: > > - Entre más copias haya, mejor > - Entre más lugares físicos haya donde están los datos, mejor. > - Si pasa por la red obviamente lo quieres con ssh > - Es posible que quieras encryptarlo con gpg o algo así, si lo vas a poner > en otra máquina física de la cual no tienes control, o si los DVDs acaban en > un lugar que no es seguro físicamente (una tienda en vez del banco, por > ejemplo). Haz esto después de comprimirlo, y ten varias copias de los > archivos llave usados para encriptarlo. > > Al final de todo este ejercicio tendrás: > 1) Confianza de que no importa qué pase, puedes restaurar el sistema. Podrás > dormir mejor en la noche > 2) Si la máquina truena y tu jefe dice "cuando te tardas en restaurarlo", > tienes una idea del tiempo (añade el tiempo que te tomaría instalar el OS en > la máquina, etc, pero al menos sabes más o menos cuando). Esto le permite a > tu jefe planear. > > Finalmente, ejercita de vez en cuando (mensual, por cuarto o semestral) > restaurar un backup nuevo en el VirtualBox (ponlo en tu calendario como > recurring appointment para que no se te olvide). Así si cambia la > configuración con el tiempo podrás encontrar lo nuevo que salió mal y > mejorar tu script para que todo funcione bien cuando sea necesario. > > Es más trabajo, pero vas automatizandolo mientras lo haces, para que al > final tengas una buena metodología y lo puedas hacer rápido (o otra persona > lo pueda hacer por tí cuando tengas empleados porque la compañia creció). > > Ojalá esto ayude. > > Saludos desde California, > > -David > http://www.hackerdude.com > > > > On Oct 8, 2009, at 1:40 PM, angellyx wrote: > >> Hola lista: >> >> Soy nuevo en el tema de los roles de SysAdmin y DBA, tengo algunas >> dudas y les agradecere su ayuda: >> >> 1.- ¿ como puedo saber cual fue la ultima fecha en la k se accedio a >> la BD en cualquiera de sus tablas ?.. deseo respaldar y borrar la no >> utilizadas >> 2.- Mis respado los genero: >> -> $MYSQLDUMP $database | $BZIP2 > >> $BACKUP_DIR/$FECHA/$FECHA-db-$database.sql.bz2 >> Y los "quemo" a un DVD.. el problema es k excederan los 4.4 GB >> pronto ¿ k puedo hacer para que no excedan ese tamaño ? ya no me >> cabrab en un DVD, NO puedo cambiar de medio "no money"... >> >> 3.- cuales es el backup optimo para TomCat y las aplicaciones. Es >> decir que subdirectorios/archivos deben ser respaldados para tener una >> restauracion sin "sorpresas" >> >> muchas gracias y saludos cordiales >> >> >> -- >> +-------------------+ >> @nGellYx >> +-------------------+ > > -- +-------------------+ @ N g e l l y x +-------------------+
