El día en el que hombrelobo.com murió y otras tribulaciones sobre servidores y errores garrafales de un administrador de sistemas novato

La semana pasada destrocé el servidor donde tenía alojado hombrelobo.com y otras 30 webs que llevo. Lo que viene a continuación es un relato de esa semana eterna, de los problemas que me dio, de los errores que cometí y del sueño que perdí.

Va a ser un relato muy técnico, y posiblemente no interese a casi nadie de los que leéis hombrelobo. Pero lo escribo de todas formas, en parte para justificarme, en parte para aprender, en parte para recordarlo en el futuro.

Todo comenzó con un comando:

# chown -R root /

Los que sabéis de shell en linux, habréis visto en seguida que es un gran error. Estaba intentando arreglar un tema de permisos en el servidor donde tengo alojados los dominios, y por alguna razón, estando en root, entré ese comando. Bueno, en realidad, el comando fue algo así como «# chown -R root wp-content/uploadscd /» Lo que pasó es que debería haber dado un «enter» antes del «cd /». Pero no lo dí y  en pocos segundos todos los ficheros del servidor pasaron a ser de root …..

Por supuesto, al darme cuenta entré en pánico. Soy un novato en estas cosas de sistemas, y no suelo entrar al servidor como root. Por cosas como esta ….

Inmediatamente, contacté con dos personas: con Iván (que sabe mucho de estas cosas) y con Sergio Sainz (que también sabe mucho). Tras pensarlo un poco, ambos me dijeron que poco arreglo tenía el tema, que posiblemente la mejor solución era reinstalar todo el sistema. Gracias a ambos por la ayuda, por cierto. Un par de horas buscando en Google me reconfirmaron que tenía difícil arreglo.

En ese momento, la única solución que me quedaba era básicamente reformatear el servidor e instalar de cero el sistema. Uso un linux con Plesk. Después, tendría que recomponer todos los dominios y webs desde las copias de seguridad que tuviera.

Aquí me entró otro pánico … ¿copias de seguridad? ¿qué copias tenía? Repaso todas las copias que suelo hacer:

  • En el caso de las webs que tengo con wordpress, uso un plugin que me copia la base de datos,  llamado WordPress Database Backup. En este caso no me sirvió para nada, ya que no lo tenía en todos los sitios y sólo cubre la base de datos.
  • En el caso de hombrelobo, uso Vaultpress, que copia la base de datos de forma continua los ficheros del sitio. Tampoco me sirvió para nada, porque sólo lo uso en una web.
  • En Plesk uso copias de seguridad desde el propio Plesk a un backup externo vía FTP, que es parte del servidor de OVH.es que uso. Pero suelen ser poco confiables, muchas veces dan errores, y cada vez que he intentado usarlos el propio Plesk me da errores, se cuelga por exceso de uso de memoria y otros problemas.
  • Hace tiempo leí un artículo fabuloso sobre cómo hacer copias de seguridad de un servidor Plesk con rsync, y poco después descubrí el programa para linux (en casa uso Ubuntu) llamado Gadmin-Rsync.  Con su ayuda, hago copias diarias de tres directorios del servidor en mi PC con ubuntu en casa. Y esta es la única copia de seguridad que me sirvió para algo.

Pero dejadme que os detalle un poco lo que hago con Gadmin-Rsync. Como digo, el programa lo tengo instalado en el Ubuntu de casa, y lo que hace es una copia de seguridad del servidor con la ayuda de rsync. No de todo el servidor, sino de los siguientes directorios:

/var/lib/mysql
/var/www/vhosts
/var/named/run-root/var

El primero, /var/lib/mysql  es el que almacena las bases de datos. No es un mysqldump, simplemente es una copia de los ficheros. Pero las bases de datos se pueden recomponer fácilmente. Simplemente hay que hacer los siguientes pasos:

  1. Desconectar el servidor MySQL con un «# stop mysql»
  2. Copiar los ficheros de la copia de seguridad de cada base de datos al directorio correspondiente del servidor.
  3. Hacer un «# chown -R mysql:mysql /var/lib/mysql» para cambiar la propiedad de los ficheros al servidor de mysql.
  4. Volver a arrancar el servidor de MySQL «# start mysql»

Si no se para el servidor MySQL puede dar problemas de estabilidad.

El segundo directorio,  /var/www/vhosts,  es el que guarda todos los ficheros de las webs propiamente dichas, con excepción de las bases de datos que estaban en el anterior.

Y el tercer directorio, /var/named/run-root/var, es el que guarda en Plesk la configuración en formato texto de los DNS de todas las webs alojadas en el servidor. Yo hago copia para poder leer los ficheros de texto para luego reconstruirlos manualmente con la interface de Plesk, no para copiarlos directamente. Pero es una forma de tener toda la info, sobre todo si hacéis cambios en los DNS, en el servidor de correos, etc.

Por cierto, los ficheros los he subido al servidor con la ayuda de Filezilla, un programa de FTP que permite conexiones SFTP, más seguro.

Por ahora, con estas copias de seguridad, he podido recomponer unos 20 de las 30 webs. Hay que hacerlo una a una, poco a poco, revisando que todo esté bien, que los permisos están correctos, etc. Pero parecen que van bien. Si alguno ve algún error estos días, que me lo diga, por favor … 😀

Todavía me fallan mucho las webs de ideasdenegociosgratis y.com de viajes.mn. No sé que les pasan. Pero todos los wordpress están funcionando aparentemente bien.

No puedo recomendar suficientemente el programa para linux Gadmin-Rsync, me ha salvado totalmente de un desastre. Y es gratuito y de código abierto. No solo eso, sino que está en los repositorios de Ubuntu. Creo que es imprescindible. Y si no usáis Ubuntu en casa, posiblemente merece la pena tener un PC viejo en casa con el programa simplemente haciendo copias diarias del servidor.

Yo sigo arreglando el desaguisado. Llevo varios días infernales, vaya Semana Santa … pero al menos contento de haber podido recuperar buena parte del trabajo de varios años, que podría haber desaparecido en un momento, como lágrimas en la lluvia ….

Y seguimos aprendiendo …. fascinante este mundo de internesss … con grandes poderes, grandes responsabilidades …

13 comentarios en «El día en el que hombrelobo.com murió y otras tribulaciones sobre servidores y errores garrafales de un administrador de sistemas novato»

  1. Madre de Dios !!!! … aunque ésta no creo que te arreglara nada :O … menudo embrollo amigo. Ahora mismo me pongo a hacer copias de seguridad … y seguro que como root no voy a entrar 🙂
    Un abrazo y que sea leve lo que queda

    Vador

  2. ¡Ánimo, Eduardo, que seguro que tú eres capaz de arreglarlo!

    Menuda faena,…

    Saludos y esperamos seguir leyéndote en todos tus blogs y webs,…

  3. dropbox puede ayudarte, dependiendo del tamanyo,

    pero bueno depende de lo «hondo» que andes con Linux.

    si tienes una nube puedes mirar alguna manera de replicar el disco duro a otro servicio asi tienes una replica completa.

    suerte hombre lobo!

  4. Joder…si sigues comiéndote la capecita con estas cosas no vas a poder disfrutar de tus viajes, hompre. No vamos…que….enhoraguena por tus conocimientos ¿das clases?

  5. Hola Eduardo.

    Tengo varios sitios con wordpress activo y te comento lo que yo hago por si te sirve y te simplifica la vida 😉

    1. Tengo un cron que se ejecuta cada noche y que me hace una copia de seguridad de las bases de datos. Es un mysqldump que borra la anterior y que me deja cada noche todo en /home/backup. Así me quedan todas las bases de datos con extensión .sql fácilmente «restaurables»/transferibles a cualquier mysql

    2. Cada varios días lanzo un:
    tar -zcvf COPIA20120417.tar.gz /home

    que me genera un ficherito .tar.gz con todo lo que cuelga de home, que es donde está el anterior directorio backup y todos los sitios web que cuelgan de allí.

    Ese ficherito es el que me bajo con Filezilla o lo paso internamente a otro disco.

    La restauración en caso de problemas es rapidísima. Puedo devolver a /home todo de una tacada (tar -xvf miarchivo.tar.gz); puedo extraer sólo un sitio web, etc …

    He tenido algunos «desastres» y la verdad es que esta «solución» me ha salvado sin ningún tipo de problemas.

    Un saludo,
    Julio.

  6. Gracias Julio

    El único tema que me preocupa es que en el script del mysqldump tienes que poner las claves de la base de datos, ¿no?

    De todas formas, es buena forma, lo voy a mirar …

  7. No necesariamente.

    El estándar del comando es, por ejemplo: mysqldump -uroot -p –all-databases > /var/tmp/mysqldump.`date +%Y%m%d`.sql

    Eso te hace una copia de todas las bases de datos y no necesitas poner claves.

    Saludos,
    Julio.

  8. Sudores es lo que le entran a uno cuando empieza a ver algún error de este tipo. La verdad que ver como el trabajo de tanto tiempo se puede ir al traste en un segundo, te deja con una buena cara de susto.

    De todo esto, si que se saca como conclusión que se aprende bastante.

  9. como dice Julio, la mejor opción es la de mysql, aunque si tienes que estar descargándola continuamente desde el servidor puede ser un problema (con bbdd grandes).

    Otra opción, hacer un mysqldump, cargarlo en una tabla que no se use más que para esto, y ahora si, descargar esa via rsync. Si tienes que parar todas las noches mysql pierdes tráfico, y si copias sin pararla, seguro que estás copiando una base de datos corrompida, así que cuidado :-).

Los comentarios están cerrados.