Backups automáticos en el servidor
Publicado el Wednesday 21 de March del 2007 @ 18:49 por Armonth.
- 15
- 1
Comentar
La semana pasada estuve entretenido haciendome unos scripts para hacer backups automáticos y periódicos de los datos… para darme cuenta que Dreamhost ya tiene documentación al respecto. Y que mi script era casi un clon de los suyos…
El proceso es sencillo y lo que viene a continuación es una ligera adaptación (principalmente cambios estéticos), solamente hace falta acceso vía SSH y — como de costumbre — hay ejemplos que se pueden simplificar o mejorar, primero la estructura:
mkdir -p backups/{archives,mysql}
Con esto ya nos ahorramos tres comandos :D. Luego en backups creamos un fichero, por ejemplo sigt.sh con los datos para hacer copias de los ficheros:
#!/bin/bash
suffix=$(date +%Y-%m-%d.$H$P)
cd /home/user/.snapshot/nightly.0/
tar -zcf /home/user/backups/archives/sigt.$suffix.tar.gz sigt.net/
Y le damos los permisos:
chmod 755 sigt.sh
Segundo cambio, el formato final de salida (el “suffix”) lo he adaptado para que salga así: sigt.2007-03-21.9pm.tar.gz, además he añadido una “z” a “tar -cf” para que la salida sea comprimida con gzip (los usuarios de Windows pueden descomprimirlo con el WinRar mismo).
Luego, el script para bases de datos, mysql.sh lo he adaptado así:
#!/bin/bash
cd /home/username/backups/
suffix=$(date +%Y-%m-%d.$H$P)
mysqldump --opt -uUser -ppass -h mysqlA.domain.com db_nameA > mysql/db_nameA.$suffix.sql
mysqldump --opt -uUser -ppass -h mysqlB.domain.com db_nameB > mysql/db_nameB.$suffix.sql
Es decir, sin hacer un “tar” con todas las bases de datos dentro, podría aprovechar y en el mismo paso comprimirlo cambiando los mysqldump por:
mysqldump --opt -uusername -ppassword -h mysql.DOMAIN.com db_nameA | gzip -c > mysql/db_nameA-$suffix.sql.gz
mysqldump --opt -uusername -ppassword -h mysql.DOMAIN.com db_nameB | gzip -c > mysql/db_nameB-$suffix.sql.gz
Pero de momento no me interesa, para terminar los ejecutas y si todo funciona bien, los añades al crontab y listo… una medida extra aparte de las de Dreamhost que hacen un backup de la base de datos cada X horas…
PD: No entiendo como habiendo shellscripts, haya gente que se haga complicados scripts en Perl para media docena de bases de datos, supongo que es puro frikismo :D
15 Comentarios
-
guillem:
Primero: Son o no son un coñazo las webs con el ancho limitado? Hala, scroll horizontal. Y ya me dirás que hago con tanto pixel por los lados. No, no pienso reducir el tamaño de la ventana, cuando navego no hago otras cosas X’-D
http://bulma.net/beowulf/misc/sigt_net.png
Segundo: Lo del mysqldump está muy bien (lo digo sin segundas, yo lo uso habitualmente) hasta que la base de datos es de varios terabytes y no se puede parar.
La única solucion para hacer backups consistentes en caliente sin bloqueos ni paradas en MySQL creo que era usar InnoDB y un tal InnoDB Hot Backup de innodb.com, no libre. Hacen falta herramientas libres para cosas GRANDES :-/
Tercero: yo uso shellscripts (y pipes por herramientas clásicas tipo sed, cut, a veces awk, etc.) cuando tengo que hacer algo muy básico, cuando sé que no habrá que ampliar el script o cuando sé que en el sistema de destino no tendré otra cosa.
En general prefiero perl porque (si puedes disponer de él) en cuanto crece el invento es más cómodo y con lo que lleva por defecto lo haces todo. Una herramienta en lugar de veinte. Por no hablar de un proceso en lugar de veinte, y todo eso ;-)
-
Sergio de la Torre:
Algo parecido tengo yo sólo que las bases de datos me las manda a gmail diariamente y los archivos me los manda 2 veces por semana a un servidor ftp externo
Por cierto y aprovechando el post… ¿alguien sabe hacer backups diferenciales y/o incrementales con tar? Creo que ahorraría mucho tiempo, ancho de banda y espacio
Salu2
-
guillem:
Para los backups incrementales con GNU tar, mira como va la opción -g. Es muy simple, tiene un argumento que es un fichero de timestamp y básicamente mete en el tar todo lo que ha cambiado desde ese timestamp, luego lo actualiza. Hay que tener en cuenta como funciona y probarlo para ver si te vale o no. Yo lo uso en mis máquinas, hago un tar total a la semana y luego incrementales a diario (respecto al último total).
-
carlus:
Habría que buscar alguna solución para que mysqldump no necesitase pasarle el password en claro como argumento.
-
guillem:
#!/bin/bashARCHIVE="/tmp/mi_dominio_`date +%s`.tar.gz"
FILES="/etc /var/backups /var/www"
SNAPSHOT="/tmp/ftpbackup.snar"
TARARGS="--create --gzip --same-permissions --absolute-names --listed-incremental $SNAPSHOT --file"[ `date +%u` == 7 ] && rm -f $SNAPSHOT
tar $TARARGS $ARCHIVE $FILES > /dev/null
lftp -u 'miuser,mipass' backupspace.mi_isp.com -e "put $ARCHIVE; exit" > /dev/null
rm -f $ARCHIVE
-
guillem:
Gracias, queda mejor :-)
Por cierto, casi que retiro lo del InnoDB Hot Backup porque el MySQLdump de toda la vida veo que tiene un argumento interesantísimo llamado single-transaction que para tablas InnoDB hace justo lo que deberia hacer: un dump consistente sin bloquear a nadie. Me alegro. Aunque me siento un poco ridículo por enterarme ahora O:-)
-
carlus:
Armonth: Por supuesto, que el wp-config.php almacene la contraseña en claro también me parece una chapuza, y muchas aplicaciones php suelen utilizar este metodo. Yo he visto alguna que otra que te permite al menos tener la contraseña encriptada en el fichero de configuración de conexión con la base de datos. Algo es algo, luego tenemos ese generador de passwords del mysqladmin que puede mejorar el asunto ya que te genera contraseñas largas y con caracteres ascii de todo tipo.
El articulo que has escrito me parece muy util y practico, tan solo quise hacer un apunte por si alguién de los presentes sabe de alguna solución para mejorar el detalle del password Y reconozco que yo mismo también tengo en el script de backup el password en claro.
Un saludo.
-
InKiLiNo:
Venga más faena…
Cada vez que leo un post tuyo me das más curro, ¿acabaré algún día?
-
Sergio de la Torre:
Gracias guillem ;)
-
kujaku:
Ya que estamos con esos articulillos, y dado que de mainframes se algo pero de linux, nada, teneis alguna manera eficaz de hacer un script de backups pero que no se limiten a un directorio, sino a TODO el sistema? Es decir, algo asi como un tar -zcf /externo/archivo.tar.gz / y que /externo sea un montaje SMB con una maquina exterior.
Evidentemente, el sistema esta encendido pero en en el Runlevel 1, es decir, sin bases de datos y temas abiertos, aunque de esa manera es posible que ni funcione la red ni el SMB, asi que… ¿Teneis alguna idea de como aconsejarme?
En otro orden de cosas, Gillem, en mi opinion, no acabo de ver la utilidad de MySQL si realmente tienes Terabytes de datos, ya que “creo” que MySQL no soporta particionado de tablas (como Oracle o DB2), y por consiguiente, una select simple a esa tabla que puede ser de gigas y gigas creo que tardaria 2 dias en realizarse, no?
-
Reboot:
Yo debo de ser un animal de la ostia, porque lo que hago es copiar el directorio de la base de datos a hacer backup y listo.
-
guillem:
Otia, que aquí seguia la discusión y yo sin enterarme O:-)
Kujaku: Sobre lo de los backups de todo el sistema, hay varias soluciones pero la mejor (si puedes) es usar ZFS (no el de IBM, sino el de Sun ;-) que soporta “snapshots” consistentes de los sistema de ficheros. Por otra parte, tanto PostgreSQL como MySQL soportan ya particionado de tablas, y backups consistentes en caliente (aunque al principio pensaba que no).
Reboot: Sí, eres un pedazo de animal. No te ha pasado una desgracia por tu santa potra X’-D
-
s0m3bdy:
Reboot, el problema que tienes es que no puedes reconstruir una base innodb con un backup de ese estilo, no haces nada, y si tu backup es
en caliente para tablas myisam y similares, lo mas probable es que
al restaurar tu backup la mayoría de las tablas esten corruptas y pierdas muchos datos. Bueno, si no son aplicaciones críticas entiendo el estilo de backup que tomas, pero si lo son, DE INMEDIATO TOMA UN BACKUP CONFIABLEEEEE!!!!! y pruebalo ok?
