Disponer de copias de seguridad de nuestra web puede salvarnos de más de una situación peliaguda. Es algo que ya hemos discutido varias veces en este blog y que nunca me canso de repetir. A pesar de la importancia que tienen las copias de seguridad, (creo que) nunca hemos hablado de cómo puedes hacerlas.
Existen diferentes métodos para realizar una copia de seguridad. Como casi todo en WordPress, algunas soluciones las encontraremos en el ecosistema de plugins:
- BackupBuddy. Un buen plugin crear y gestionar copias de seguridad, recomendado por uno de nuestros WProfesionales, Joan Boluda.
- WPBackup. Otro plugin para planificar la creación de copias de seguridad de nuestros ficheros y base de datos.
- WordPress Backup to Dropbox. Este plugin es interesante porque la copia de seguridad de tu site se envía automáticamente a tu cuenta de Dropbox, una solución rápida y cómoda para instalaciones de WordPress pequeñas. Recuerda que jamás deberías guardar la copia de seguridad de un sistema en el propio sistema, así que hacerlo en Dropbox es una buena idea 😉
Sin embargo, hoy me gustaría explicarte cómo puedes hacer copias de seguridad con Git. La primera persona a la que oí hablar de esta idea fue Rafa Poveda durante el Contributor Day de la WordCamp Barcelona. Si, como yo, eres un usuario de Linux (o UNIX en general), trabajas habitualmente con Git y amas el terminal de comandos, entonces esta forma de asegurar tus instalaciones de WordPress autogestionadas te va a encantar.
Una (espero que pequeña) introducción a Git
Git es un sistema de control de versiones distribuido. ¿Que qué es eso? Un sistema de control de versiones (VCS por sus siglas en inglés) es un sistema que almacena todos los cambios que se realizan sobre un repositorio (siendo un repositorio un conjunto de ficheros). Esta es la teoría. Veamos cómo funciona todo esto con un sencillo ejemplo paso a paso:
- Creamos un nuevo repositorio vacío.
- Creamos un nuevo fichero fichero-1.txt dentro del repositorio. Nuestro VCS guardará que acabamos de crear un fichero.
- Editamos el fichero-1.txt y le añadimos texto. Nuestro VCS guardará la nueva versión del fichero.
- Añadimos un segundo fichero fichero-2.txt y un directorio llamado carpeta. De nuevo, el VCS guardará estos cambios.
- Borramos el fichero-1.txt. ¿Y ahora? El VCS se apunta que hemos borrado ese fichero y «lo elimina».
Lo que estoy describiendo no parece diferir demasiado de lo que hacemos en nuestro ordenador habitualmente, ¿no? Creas ficheros, los modificas, los eliminas… nada nuevo. Lo interesante del sistema de control de versiones es que podemos acceder a los instantes anteriores: aunque yo haya borrado el fichero-1.txt y, por tanto, ya no lo tenga disponible (ya hemos realizado el paso 5), en cualquier momento puedo acceder a mi VCS y «navegar hacia el pasado» para ver qué ficheros y con qué contenidos había en el paso 4, o en el paso 3… y así hasta el origen (la creación del repositorio).
¿Entiendes ya por qué se le llama control de versiones? El sistema tiene un registro con todos los cambios que se han ido produciendo a lo largo del tiempo y nos permite recuperar estados anteriores, de una forma sencilla y cómoda. En mi opinión, esta funcionalidad por si sola ya es bastante chula. De hecho (y por si no lo sabías), Dropbox incluye este tipo de control de versiones: dado un fichero cualquiera dentro de tu directorio Dropbox, puedes recuperar versiones anteriores del fichero de tal forma que, en caso de haber metido la pata con alguno de tus documentos, no tengas que rehacer trabajo.
Volviendo a Git, éste fue diseñado y desarrollado originalmente por Linus Torlvads, el creador de Linux. Git nació en 2005 con el objetivo de convertirse en el sistema de control de versiones sobre el que desarrollar Linux y desde entonces ha evolucionado y mejorado muchísimo. Algunas de sus principales características son:
- Registro de cambios. Cuando subimos una nueva versión de un fichero de texto plano (lo que normalmente es el código fuente de un fichero, vaya), siempre tendremos información sobre qué cambios concretos se han hecho. Esto quiere decir que podremos ver qué lineas se han añadido, cuáles se han eliminado y cuáles se han modificado. Además, los cambios suelen acompañarse de un mensaje que sirve como resumen de los cambios efectuados. Si somos ordenados y pulcros, el registro de cambios de Git nos permitirá saltar de una versión a otra con comodidad y rapidez.
- Desarrollo distribuido. El objetivo de usar Git es que varias personas puedan trabajar sobre un mismo repositorio a la vez y que todas contribuyan a él. Es de suponer que cada uno de los diferentes desarrolladores estará trabajando en una funcionalidad o bug diferente, y que su parte del trabajo sumará al total del proyecto. Este repositorio está en un servidor central al que todos tienen acceso, en el que pueden subir sus cambios y del que pueden obtener los cambios hechos por otros. Además, Git permite tener una copia local de todo el historial de desarrollo, con lo cual podemos beneficiarnos del sistema de control de versiones incluso si no tenemos conexión con el servidor central.
- Fusión de versiones automática. ¿Qué pasa si, en este entorno distribuido con varios desarrolladores, dos personas editan un mismo fichero? Está claro que los cambios que ha hecho uno pueden pisar los del otro… ¿Qué versión guardamos? ¿Qué hacemos? En la mayoría de los casos, Git se encargará de solucionar automáticamente el problema, generando una tercera copia con los cambios de ambos. Si detecta que al hacer la fusión entre el trabajo de uno y el de otro puede haber conflictos, nos informará y nos pedirá que los resolvamos a mano.
Y creo que con esto ya puedes hacerte una idea de qué es y para qué sirve Git. A continuación veremos cómo usarlo para realizar copias de seguridad, pero si eres un desarrollador y no lo estabas usando en tus proyectos… en fin, ¡espero que de ahora en adelante lo hagas! Si quieres aprender un poco más cómo funciona y dominas el inglés, aquí tienes un fantástico tutorial de GitHub para aprender a usar Git en 15 minutos.
Copias de seguridad con Git
En anteriores entradas hemos hablado de la importancia que tienen las copias de seguridad, especialmente cuando las cosas se tuercen y necesitamos recuperarnos rápidamente. La primera duda que aparece cuando uno se propone crear copias de seguridad es… vale, voy a hacer estas copias, pero ¿copias de qué? ¿De mis plugins? ¿De mi tema? ¿De mi base de datos? Recuerda que lo importante de una copia de seguridad es que te permita recuperarte rápidamente en caso de necesidad, así que lo mínimo que deberá incluir es todo aquello que es único en tu instalación de WordPress:
- Directorio
wp-content/uploads. Ahí tienes, por defecto, todos los ficheros que subes a tu librería multimedia (imágenes, vídeos, archivos comprimidos…) - Fichero
wp-config.php. Configuración de tu WordPress como, por ejemplo, los credenciales para acceder a la base de datos. - Fichero
.htaccess. Configuración de servidor relacionada con tu WordPress. Por ejemplo, si usas algún tipo de Enlace permanente que no sea el por defecto, tendrás algunas reglas importantes en este fichero. También puede contener reglas para mejorar la seguridad de tu sistema y otros parámetros. - Base de datos. Todas las entradas que has escrito, tus páginas, los comentarios de tus visitantes, la configuración de plugins y temas… en resumen, todo lo que es importante y que (probablemente) sería imposible llegar a restaurar a mano, está en la base de datos.
- Tema hijo (o tema a medida). Si has creado un tema hijo para adaptar algunos apartado del tema que usas en tu web, también te interesará guardarlo.
Pero hay algunas cosas que, aunque puedas recuperar desde otras fuentes, igual también sería interesante tener en la copia de seguridad:
- Plugins. Todos los plugins que hayas instalado en tu tema. La mayoría de ellos serán, seguramente, del repositorio oficial de plugins de WordPress, pero quizás otros sean de pago y los hayas conseguido de otras fuentes. Tenerlos todos en la copia que vamos a crear te ahorrará el tiempo de buscarlos, descargarlos y volverlos a instalar en tu web en caso de necesidad.
- Temas. Lo mismo pasa con los temas. A lo mejor tu tema está hecho a medida, a lo mejor lo has descargado de alguna plataforma de temas profesionales. De nuevo, tenerlos en la copia de seguridad hace tu vida más cómoda.
Y ya puestos, si vamos a guardar todo el directorio wp-content (con los contenidos de la librería multimedia, los plugins y los temas), la base de datos, algunos ficheros de configuración de WordPress… ¿por qué no guardamos absolutamente todo WordPress?
- WordPress en general. Si leíste mi entrada sobre cómo recuperar una instalación hackeada, supongo que viste que una de las cosas a hacer es reinstalar un WordPress limpio. Si tenemos absolutamente todo WordPress (el core, los plugins, los temas, las imágenes, la base de datos…) en una misma copia de seguridad, ¿para qué perder el tiempo en bajar cada uno de los componentes uno a uno y configurarlo todo para dejarlo como antes?
Llegados a este punto, espero que ya empieces a tener una idea de cómo Git te puede ayudar a crear y gestionar tus copias de seguridad. La propuesta que te propongo es muy sencilla: basta con hacer que el directorio donde tenemos instalado WordPress sea nuestro repositorio y que absolutamente todos los ficheros que contiene estén controlados por Git. Ni más, ni menos.
Configurar Git para que controle nuestro WordPress
Suponiendo que tenemos instalado Git en nuestro servidor y que WordPress está instalado en el directorio /wordpress/, lo único que tenemos que hacer (desde la línea de comandos) es lo siguiente:
cd /wordpress/
git init
y veremos la siguiente respuesta:
Initialized empty Git repository in /wordpress/.git/
Con esto ya hemos indicado a Git que el directorio /wordpress/ va a ser nuestro repositorio. Ahora tenemos que indicarle qué ficheros hay que tener controlados. Como ya hemos visto, son todos, así que añadiremos todos los ficheros (ocultos o no):
git add .
Si ahora ejecutáramos git status podremos ver que todos los ficheros están ya monitorizados por Git:
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: index.php
new file: license.txt
new file: readme.html
new file: wp-activate.php
...
Finalmente, lo único que tenemos que hacer es un commit de todos los cambios para que se cree un «punto de restauración» en nuestro backup:
git commit --all -m "Primera copia de seguridad de nuestra web".
Qué hacer cuando hay cambios en nuestra web
Vamos a echar un vistazo al estado de nuestro repositorio tal y como está en este momento con git status:
On branch master nothing to commit, working directory clean
Tal y como podemos ver, nos indica que «no hay nada que guardar, el directorio está limpio».
Imaginemos que cambiamos algo de la configuración de nuestro fichero wp-config.php y que añadimos un nuevo plugin llamado ejemplo. Si después de estos cambios echamos un vistazo de nuevo veremos lo siguiente:
On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: wp-config.php Untracked files: (use "git add ..." to include in what will be committed) wp-content/plugins/ejemplo/ no changes added to commit (use "git add" and/or "git commit -a")
Es decir, Git acaba de detectar que el fichero wp-config.php ha cambiado (Changes not staged for commit) y que hemos añadido un nuevo plugin el cual todavía no está bajo su control (Untracked files). ¿Qué tenemos que hacer ahora? Fácil, decirle a Git que añada el nuevo plugin a su control y hacer de nuevo commit de todos los cambios:
git add wp-content/plugins/ejemplo/ git commit -a -m "He instalado 'ejemplo' y actualizado wp-config porque..."
¡Y ya está! Ya tenemos un segundo punto de restauración. Fíjate que cada vez que hago una copia de seguridad manualmente le añado un mensaje (parámetro -m). En el futuro, estos mensajes me pueden ser útiles para saber por qué creé una copia de seguridad en un cierto punto.
Nelio Content
Estoy tan contento con Nelio Content que parece que me hayan pagado para hablar bién de él… pero es que también a ti te encantará: funciona como prometen, la programación automática de mensajes es increíble, la calidad/precio no tiene parangón y su equipo de soporte se siente como si fueran parte del tuyo.
Panozk
Espera un segundo… ¿y la base de datos?
Con lo que te acabo de explicar, ya tienes una copia de seguridad de todos los ficheros de tu instalación de WordPress. Sin embargo, aún no hemos hecho ninguna copia de la base de datos, aunque no es muy difícil conseguirlo: simplemente tienes que exportar la base de datos a un fichero .sql y, a partir de ahí, dejar que sea Git el que lo guarde (como si fuera un fichero más de cualquier instalación). ¡Veamos cómo!
Puedes exportar la base de datos como más te guste. En mi caso, siempre uso una herramienta de la línea de comandos llamada mysqldump:
mysqldump -uUSUARIO -pCONTRASEÑA BD > /wordpress/database.sql
Como puedes ver, lo único que necesita el comando anterior es el USUARIO y CONTRASEÑA que necesitas para conectarte al servidor SQL, la base de datos a exportar BD y el fichero donde quieres guardarlo todo /wordpress/database.sql (si el servidor de base de datos no está en la misma máquina donde tienes WordPress instalado, deberás indicar el host).
Edición 27 de junio de 2016. Tal y como señala Iñaki, si ponemos el volcado de la base de datos en la instalación de WordPress, el fichero sería accesible para cualquier visitante de nuestra web. Para evitarlo, la mejor solución es bloquear el acceso a ese fichero a través de la configuración de nuestro servidor.
Cuando el proceso haya acabado (suele ser bastante rápido), tendrás en la raíz del sistema un fichero de texto plano con el export de tu base de datos. Así pues, sólo nos queda añadirlo a Git y hacer el commit:
cd /wordpress/
git add database.sql
git commit -a -m "Añadida la base de datos a la copia de seguridad"
De ahora en adelante, cada vez que queramos crear una copia de seguridad de todo, bastará con volver a exportar el estado actual de la base de datos, asegurarnos que todos los ficheros nuevos (nuevos plugins, temas, o elementos de la media library) estén incluidos y hacer commit.
cd /wordpress/ mysqldump -uUSUARIO -pCONTRASEÑA BD > /wordpress/database.sql git add * git add .[^.]* git commit -a -m "Mensaje..."
Guardar la copia de seguridad remotamente
Cada vez que hacemos un commit de nuestra instalación de WordPress creamos un punto de restauración (lo que viene siendo «la copia de seguridad») que nos permitirá volver a ella rápidamente en caso de necesidad. El problema que tenemos con esta solución es que todos estos commits se guardan en el propio directorio donde tenemos instalado WordPress.
Las copias de seguridad sirven para recuperar nuestro sistema rápidamente cuando hemos tenido un problemón: nuestra web ha sido hackeada, hemos borrado algo que no debíamos o nuestro servidor (el ordenador) ha petado, por ejemplo. Si almacenamos la copia de seguridad junto con la instalación de WordPress únicamente y no hacemos nada más… pues, en fin, en caso de que nos hackeen la web nos pueden borrar las copias de seguridad (o hacerlo nosotros por error), o si el ordenador peta perderemos no sólo la web, sino también el salvavidas que habíamos preparado. Está claro, pues, que tenemos que hacer algo más.
Tal y como te he explicado en la introducción, con Git puedes tener un servidor central al que todos los desarrolladores tengan acceso. Así pues, si montamos este «servidor central» (separado de nuestro servidor web, por supuesto), podremos guardar las copias de seguridad en una ubicación remota y solucionar el problema que te comentaba. ¿Cómo hacemos eso?
Existen varios servicios en Internet que nos permiten montar repositorios Git. Los dos más conocidos son, seguramente, GitHub y BitBucket. Ambos nos permiten tener repositorios públicos (todo el mundo tiene acceso a su contenido) y privados (sólo nosotros, o quienes queramos, podremos acceder a él). ¿Cuál es la diferencia entre ellos? Con GitHub, los repositorios para proyectos públicos (normalmente, proyectos software libre) son gratis, mientras que para poder tener proyectos privados hay que pagar. Por otro lado, BitBucket funciona al revés: puedes montar tantos repositorios privados como quieras, pero para los públicos hay que pasar por caja.
Como lo que queremos es crear copias de seguridad de nuestro site y esto, en principio, es una información privada a la que nadie más debería tener acceso… vamos a usar BitBucket.
Crear un nuevo repositorio en BitBucket
Lo primero que tienes que hacer es crearte una cuenta en BitBucket (si todavía no tienes una). Una vez listo, ya podemos crear un nuevo repositorio. Yo no suelo complicarme mucho la vida y sólo especifico el nombre del repo:
Una vez el repo está creado, podremos acceder a él y ver que está vacío:
Ya podemos pasar al siguiente punto…
Enlazar nuestro repositorio local con el repositorio de BitBucket
Ahora mismo tenemos dos repositorios: uno en local que es el que contiene las copias de seguridad y otro remoto en BitBucket que está vacío. ¿Qué queda? Pues, simplemente, enlazar el uno con el otro. Si echas un vistazo a la anterior captura de pantalla, verás que te explica cómo configurar Git en tu ordenador local:
mkdir /path/to/your/project cd /path/to/your/project git init git remote add origin https://davilera@bitbucket.org/davilera/wprincipiante.es.git
El único comando que nos interesa es el último, puesto que nuestro directorio local ya existe (/wordpress/) y ya hemos visto que había que convertirlo en un repositorio de Git (git init). ¿Y qué hace la última instrucción? Lo que nos quedaba: indicarle a nuestro repositorio local que todos los commits tienen que guardarse en el repositorio remoto de BitBucket.
Finalmente, una vez esté todo configurado sólo nos queda una cosita: cada vez que creemos un nuevo commit en local tendremos que enviarlo al servidor remoto con un git push:
git commit -a -m "Mensaje..." git push --all
Si ahora vamos a echar un vistazo a nuestro repositorio en BitBucket, veremos lo siguiente:
Y si vamos al apartado Commits, veremos todas las copias de seguridad que hemos hecho.
Resumiendo…
Las copias de seguridad nos permiten recuperarnos rápidamente de un desastre. Hoy hemos visto como Git, una herramienta de control de versiones habitualmente usada para gestionar proyectos software, nos puede ayudar a crear y gestionar nuestras copias de seguridad. También hemos visto que podemos usar un servicio como BitBucket para almacenar estas copias en un lugar remoto y confiable.
Ahora que ya sabes toda la potencia que hay detrás de Git, ya no tienes excusa para no hacer copias de seguridad de tu web. En una próxima entrada, te explicaré cómo puedes automatizar todo el proceso y algún truco adicional que seguro te va a encantar 😀
Imagen destacada de Theophilos Papadopoulos.
Deja una respuesta