Copias de respaldo con Git

Copias de respaldo con Git

0 327

Disponer de copias de seguridad de nuestra web puede salvarnos de más de una situación peliaguda. Es algo que ya hemos discutido múltiples veces en este blog y que nunca me canso de repetir. A pesar de la relevancia que tienen las copias de respaldo, (creo que) nunca hemos hablado de de qué manera 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:

Sin embargo, el día de hoy me agradarí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 a lo largo del Contributor Day de la WordCamp Barcelona. Si, como , eres un usuario de Linux (o UNIX por lo 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. ¿Qué es eso? Un sistema de control de versiones (VCS por sus siglas en inglés) es un sistema que guarda todos los cambios que se realizan sobre un repositorio (siendo un repositorio un conjunto de ficheros). Esta es la teoría. Veamos de qué manera funciona todo esto con un fácil 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 archivo.
  3. Editamos el fichero-1.txt y le agregamos texto. Nuestro VCS guardará la nueva versión del archivo.
  4. Añadimos un segundo fichero fichero-2.txt y un directorio llamado carpeta. Nuevamente, 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 describo no semeja diferir demasiado de lo que hacemos en nuestro PC frecuentemente, ¿no? Creas archivos, los modificas, los eliminas… nada nuevo. Lo interesante del sistema de control de versiones es que podemos acceder a los momentos anteriores: aunque yo haya borrado el fichero-1.txt y, por lo 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 de esta manera 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 deja recuperar estados precedentes, de una manera sencilla y cómoda. En mi opinión, esta funcionalidad por si acaso sola ya es bastante chula. En verdad (y por si no lo sabías), Dropbox incluye este tipo de control de versiones: dado un archivo cualquiera dentro de tu directorio Dropbox, puedes recuperar versiones precedentes del archivo de tal forma que, en el 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 dos mil cinco 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 peculiaridades son:

  • Registro de cambios. Cuando subimos una nueva versión de un archivo de texto plano (lo que normalmente es el código fuente de un archivo, vaya), siempre tendremos información sobre qué cambios concretos se han hecho. Esto desea decir que podremos ver qué lineas se han añadido, cuáles se han eliminado y cuáles se han modificado. Por si fuera poco, los cambios suelen acompañarse de un mensaje que sirve como resumen de los cambios realizados. Si somos ordenados y pulcros, el registro de cambios de Git nos permitirá saltar de una versión a otra cómodamente y velocidad.
  • Desarrollo distribuido. El objetivo de utilizar Git es que varias personas puedan trabajar sobre un mismo repositorio a la vez y que todas y cada una contribuyan a él. Es de suponer que cada entre los diferentes desarrolladores estará trabajando en una funcionalidad o bien 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 conseguir los cambios hechos por otros. Además de esto, Git deja tener una copia local de todo el historial de desarrollo, con lo cual podemos favorecernos del sistema de control de versiones aun si no tenemos conexión con el servidor central.
  • Fusión de versiones automática. ¿Qué ocurre si, en este entorno distribuido con múltiples desarrolladores, 2 personas editan un mismo fichero? Es obvio que los cambios que ha hecho uno pueden pisar los del otro… ¿Qué versión guardamos? ¿Qué hacemos? En la mayor parte de los casos, Git se encargará de solventar de forma automática el problema, produciendo 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é vale Git. Ahora vamos a ver de qué forma usarlo para efectuar copias de seguridad, pero si eres un desarrollador y no lo estabas utilizando en tus proyectos… en fin, ¡espero que a partir de ahora lo hagas! Si deseas aprender un tanto más de qué manera funciona y dominas el inglés, acá tienes un fantástico tutorial de GitHub para aprender a usar Git en uno minutos.

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

Copias de seguridad con Git

En precedentes entradas hemos hablado de la relevancia que tienen las copias de respaldo, singularmente cuando las cosas se tuercen y necesitamos recobrarnos de manera rápida. La primera duda que aparece cuando uno se propone crear copias de seguridad es… vale, haré estas copias, pero ¿copias de qué? ¿De mis complementos? ¿De mi tema? ¿De mi base de datos? Recuerda que lo esencial de una copia de seguridad es que te permita recuperarte velozmente en caso de necesidad, con lo que lo mínimo que va a deber incluir es todo lo que es único en tu instalación de WordPress:

  • Directorio wp-content/uploads. Ahí tienes, por defecto, todos los archivos que subes a tu librería multimedia (imágenes, vídeos, ficheros comprimidos…)
  • Fichero wp-config.php. Configuración de tu WordPress como, por poner un ejemplo, los credenciales para acceder a la base de datos.
  • Fichero .htaccess. Configuración de servidor relacionada con tu WordPress. Por servirnos de un ejemplo, si usas algún tipo de Backlink permanente que no sea el por defecto, tendrás ciertas reglas esenciales en este fichero. Asimismo 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… resumiendo, todo lo que es importante y que (seguramente) sería imposible llegar a restaurar a mano, está en la base de datos.
  • Tema hijo (o bien tema a medida). Si has creado un tema hijo para amoldar ciertos apartado del tema que utilizas en tu web, también te va a 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 y cada uno de los complementos que hayas instalado en tu tema. La mayoría de ellos van a ser, probablemente, del repositorio oficial de plugins de WordPress, pero tal vez otros sean de pago y los hayas logrado de otras fuentes. Tenerlos todos en la copia que crearemos te ahorrará el tiempo de procurarlos, descargarlos y volverlos a instalar en tu página web en el 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. Nuevamente, tenerlos en la copia de seguridad hace tu vida más cómoda.

Y ya puestos, si guardaremos todo el directorio wp-content (con los contenidos de la librería multimedia, los plugins y los temas), la base de datos, ciertos archivos de configuración de WordPress… ¿por qué razón no guardamos totalmente todo WordPress?

  • WordPress por norma general. Si leíste mi entrada sobre de qué forma recuperar una instalación hackeada, supongo que viste que una de las cosas a hacer es reinstalar un WordPress limpio. Si tenemos totalmente todo WordPress (el core, los plugins, los temas, las imágenes, la base de datos…) en una misma backup, ¿para qué perder el tiempo en bajar cada uno de los componentes uno a uno y configurarlo todo para dejarlo como anteriormente?

Llegados a este punto, espero que ya comiences a tener una idea de de qué manera Git te puede ayudar a crear y gestionar tus copias de respaldo. La propuesta que te planteo es muy sencilla: basta con hacer que el directorio donde tenemos instalado WordPress sea nuestro repositorio y que completamente todos los archivos que contiene estén controlados por Git. Ni más, ni menos.

Configurar Git a fin de 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é archivos hay que tener controlados. Como ya hemos visto, son todos, así que agregaremos todos y cada uno de los archivos (ocultos o bien no):

git add git add[^.]

Si ahora ejecutásemos git status vamos a poder ver que todos los ficheros están ya controlados por Git:

On branch masterInitial commitChanges 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 y cada uno de los cambios para que se cree un punto de restauración” en nuestro backup:

git commit -all -m "Primera backup de nuestra web".
Any questions? de Matthias Ripp
¿Va todo bien? Si necesitamos tomarte un reposo, adelante, mas ya prácticamente hemos acabado :-) Imagen de Matthias Ripp.

Qué hacer cuando hay cambios en nuestra web

Vamos a echar una ojeada al estado de nuestro repositorio tal y como está ahora con git status:

On branch masternothing to commit, working directory clean

Tal y como podemos ver, nos señala 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 tras estos cambios echamos una ojeada de nuevo vamos a ver lo siguiente:

On branch masterChanges 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.phpUntracked 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 termina de advertir que el fichero wp-config.php ha cambiado (Changes not staged for commit) y que hemos añadido un nuevo complemento 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 complemento a su control y hacer nuevamente commit de todos los cambios:

git add wp-content/plugins/ejemplo/git commit -a -m "He instalado 'ejemplo' y actualizado wp-config pues..."

¡Y ya está! Ya tenemos un segundo punto de restauración. Fíjate que toda vez que hago una copia de seguridad manualmente le agrego un mensaje (parámetro -m). En el futuro, estos mensajes me pueden ser útiles para saber por qué creé una backup 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 y cada uno de los ficheros de tu instalación de WordPress. No obstante, 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 archivo más de cualquier instalación). ¡Veamos cómo!

Puedes exportar la base de datos como más te guste. En mi caso, siempre empleo 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 archivo donde deseas guardarlo todo /wordpress/database.sql (si el servidor de base de datos no está en exactamente la misma máquina donde tienes WordPress instalado, deberás apuntar el host).

Cuando el proceso haya acabado (acostumbra a ser bastante veloz), tendrás en la raíz del sistema un archivo de texto plano con el export de tu base de datos. Así, sólo nos queda agregarlo a Git y hacer el commit:

cd /wordpress/git add database.sqlgit commit -a -m "Añadida la base de datos a la copia de seguridad"

De ahora en adelante, toda vez que deseemos crear una copia de respaldo de todo, va a bastar con regresar a exportar el estado actual de la base de datos, asegurarnos que todos y cada uno de los ficheros nuevos (nuevos plugins, temas, o bien elementos de la media library) estén incluidos y hacer commit.

cd /wordpress/mysqldump -uUSUARIO -pCONTRASEÑA BD > /wordpress/database.sqlgit add git add[^.]git commit -a -m "Mensaje..."

Guardar la backup 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 dejará volver a ella velozmente en el caso de necesidad. El inconveniente 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 servirnos de un ejemplo. Si guardamos la backup así como la instalación de WordPress únicamente y no hacemos nada más… puesto que, en resumen, en caso de que nos hackeen la web nos pueden borrar las copias de respaldo (o bien hacerlo nosotros por error), o si el ordenador peta vamos a perder no solo la web, sino más bien asimismo el salvavidas que habíamos preparado. Está claro, puesto que, que debemos 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 inconveniente que te comentaba. ¿De qué forma hacemos eso?

Existen varios servicios en Internet que nos dejan montar repositorios Git. Los 2 más conocidos son, seguramente, GitHub y BitBucket. Ambos nos dejan tener repositorios públicos (todo el planeta tiene acceso a su contenido) y privados (sólo , o bien quienes queramos, podremos acceder a él). ¿Cuál es la diferencia entre ellos? Con GitHub, los repositorios para proyectos públicos (por norma general, proyectos software libre) son sin coste, al tiempo 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 deseamos es crear copias de respaldo de nuestro site y esto, en principio, es una información privada a la que absolutamente nadie más debería tener acceso… vamos a utilizar BitBucket.

Crear un nuevo repositorio en BitBucket

Lo primero que debes hacer es crearte una cuenta en BitBucket (si aun 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 precisar un nombre y comprobar que su tipo sea Git”.

Una vez el repo está creado, vamos a poder 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 2 repositorios: uno en local que es el que contiene las copias de respaldo y otro remoto en BitBucket que está vacío. ¿Qué queda? Puesto que, simplemente, enlazar uno con otro. Si echas una ojeada a la anterior atrapa de pantalla, vas a ver que te explica de qué manera configurar Git en tu PC local:

mkdir /path/to/your/projectcd /path/to/your/projectgit initgit remote add origin https://davilera@bitbucket.org/davilera/wprincipiante.es.git

El único comando que nos interesa es el último, pues 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: apuntarle a nuestro repositorio local que todos los commits deben guardarse en el repositorio remoto de BitBucket.

Finalmente, una vez esté todo configurado solo 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 una ojeada a nuestro repositorio en BitBucket, veremos lo siguiente:

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

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

Lista de
En el apartado Commits” podemos ver todos y cada uno de los commits que hemos hecho en nuestro proyecto. En nuestro caso, cada commit es una backup.

Resumiendo…

Las copias de seguridad nos dejan recuperarnos velozmente de un desastre. El día de hoy hemos visto como Git, una herramienta de control de versiones habitualmente utilizada para administrar proyectos software, nos puede asistir a crear y administrar nuestras copias de respaldo. También hemos visto que podemos emplear un servicio como BitBucket para guardar estas copias en un sitio remoto y confiable.

Ahora que bien sabes toda la potencia que hay detrás de Git, ya no tienes disculpa para no hacer copias de respaldo de tu página web. En una próxima entrada, te voy a explicar cómo puedes mecanizar todo el proceso y algún truco adicional que seguro te va a encantar

Imagen señalada de Theophilos Papadopoulos.

 

NO COMMENTS

Leave a Reply