Madre mía que semanita!

Si esta semana hemos estado tan ausentes en BlogsFarm es debido a que ha coincidido una fatal casualidad: La migración de los servidores al hosting español de Ferca (Geniales de momento con David Carrero a la cabeza ayudándonos en todo momento), y una caída (mejor dicho destrucción masiva) de los servidores de USA junto con una total pérdida de datos el día de antes de la migración.

Así que creo que no es necesario que os lo diga: Una buena política de backups es totalmente necesaria en una empresa. Y más cuando todos sus activos, todo lo que le produce dinero, son datos y ficheros alojados en un servidor remoto :D.

Os contaré los hechos porque seguramente os sirvan de ayuda. Es mejor escarmentar en cabeza ajena :D.

Los antecedentes

Los blogs de BlogsFarm estaban alojados hasta el momento en hosting americanos. Concretamente Micfo, LunarPages y AwardSpace. El motivo es por la funcionalidad que tienen (Cpanel gratis) y el precio. Digamos que el mismo servidor dedicado en Ferca cuesta el doble :D.

La razón de tener más de un hosting era para “no poner todos los huevos en la misma cesta” y que si algun servidor se caía no estuvieran todos los blogs offline. Solo el servidor de Micfo era dedicado y alojaba las webs con más visitas. Los otros eran planes compartidos.

El servicio técnico es 24 horas y su respuesta es inmediata… Pero claro, hay que llamar a USA, con el consiguiente coste, y quieras que no la conversación nunca es tan fluida como en Castellano.

El caso es que por muy bonitos que pintaran los hostings americanos, finalmente decidimos migrar a España. Sobre todo por la amenaza de la LOPD. No queríamos pagar esos 900 mil euros que dicen por alojar datos en servidores no auditados (Además Micfo no estaba en el safe Harbour)

Después de analizar y pedir recomendaciones escogimos un servidor dedicado en Ferca. David Carrero y los suyos nos atendieron de forma genial y el lunes pasado por la mañana tenían preparado nuestro servidor con Plesk.

Los hechos

El servidor español lo teníamos para el lunes. Por lo que planificamos la migración de blogs durante esa semana. El plan era comenzar a hacer backups actualizados de los diseños y bases de datos el martes. Miercoles, jueves y viernes migrar los blogs a el nuevo servidor. Y durante el fin de semana, cambiar las DNSs de los dominios para que este lunes todos los que visitaran los blogs se encontraran con el nuevo alojamiento sin que se dieran cuenta.

Por supuesto no dijimos nada a nuestro hosting en USA, no fuera a ser que nos hicieran alguna putada :D.

El problema comenzó cuando el lunes por la noche se produjo una caída de los servidores. Cuando llamamos al servicio de soporte se confirmó la catástrofe:

“All data in server was lost”

Y entonces comenzó el pánico.

Lo primero que hicimos fue comprobar los backups que teníamos de los blogs:

  • Los diseños los teníamos todos en local, pero no teníamos el backup de la estructura exacta de directorios en todos los blogs, sino más bien los logos, imágenes etc.
  • De las bases de datos, teníamos el último backup de mediados de abril: es decir, casi dos meses de artículos perdidos. Así que fuimos corriendo a Google Reader a recuperar los posts de la caché. Menos mal, que los redactores también tenían copia de los posts en local. Por lo que hemos podido recuperar todo el contenido de los blogs. Sin embargo al no tener backup de la base de datos… digamos que el proceso no ha sido tan inmediato como importarla de nuevo con PHPMyAdmin.

Nuestra política de Backup anterior

Era muy vaga. De vez en cuando hacíamos backup, pero no estaba planificada. Aún así menos mal que siempre guardábamos todos los artículos y diseños. Pero eso no basta. Es esencial hacer backup completo de base de datos y ficheros por lo menos cada semana.

La restauración de datos

Lo primero fue restaurar el estado de todos los blogs en abril. Para ello, creamos nuevos espacios de dominio en el nuevo hosting. Y aprovechando las horas de la propagación de los DNSs nuevos, restauramos nuestros blogs más visitados que sólo estuvieron caídos unas horas.

Si no sabes como restaurar un blog de WordPress. Te recomiendo este artículo de su web.

Después seguimos restaurando los demás blogs, hasta que logramos el primer hito: Recuperar el estado de mediados de abril de todos los blogs.

Una vez hecho esto comenzó la tediosa tarea de recuperación de post manual: Con la ayuda de google Reader hicimos un backup de todos los artículos de los blogs. Fuimos recuperándolos teniendo cuidado para que mantuvieran su permalink: No queríamos perder posicionamiento :D.

Una vez conseguido restaurar todo el contenido de los blogs, faltaban los detalles de diseño. Había que dejar todos los blogs como estaban. Lo bueno, es que gracias a esto hemos incluido algunas mejoras: Por ejemplo ya hemos actualizado el diseño de erenovable, y en locuraviajes hemos incluido una funcionalidad que queríamos desde hace un montón de tiempo: Explora el mundo. Post geoposicionados.

nuevodisenoerenovable.jpg

exploraelmundo.jpg

Las conclusiones

Una de las razones que me han llevado a escribir este artículo es que escarmentéis en cabeza ajena. ¿Cuantos de vosotros hacéis un backup periódico? ¿Que políticas de backup mantiene vuestra empresa? ¿Tienes una red de blogs con servicio de backup periódico en el hosting?

Desde luego nosotros hemos escarmentado. Hemos sufrido mucho, pero al final ya estamos en España. Esperemos mejorar además en posicionamiento gracias a nuestras nuevas IPs españolas.

Por lo menos ni el tráfico ni nuestras ganancias no se han visto afectadas en exceso gracias a la rápida respuesta que tuvimos y a la decisión de recuperar primero los blogs más visitados. En total perdimos un 60% del tráfico el primer día de la caida, un 30% el segundo, un 15% el tercero y un 5% el cuarto.

Felices backups y migraciones. 

 

12 Responses to La importancia de un buen Backup. Migración de los servidores: Parte 2

  1. Pues… da gracias porque por lo que cuentas podía haber sido un auténtico desastre.

  2. GONZO says:

    Muchas gracias por el consejo Gonzalo.

    Si te sirve de algo, ya mismo estoy haciendo la copia de seguridad mensual! 🙂

    En mi caso hago copias cada 2 3 o 4 semanas, copias totales, que me descargo y guardo en todos los PCs de casa y en un HD externo que tengo. Con esto me siento seguro.

    Más luego los servidores tienen raid con dobles discos duros funcionando como uno, por lo que es imposible que “peten”. Lo que si puede ocurrir es un incendio o algo así… Por eso es fundamental tener copias.

    Gracias y un saludo!

  3. Troy says:

    Me alegro de que hayáis salvado la papeleta… sólo de leerlo uno empieza a sentir sudor frío.

  4. zordor says:

    Yo hago backup todos los dias, 8 horas al dia y algunas semanas 24×7 jeje y es que trabajo en backup unica y exclusivamente con el software Veritas Netbackup. Especializacion a saco, eso si os recomiendo que si os podeis permitir pagar las licencias, lo compreis 😀

  5. J. Robles says:

    Yo voy a dar otra alternativa para el que quiera currárselo un poco pero ahorrarse el dinero en licencias. En mi caso tengo dos procesos planificados uno en el servidor y otro en mi PC que automáticamente me permiten descargar la info crítica.
    – En el servidor tengo un cron que crea backups cada n horas y en “otras ocasiones” que hay grandes modificaciones de la BD.
    – Otro cron se encarga de copiar los n últimos backups a un directorio que está dentro de la home de un usuario que tiene acceso por ssh y nada más.
    – En el PC un cliente hecho en Java y que usa la librería ganymed-ssh2-build211beta4.jar para conectarse al servidor y descargar lo que haya en el directorio anterior.
    – Un proceso Windows que ejecuta la aplicación Java todas las noches.

    Es relativamente sencillo y sin pagar un duro tengo una copia de seguridad del servidor actualizada a diario.

Leave a Reply

Busqueda de Artículos

Usa el formulario de busqueda:


Aún no encuentras lo que buscas? Dejanos un comentario en un artículo y contactaremos contigo!

Lectores

Gracias por seguir los artículos de CanguroRico.com. Puedes suscribirte por RSS en RSS feed.