Revisión de mi estrategia de backup

Desde hace varios años tengo implementado un sistema de backup automático para mis datos importantes. Pero hechos recientes me han empujado a revisar mi estrategia, encontrando dos puntos a tener muy en cuenta:

  • Mi sistema de backup tenía importantes carencias
  • Mis necesidades actuales han cambiado

Nuevos tiempos requieren nuevos planteamientos, así que aproveché la caída de uno de los discos del NAS para rediseñar e implementar un nuevo sistema de backup de datos.

Como consejo para cualquiera que esté buscando una mejor manera de salvaguardar sus datos, diré que es fundamental elaborar una lista personal de necesidades, ya que las soluciones van a depender de ellas. Éstas son las mías:

  • Tiene que ser automático. Ya tengo bastantes preocupaciones en mi cabeza como para sumar una mas. Si tengo que acordarme de conectar un disco duro externo cada cierto tiempo para volcar mis datos, no lo haré nunca.
  • Tiene que estar redundado. No quiero tener una sola copia, quiero al menos dos en diferentes lugares. Las probabilidades de que, llegado el momento de necesidad, acceda a la primera copia y haya algún problema son altas. Suelo estar gafado en esto.
  • Me tiene que proteger de desastres físicos como sobretensión, robo, incendio, o inundación. Por lo tanto, es fundamental tener una copia fuera de casa, en lugar remoto.
  • Me tiene que proteger de malware/ransomware, así como de corrupciones esporádicas de datos debido a bugs en las aplicaciones que manejan los archivos.
  • Me tiene que proteger de mis propias torpezas. Puedo llegar a borrar o alterar un archivo de forma accidental y sin darme cuenta. Es más, no tengo por qué descubrir el problema al momento, pueden pasar semanas o meses hasta que vea que ha pasado algo, cuando quiera volver a abrir un archivo y vea que no existe o está corrupto.

Solución Antigua: Centralizada, basada en Historial de Archivos de Windows + CloudBerry Backup

En mi ecosistema, las máquinas que contienen datos susceptibles de necesitar copia de seguridad son todas Windows 10. En el pasado tuve muy buenas experiencias con Time Machine de OS X, así que en su momento diseñé la solución confiando en que el intento de clon de Microsoft, su Historial de Archivos, sería igual de bueno. La solución que describiré ahora es la que he estado usando durante unos 3 ó 4 años, y que sólo hace unas pocas semanas descubrí cuán equivocado estaba con ella.

La solución

Se trataba de una solución centralizada en el NAS, y con una segunda copia de seguridad en un servicio de almacenamiento remoto.

¿Por qué centralizada en el NAS? Por aquel entonces mi conexión a Internet era asimétrica con unos 5 Mbps de subida, por lo que no quería tener que dejar los clientes encendidos a la espera de que completaran la copia de seguridad al almacenamiento remoto. Volcar una tarjeta de 20 GB con fotos podía suponer una carga de 9 horas al almacenamiento remoto, por lo que mi estrategia era que los clientes hicieran una copia local al NAS, mucho más rápida, y sería el NAS quien se encargue de forma centralizada de agrupar las copias de todas las máquinas y subirlas al almacenamiento remoto.

Diagrama de solución antigua: copias centralizadas en el NAS, basado en Windows File History + CloudBerry Backup

Cada cliente hacía una copia con Historial de Archivos a un recurso compartido en el NAS por Samba, y más tarde el NAS sincronizaría la copia de forma centralizada con BackBlaze B2 usando CloudBerry Backup para Linux. Todo sonaba bien.

Internet, donde el NAS almacena la segunda copia de seguridad

Los problemas

Sin embargo, recientemente he descubierto que Historial de Archivos no es fiable y tiene múltiples carencias. Para mi caso de uso, éstas son las más importantes:

  • Fallos silenciosos: no avisa de ninguna manera de que la copia ha ido mal, y desde la propia herramienta se indica la copia como completa aunque hayan ocurrido errores. Hay que mirar a mano en el Visor de Sucesos, mensaje por mensaje.
  • No copia archivos que incluyan ciertos caracteres, que sí son admitidos por el filesystem de Windows.
  • No copia archivos con rutas que superen los 255 caracteres en destino, y como añade timestamp a los nombres de archivo, aumenta el riesgo. El timestamp añade la nada despreciable cifra de 26 caracteres al nombre de archivo.
  • No hay forma de que reintente los archivos fallidos: re-run, disable/enable, reconfigure no funcionan. Una vez que un archivo falla, no lo vuelve a intentar nunca más.
  • La única manera de reintentar es destruir toda la copia y hacerla de cero, tardando horas, dejando los datos desprotegidos todo ese tiempo, y causando duplicados en el almacenamiento remoto debido al timestamp en los nombres de archivo.
  • No hace un almacenamiento inteligente de versiones: las opciones se limitan a retener todas las copias en los últimos X meses, pero sin tener opción a disponer de mayor granularidad para los días más cercanos, o conservar una copia al mes para los últimos meses o años.

En mi caso concreto, descubrí que faltaban en torno a 12.000 archivos en mi copia de seguridad, estando afectadas todas las fotografías tomadas entre los años 2010 y 2014, entre otras cosas, y que nunca habían tenido realmente copia de seguridad. Si hubiera ocurrido un fallo en mi almacenamiento principal, hubiera perdido 5 años de fotografías.

Conclusiones

Al descubrir estos problemas, especialmente que había estado sufriendo durante años una sensación de falsa seguridad al pensar que tenía copia de ciertos archivos que realmente no tenían copia, concluí lo siguiente:

  • Debo verificar las copias de seguridad de una manera más exhaustiva. No sólo debo comprobar que la copia se pueda restaurar, también debo comparar el contenido de la copia contra el origen para verificar que los datos son correctos. Al menos debería comprobar nombres de archivo, tamaños, y cierta verificación inteligente en las fechas de modificación. Idealmente también podría calcular hashes del contenido y comparar dichos hashes para verificar que no existe corrupción de datos.
  • Debo diseñar una nueva solución técnica de copias de seguridad, adaptada a mis necesidades actuales y con herramientas más fiables.

Solución Nueva: Descentralizada, basada en Duplicati

Uno de los problemas de la solución anterior es que todo se basaba en una herramienta fallida: Historial de Archivos de Windows. Necesitaba otras herramientas. Una primera aproximación era pasar a utilizar CloudBerry Backup directamente en los clientes. Sin embargo, debido al coste de licencias ($50 por máquina) descarté esta opción, ya que no es lo mismo pagar una única licencia para el NAS y centralizarlo todo ahí, que pagar N licencias, una para cada cliente.

Otro de los problemas es que, al ser una solución centralizada, el NAS se convierte en punto único de fallo (single point of failure). Si el NAS cae, tanto la copia del NAS como la copia remota dejarían de funcionar. Toda la solución se basa en que una máquina concreta funcione correctamente todo el tiempo. Pensé que sería conveniente evitar eso.

La solución

Actualmente dispongo de una conexión de fibra simétrica con 600 Mbps de subida, por lo que la necesidad inicial de centralizar las copias en el NAS desaparece. Ahora mismo, volcar una tarjeta con 20 GB de fotos suponen unos 5 minutos de tiempo de carga al almacenamiento remoto, frente a las 9 horas que necesitaba hace unos pocos años. Es perfectamente asumible que ahora sean los propios clientes los encargados de sincronizarse con el almacenamiento remoto directamente, liberando al NAS de hacer esta tarea.

Esto además tiene otro importante beneficio, y es que cada cliente mantendrá dos copias de seguridad independientes. Si una de ellas se vuelve corrupta por la razón que sea, la otra no tiene por qué estarlo también. En el antiguo esquema, si la copia del NAS se volvía corrupta, lo que se subía al almacenamiento remoto también lo iba a estar, ya que era una «copia de la copia».

Sobre el software, tras investigar diversas herramientas que soportaran tanto copias por red como copias a servicios de almacenamiento remoto como Amazon S3 o BackBlaze B2, y que tuvieran un coste asumible, me decanté por Duplicati.

Duplicati es un proyecto GNU/GPL y multiplataforma, que proporciona una solución de copias de seguridad fiable, robusta, con soporte para múltiples destinos, incluyendo los servicios de terceros más populares. Encontré muy buenas referencias de él, hay mucha gente contribuyendo, y no vi grandes bugs en el historias de cambios del proyecto en GitHub. Por ello, decidí darle una oportunidad.

Diagrama de solución nueva: copias descentralizadas, basado en Duplicati

He instalado Duplicati en cada cliente, definiendo dos copias de seguridad:

  1. Una copia diaria al NAS por Samba, con almacenamiento inteligente de versiones. Cada cliente copia a un directorio diferente.
  2. Una copia diaria a BackBlaze B2, con almacenamiento inteligente de versiones. Cada cliente copia a un bucket diferente.

Conclusiones

Llevo unas semanas, y hasta la fecha mis impresiones son muy positivas. Las copias se completan con bastante velocidad, tengo dos destinos independientes, y por lo que he podido comprobar, esta vez sí que están todos mis archivos importantes incluidos en la copia. Además, cuando ocurre un problema, se visualiza una notificación en el cliente, aunque hubiera estado bien poder configurar un email donde recibir y centralizar tanto notificaciones de copia completada como de copia fallida. Quizá podría contribuir al proyecto creando esa funcionalidad.

Siguientes pasos

Lo más importante es asegurarme de que las copias de seguridad siguen siendo fiables con el paso del tiempo. Por ello, debo diseñar un sistema de comprobación del contenido de todas las copias, tanto del NAS como del almacenamiento remoto, y no solo debe comprobar que la copia sea restaurable, sino que estén todos los datos, y que estos sean correctos. Y por supuesto, tiene que hacerse de forma automática. Si no me puedo fiar de mí mismo para hacer una copia de seguridad manual de forma regular, tampoco puedo fiarme de que vaya a estar comprobando las copias cada mes. Quizá lo haga el primero, pero os aseguro que después me olvidaré.

El sistema de comprobación debe:

  • Restaurar los datos automáticamente desde cada origen: NAS y B2.
  • Comprobar que todos los archivos del origen se encuentran en la copia.
  • Comprobar que los tamaños y fechas de archivo entre el origen y la copia se corresponden.
  • Enviar una notificación por email cuando la verificación sea correcta.
  • Enviar una notificación por email cuando haya ocurrido un problema de verificación junto con un informe que contenga el detalle, enumerando cada archivo con problemas y el error detectado.
  • Ejecutarse de forma automática y periódica, inicialmente una vez al mes.

Conclusiones finales

Si hay algo peor en informática que la falta de seguridad, es la falsa seguridad. La falsa seguridad es cuando igualmente no estás seguro pero ni siquiera lo sabes, y por lo tanto asumes riesgos que de otra manera no hubieras asumido. En mi caso estaba tranquilo y confiaba en mi sistema de copias de seguridad, cuando en realidad hubiera perdido muchos datos únicos en caso de catástrofe.

Afortunadamente no lo he llegado a sufrir, lo he detectado a tiempo (de casualidad, dicho sea), y he podido ponerle remedio. Pero otros podrían no correr la misma suerte que yo.

Las necesidades cambian con el tiempo, y la fiabilidad de las soluciones también. Revisa tus estrategias de vez en cuando, comprueba que tus soluciones sigan siendo buenas y cubran tus necesidades, y cambia tus soluciones cuando no sea así. Lo que ayer valía, hoy puede que no lo haga. El cambio es la única constante.

OpenSSL Heartbleed, descripción gráfica

A veces es difícil explicar una vulnerabilidad a alguien que no tiene muchos conocimientos sobre seguridad. Cuando esto ocurre, una imagen suele funcionar mejor que una explicación técnica.

Esta imagen la he encontrado hoy y me ha encantado:

heartbleed_explanationRecordad que las versiones afectadas son:

  • OpenSSL 1.0.1 – 1.0.1f
  • OpenSSL 1.0.2-beta

Y que las siguientes versiones NO están afectadas:

  • OpenSSL 0.9.8 (all branches)
  • OpenSSL 1.0.0 (all branches)
  • OpenSSL 1.0.1g

Para actualizar en Ubuntu/Debian:

Si vuestro servidor utiliza OpenVPN-AS, que sepáis que utiliza sus propias librerías que tendréis que actualizar de forma independiente. Más información aquí:

OpenVPN Docs: Heartbleed vulnerability on Access Server 1.8.4 –> 2.0.5

Otros enlaces de interés:

Página oficial OpenSSL Heartbleed

Heartbleed Test

 

Instalar disco SSD en iMac 27″ Late 2009

Recientemente he cambiado el disco duro original de mi iMac por un SSD, y como no es lo mismo contarlo que vivirlo, quiero compartir con vosotros los pasos que he dado para que los indecisos se animen. La pena es que apenas hice fotos, pero la operación es sencilla.

Lo primero, la víctima:

  • iMac 27″ Late 2009
  • Core i5 2,66GHz
  • 4GB DDR3
  • ATi HD4850
  • 1TB Seagate

Imagen enviada

Y lo segundo, el juguete:

  • OCZ Vertex 2 120GB SATA-II

Imagen enviada

Material necesario:

  • Ventosas de los chinos (2)
  • Clips de papelería (2)
  • Destornilladores Torx
  • Destornillador de estrella
  • Resistencia de 470 omhios (o una sonda de temperatura de Superdrive)
  • Un poco de paciencia y muchas ganas :lol:

Pasos:

Lo primero es acondicionar una habitación libre de polvo. Aconsejo elegir una habitación fácil de limpiar, con pocos muebles/figuritas, y retirar el polvo uno o dos días seguidos. Después esperar algunas horas a que el polvo del ambiente se vuelva a posar antes de empezar la operación. Disponer también de una toalla o tela grande, que no suelte pelusas, donde dejar el cristal protector y la pantalla cuando los saquemos.

Sacando el cristal protector

  • Pegar las ventosas en las esquinas superiores del cristal protector.
  • Tirar de una esquina con decisión. El cristal sale muy fácil.

Para esto utilicé los típicos ganchos con ventosas para colgar trapos de cocina. De hecho ni siquiera compré nuevos, usé unos que llevan en los azulejos de mi cocina lo menos 5 años. Cualquier ventosa por cutre que sea nos servirá. Si no tienes nada en casa pásate por una tienda de chinos.

Imagen enviada Imagen enviada

Sacando la pantalla

  • Usar el destornillador Torx para sacar los tornillos. Lleva 4 a la izquierda, y otros 4 a la derecha.
  • Una vez retirados los 8 tornillos, deformar los clips de papelería para que nos sirvan de gancho. Usadlos en las esquinas superiores para abatir un poco la pantalla, pero ¡cuidado!, que lleva 4 cintas de datos por detrás con muy poco margen de cable.
  • Soltad las 4 cintas con cuidado, empezando por la que está arriba a la izquierda, que es la más corta. Una vez retirada esa, tendremos más espacio para abatir un poco más la pantalla y manipular el resto.
  • La cinta más grande, la que está más a la derecha, lleva unas pestañas metálicas a los lados que debeis presionar para sacarla. El resto de cintas salen simplemente tirando.
  • Con las 4 cintas sueltas podemos retirar la pantalla. Cuidado que pesa. Procurad agarrarla solo del marco, así nos evitaremos tener que limpiar huellas después.

Es bastante recomendable que el destornillador esté imantado. Si no lo está, podemos imantarlo temporalmente pasándolo por alguno de los imanes que tiene el iMac en el marco. Deberemos hacerlo por cada tornillo para que funcione. También os voy a recomendar hacer esta operación con el iMac tumbado, ya que si se os escapa un tornillo evitaréis que caiga dentro como me pasó a mí.

Imagen enviada Imagen enviada

Soltando el disco duro

  • El disco duro va fijado a un soporte con gomas para reducir las vibraciones. Primero soltamos el soporte con el destornillador Torx. Solo hay que retirar los dos tornillos superiores.
  • Soltamos todas las conexiones (3 cables: datos, alimentación y sonda de temperatura) y sacamos el disco.
  • Debemos quitar el soporte del disco duro antiguo para ponérselo al SSD. En este caso debemos retirar tanto la barra superior que hemos desatornillado antes, como los dos pivotes de abajo que encajan en los huecos del iMac.
  • Atornillamos el soporte al SSD y atornillamos el conjunto de vuelta en el iMac.

De este proceso no tengo fotos, pero es muy sencillo. Eso sí, hay que tener en cuenta un detalle. La mayor parte de los discos SSD son de 2,5″, por lo que necesitaremos un adaptador a 3,5″. La buena noticia es que éste suele venir incluído con el propio SSD. La mala es que probablemente no nos valga para el iMac. En el caso del OCZ Vertex 2, el adaptador tiene dos problemas: es demasiado corto, y utiliza una tornillería diferente. Esto me dio bastantes problemas a la hora de instalarle el soporte para discos duros del iMac. Al final lo apañé porque tenía tornillería de sobra en casa, pero en vuestro caso os aconsejo comprar un adaptador de 3,5″ que tenga la misma longitud que un disco mecánico de 3,5″ corriente, y que utilice su misma tornillería.

Imagen enviada Imagen enviada

Apañando la sonda de temperatura

  • Soltar el conector de temperatura del disco duro original.
  • Introducir la resistencia de 470 ohmios en los pines del conector.
  • Cubrir resistencia y conector con cinta aislante para que ni se salga, ni pueda hacer contacto con ninguna otra parte metálica.

La dichosa sonda de temperatura suele ser lo que más dudas genera. La sonda de temperatura no va pegada a la superficie del disco duro como muchos pensarán, sino que está dentro del propio disco duro y se lee a través de unos pines de servicio del disco. Es decir, no tenemos una sonda RTD normal que podemos despegar y volver a pegar sobre el SSD, sino que nos encontraremos con un conector. ¿Y qué hacemos con él? Si lo dejamos suelto el ventilador del HD se pondrá a la máxima velocidad, así que deberemos apañarlo. Hay gente que ha conseguido una sonda de temperatura de SuperDrive y la ha puesto en su lugar, pero son difíciles de encontrar. Yo he preferido puentearlo con una resistencia de 470 ohmnios. De esta manera se obtiene una lectura constante de 30ºC y el ventilador se mantiene a su velocidad mínima. Los discos SSD no se calientan así que realmente no necesitan ventilación alguna.

Imagen enviada Imagen enviada

Cerrando el iMac

  • Volver a colocar la pantalla en su lugar y conectar las 4 cintas de datos.
  • Atornillar la pantalla. Para esto nos puede venir bien ayudarnos de un segundo destornillador para guiar el tornillo, ya que los imanes del marco los atraen por mucho que tengamos el destornillador imantado.
  • Limpiar la pantalla interior y la parte trasera del cristal protector con un trapo para que no quede polvo atrapado.
  • Colocar el cristal protector en su sitio.

 

Video del proceso:

El video no es mio, pero es muy ilustrativo. Es el que más me gusta de todos los que he encontrado, aunque no explica nada bien la parte de la sonda de temperatura. Pero todo lo demás está fantástico:

 

Resultados:

Como se suele decir, una imagen vale más que mil palabras:

Imagen enviada

  • Tiempo de carga de OS X Lion 10.7.0: 4 segundos (presionando ALT al arranque, cronometrado desde que elijo la partición de arranque hasta que tengo el escritorio delante)
  • Tiempo de carga de Photoshop CS4: 2 segundos
  • Tiempo de carga de OpenOffice: 2 segundos
  • Tiempo de carga de Firefox, Safari, SparrowMail, Skype, Spotify, etc: menos de 1 segundo (casi instantáneo)

Ni que decir tiene que el ordenador ha cambiado completamente. Si antes iba rápido, ahora es una bala. Desde luego estoy encantado con el cambio, y recomiendo a todos los intrépidos que lo prueben.

Y para los que estén preocupados por la invalidación de la garantía, una de cal y otra de arena: el disco duro no es parte reemplazable por el usuario y Apple podría anular la garantía del equipo entero por manipulación no autorizada. Peeeeero, no hay ningún precinto interior y la operación en el fondo es tan sencilla que es 100% reversible. Yo he guardado el disco original de 1TB sin tocar, y así se quedará por si acaso.

Espero que esta guía os sirva a aquellos que estábais en dudas. ¡Ánimo! ;)

Descifrar hashes MD5 con John the Ripper y Raw-MD5

John the Ripper es una conocida herramienta de auditorías de seguridad, muy utilizada para (ejem ejem) comprobar si nuestras claves son robustas. Para ello se le proporciona un fichero de entrada con los hashes de las claves que queremos obtener comprobar, y opcionalmente un diccionario o juego de caracteres con los que realizar las pruebas.

John the Ripper no soporta de serie el tratamiento de passwords en formato MD5 simple. Es decir, no soporta un archivo de claves con formato «nombre:clave» como el utilizado en passwd. Un ejemplo:

pepe:7ef0b3c0aa6339c701ff370795873628
juan:5fc6c5c2aecd3a419109cb34ccb7da70
jorge:b662c2e331741ada2770cb885b3f696a

Para que John the Ripper funcione con este formato necesitamos parchear su código fuente con Raw-MD5, y después compilar.

Descargar lo necesario

Vamos a utilizar John the Ripper 1.7.2 y el parche Raw-MD5 para 1.7:

$ wget http://www.openwall.com/john/f/john-1.7.2.tar.gz
$ wget ftp://ftp.openwall.com/pub/projects/john/contrib/john-1.7-rawmd5-ipb2-4.diff.gz

Parchear

Descomprimimos ambos archivos y parcheamos el código fuente:

$ tar zxvf john-1.7.2.tar.gz
$ gunzip
john-1.7-rawmd5-ipb2-4.diff.gz
$ cd john-1.7.2
$ patch -p1 < ../
john-1.7-rawmd5-ipb2-4.diff

Compilar

A continuación compilamos el código fuente ya modificado. Con la primera llamada a «make» visualizaremos un listado de plataformas, donde deberemos elegir la que mejor se ajuste a nuestro sistema para la segunda llamada. En mi caso, la mejor es «linux-x86-sse2»:

$ cd src
$ make
$ make clean linux-x86-sse2

El código fuente no tiene una orden «make install» para copiar los binarios a nuestro sistema. En su lugar, se crea un directorio «run» al mismo nivel que «src» que contiene el resultado de la compilación. Podemos mover este directorio libremente a una ubicación mejor y borrar el código fuente si no lo vamos a necesitar más.

Ejecutar

Vamos a suponer que tenemos un archivo «/home/usuario/claves.txt» con el contenido que aparece en el párrafo introductorio del artículo. Para procesar sus claves haríamos la siguiente llamada:

$ ./john –format=raw-MD5 /home/usuario/claves.txt

Encendido y apagado remoto de una máquina Windows desde Linux

Vamos con una entrada rápida. ¿Quién no tiene en su casa una máquina montada con Linux y encendida 24h al día, 365 días al año?. ¿Que no la tienes?. ¡Venga ya!

(Espérate a mi super artículo sobre cómo preparar un servidor casero basado en Linux, si es que algún día lo acabo…)

Muchos de nosotros tenemos un servidor de descargas en casa montado en una máquina Linux, o incluso un router basado en Linux (como el Linksys WRT54GL), que podemos utilizar como pasarela para encender y apagar nuestro PC habitual. Supongamos que disponemos de acceso por SSH desde el exterior a nuestra máquina Linux, y que queremos encender de forma remota nuestro PC habitual para recuperar algunos documentos de su disco duro.

Necesitaremos: samba y alguna utilidad WOL:

# sudo aptitude install wakeonlan samba-client

Con esto tenemos todo el software que necesitamos. Para hacer el encendido y apagado remotos además necesitaremos conocer la IP y MAC de la máquina remota que queremos manejar.

Para despertar la máquina usaremos Wake On Lan (debe estar activado en la BIOS de la máquina a despertar):

# wakeonlan 00:11:22:33:44:55

Y para apagar de forma remota usaremos Samba:

# net rpc shutdown -t 10 -f -C «Apagando el sistema de forma remota…» -I 192.168.0.2 -U usuario%password

El parámetro «-t» expresa el tiempo de espera antes de realizar el apagado, «-f» indica forzar la terminación de todos los programas (garantiza que no se quede a la espera de algún programa y no se apague), «-I» permite establecer la IP de la máquina remota, y por último «-U» establece un usuario con permisos para realizar el apagado. Si no queremos indicar el password en el prompt podemos eliminar la última parte «%password», y la utilidad net nos preguntará la clave al estilo sudo.

En otro capítulo veremos cómo se puede acceder a esa máquina por Terminal Server (en Windows XP: Escritorio Remoto) sin necesidad de abrir puertos en el router, y con una conexión 100% cifrada. La pista de nuevo es SSH, una herramienta con mucho poder. Pero primero veremos cómo tunelizar y activar un proxy dinámico para lo que pudieramos necesitar.