Más allá de WordPress: backups automáticos y logs

Nuestro servidor con WordPress instalado ya esta funcionando pero necesitamos una copia de seguridad en caso de que tengamos algun problema con nuestra web: un borrado accidental o problema con la base de datos, o algún problema de seguridad. Para ello vamos a crear dos copias de seguridad, una para la base de datos y otra para los archivos de la web ubicados en /var/www/html/sitename.

Lo primero que haremos será crear un directorio en el directorio home de nuestro usuario y crear dos scripts, uno para cada copia de seguridad:

cd
mkdir backups
cd backups
nano a1_db_backup_sitename.sh

#!/bin/bash

db_user=root
db_name=wp_db_name
destination_folder=/home/usuario-server/backups
backup_file=sitename-`date +%F_%H%M`

mysqldump -u $db_user $db_name | xz -z > $destination_folder/$backup_file.sql.xz

chmod +x nano a1_db_backup_sitename.sh

Para la copia de la base de datos se debe emplear el comando mysqldump que viene con el paquete de la base de datos. Como este comando no comprime la base de datos (llamaremos al archivo .sql), pasamos el resultado de la copia de la base de datos al compresor. Xz es una de los tres compresores que podemos utilizar y es el más moderno de los tres. Las tres primeras lineas son la asignación de variables que se deben cambiar cuando se crea el archivo en un nuevo servidor.
A continuación hacemos lo mismo para los archivos de la web:

cd backups
nano a1_site_backup_sitename.sh

#!/bin/bash

destination_folder=/home/usuario-server/backups
archive_file=sitename-`date +%F_%H%M`.tar.xz
/bin/tar -cJf $destination_folder/$archive_file /var/www/html/sitename

En este caso utilizamos la aplicación tar para crear un archivo con toda la estructura de directorios del sitio web y utilizamos opción J para comprimir en formato xz.

Por último, para que los backups se ejecuten periódicamente, deben instalarse en el crontab de usuario. En mi caso en el crontab de de root. Para ello, editamos el archivo de crontab y programamos:

$ sudo crontab -e

# .—————- minute (0 – 59)
# | .————- hour (0 – 23)
# | | .———- day of month (1 – 31)
# | | | .——- month (1 – 12) OR jan,feb,mar,apr …
# | | | | .—- day of week (0 – 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed (> /dev/null para evitar mail)
20 0 * * * /bin/sh /home/usuario-server/backups/a1_db_backup_world4.sh
00 1 * * 6 /bin/sh /home/usuario-server/backups/a1_site_backup_world4.sh

En nuestro caso hemos decidido que la copia de seguridad de la base de datos sea diaria y la de la web cada semana. No deberemos programarla a la misma hora ya que sinó el dia en que coincidan las dos el rendimiento del servidor puede verse afectado.

Por último, comprobamos que nuestro crontab está instalado mediante sudo crontab -l y desde ahora ya podremos conectarnos a nuestro servidor mediante Filezilla u otro cliente FTPS para descargar nuestras copias de seguridad.

Para una copia de seguridad automatizada y en un servidor externo, tenemos varias opciones como hacerla en AWS u otros servicios on-line. Quizá en otro artículo cubramos esta posibilidad mediante la fantástica herramienta (para paranoicos) Tarsnap.

Print Friendly, PDF & Email

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *