¿Te tirarías con un carro de la compra por un barranco?

Échale un vistazo a esto...

Tras la primera entrada sobre de copias de seguridad aquí va otra entrada sobre cómo hacerlo para el caso de servidores web.

Para realizar backups, primero se necesita una cuenta de usuario en la máquina. Si no tienes cuenta de usuario, poco puedes hacer.

En mi caso básicamente tengo dos webs de las que quiero hacer backup: artypist.com y este blog.

Este blog utiliza wordpress, por lo que realmente, hacer un backup de los archivos tampoco aporta mucho valor, ya que en caso de perder los ficheros, se podrian volver a bajar de internet.

Lo más importante de este blog, y de cualquier otro, es la base de datos y los ficheros de imágenes o datos que se puedan haber subido al servidor.

Guardar un backup de los ficheros que puedes conseguir por otra parte es importante en dos casos:

  • Para minimizar el tiempo de reacción cuando te das cuenta de que todo ha dejado de ir: imagina que este blog se borra por arte de magia. Si yo tenia un backup, es mejor restaurar el backup, que tendrá las contraseñas de la base de datos, etc, antes que reinstalar y configurar todo wordpress, ya que se tarda mucho menos en que el servidor vuelva a estar en pleno funcionamiento.
  • Para prevenir pérdida de datos que no recordábamos que habíamos modificado: imagina que cambias el estilo de la página o que has subido archivos y desconoces si se guardaban en la base de datos o el sistema de ficheros. Si tienes una copia de todo, sabes que luego podrás recuperarlo todo. Fácil.

En el caso de Artypist, el punto crítico sería la base de datos, ya que la web, las lecciones, etc… se podrían recuperar del sistema de control de versiones.

En cualquier caso lo mejor es realizar un backup de todo y así uno se cura en salud, por lo que pueda pasar.

Una vez vistos los motivos, el script ideal que soluciona nuestros problemas debería hacer las siguientes cosas:

  • Crear un archivo comprimido (.tgz) para los archivos de cada dominio
  • Crear un archivo comprimido (.gz) por cada base de datos de cada dominio
  • Eliminar copias de seguridad antiguas (p.ej. eliminar copias de hace más de 10 dias)
  • Mandar las copias de seguridad creadas a otro servidor

Una vez se tiene el script, hay que hacer que se ejecute automáticamente de forma periódica. ¿Por qué automáticamente? Porque manualmente se nos olvidaría, o lo iríamos dejando pasar hasta un día en que nos hiciera falta el backup y por pereza ese backup no existiera.

Para ejecutar comandos automáticamente, en linux se usa cron. Así que, nos vamos a una consola y hacemos:

$ crontab -e

Suponiendo que el script de copias de seguridad se encuentra en “/home/usuario/backup.sh”, editamos el archivo de cron para que contenga algo como:

30 3 * * 2,4,7 /home/usuario/backup.sh

Este script se ejecutaría todos los Martes, Jueves y Domingos a las 3:30 de la madrugada. Con lo que tendríamos 3 copias de seguridad a la semana.

Para más información podeis leer este artículo de backups automátios de DreamHost (en inglés)

Para el que quiera echarle un ojo: este es el script de backup en cuestión: Script de Backup

Finalmente, el último paso del script compromete un poco la seguridad, ya que para que no pida passwords hay que crear unas claves y copiarlas en ambos sistemas, así que si el entorno no es del todo seguro, lo mejor es borrar estas lineas.

No soy ningún experto en servidores, y soy consciente de que todo puede hacerse mejor, así que si teneis alguna sugerencia será más que bienvenida.

Nota: dado que el script de backup contiene passwords, etc, hay que ser muy cautelosos acerca de dónde se ubica (para que no sea visible y alguien se lo pueda bajar desde tu web), y acerca de los permisos del archivo (para que otros usuarios del hospedaje no puedan ver su contenido). La recomendación es ejecutar el comando: chmod 700 backup.sh

One Response to “Copias de seguridad: El script”

  1. […] Actualizado: aquí teneis la segunda parte […]

    November 24th, 2007 | 9:36 am

Leave a Reply