Foto de cielo difuminado y colorido

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.

Day 113: Introduction de Snugg LePup
Empecemos con una pequeña introducción sobre Git. Imagen de Snugg LePup.

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:

  1. Creamos un nuevo repositorio vacío.
  2. Creamos un nuevo fichero fichero-1.txt dentro del repositorio. Nuestro VCS guardará que acabamos de crear un fichero.
  3. Editamos el fichero-1.txt y le añadimos texto. Nuestro VCS guardará la nueva versión del fichero.
  4. Añadimos un segundo fichero fichero-2.txt y un directorio llamado carpeta. De nuevo, el VCS guardará estos cambios.
  5. 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.

Blogging de Anonymous Account
¡Manos a la obra! Imagen de Anonymous Account.

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".
Any questions? de Matthias Ripp
¿Va todo bien? Si necesitas tomarte un descanso, adelante, pero ya casi hemos acabado 🙂 Imagen de Matthias Ripp.

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.

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:

Creación de un repositorio en BitBucket
Para crear un nuevo repositorio Git en BitBucket basta con especificar un nombre y comprobar que su tipo sea «Git».

Una vez el repo está creado, podremos acceder a él y ver que está vacío:

Visión general de nuestro repositorio
Visión general de nuestro repositorio recién creado. Fíjate que nos explica cómo crearlo en local.

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:

Repositorio en BitBucket con un WordPress
Este repositorio de BitBucket contiene una (o varias) copias de seguridad de nuestro WordPress.

Y si vamos al apartado Commits, veremos todas las copias de seguridad que hemos hecho.

Lista de "Commits" en BitBucket
En el apartado «Commits» podemos ver todos los commits que hemos hecho en nuestro proyecto. En nuestro caso, cada commit es una copia de seguridad.

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.

6 respuestas a «Copias de seguridad con Git»

  1. Avatar de Paul

    Hola David, el tema de hacer copias de seguridad con Git lo tenía pendiente de investigar. Tu articulo es muy esclarecedor. Trataré de ponerlo en práctica con Bitbucket.

    Y ahora mi granito de arena sobre el tema de las copias de seguridad en WordPress. Te añado tres plugins alternativos a los que comentas.

    UpdraftPlus. Tiene un mecanismo que funciona muy bien en hosting compartidos evitando saturar los recursos del servidor, lo que te permite hacer copias grandes sin fallos. Cuestión de tiempo.
    BackWPup. Tiene un sistema de programación muy atractivo que te permite hilar filo en los archivos de copia.
    Duplicator. Tu mejor alado en caso de querer migrar una web de un hosting a otro. La versión comercial añade la funcion de programación (schedule) que no viene de serie con la gratuita.

    Y aquí algunos sus tutoriales.

    http://miposicionamientoweb.es/como-hacer-backup-de-wordpress-con-updraftplus/
    http://www.administrandowp.com/copia-de-seguridad-con-wordpress/
    http://hormigasenlanube.com/duplicator-para-wordpress/

    Y si puedes delega en el hosting las copias de seguridad y a ser posible con periodo de retención de 30 días. Si no es el caso, pues a tirar de plugin y a correr.

    Buena semana.

    Un saludo.

    1. Avatar de David Aguilera

      ¡Hola Paul! Me alegro que te haya gustado la entrada 🙂 ¡Y gracias por los tutoriales extra!

  2. Avatar de Jonay
    Jonay

    No estoy muy puesto en Git, pero aunque puede ser una buena solución si trabajas solo.

    Me parece que seria una mala practica si trabajas conjuntamente con otras personas porque:

    Tu copia en local no tiene porque ser la misma que la copia en el git.

    Al utilizarlo para guardar datos ya no se utiliza propiamente como un control de versiones ,es decir, guardas tu ultima version en vez de ir anotando los pequeño cambios.

    Y guardar las pruebas, los experimentos o como quieran llamarlo, no es practico usando el git cuando se trabaja con varias personas.

    Personalmente, para copias de seguridad prefiero usar una herramienta que me vaya bien tanto trabajando solo como en equipo.
    ¿Me equivoco?

    P.S. Al margen de mi opinión me gustado mucho el articulo ha estado muy bien hasta lo he puesto mis marcadores para relerlo con calma cuando tenga más tiempo.

    1. Avatar de David Aguilera

      ¡Hola Jonay!

      Muchas gracias por compartir tu opinión. Desde mi punto de vista, Git es una fantástica herramienta para el trabajo en equipo. De hecho, Git nació (tal y como ya comento en la entrada) con el objetivo de convertirse en el sistema de control de versiones sobre el que desarrollar el núcleo de Linux. Linux es un proyecto de software libre increíblemente complejo y con muchísimos desarrolladores detrás.

      En cuanto a usar Git para copias de seguridad, no veo por qué no debería funcionarte «trabajando en equipo». ¿Podrías detallar un poco más qué limitaciones le ves? No olvides que todas las versiones de tu site (es decir, todas las copias de seguridad) pueden (y deben) sincronizarse con un servidor Git externo, al que todos los miembros de tu equipo tendrían acceso.

      ¡Un saludo!

  3. Avatar de Iñaki Arenaza
    Iñaki Arenaza

    Hola David,

    un par de comentarios, con ánimo de mejorar tu propuesta.

    1. Para añadir todo el contenido de WordPress a git, puedes usar «git add .» y él se encarga de añadir (por defecto) de forma recursiva todo el contenido del directorio (incluyendo ficheros que empiezan por ‘.’). Por lo que no hace falta usar los comodines del shell y una sintaxis un poco más arcana para los no iniciados 🙂

    2. Si dejas el volcado de la base de datos (mysqldump) directamente dentro del directorio de wordpress (como haces en tu ejemplo), entonces ¡está disponible desde la web para todo el mundo!. Se puede usar «seguridad por medio de oscuridad» y usar un nombre poco predecible del fichero (o incluirlo en un subdirectorio poco predecible con un nombre poco predecible), pero yo prefiero configurar mi servidor web (Apache, Nginx, etc.) para que bloquee el acceso a dicho fichero.

    Saludos.
    Iñaki.

    1. Avatar de David Aguilera

      Buenos días, Iñaki.

      Muchísimas gracias por tus dos aportaciones: tienes toda la razón del mundo ? He actualizado el comando git de la entrada con tu recomendación y he añadido un pequeño aviso para que seamos conscientes que, si volcamos el SQL en el directorio de WordPress, hay que protegerlo.

      ¡Un saludo desde Barcelona!

Deja una respuesta

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

He leído y acepto la política de privacidad de Nelio Software

Tus datos personales se almacenarán en SiteGround y serán usados por Nelio Software con el único objetivo de publicar tu comentario aquí. Con el envío de este comentario, nos das el consentimiento expreso para ello. Escríbenos para acceder, rectificar, limitar o eliminar tus datos personales.