Sin embargo, puede que te salte la necesidad de hacer esto mismo bajo tu propio dominio, aunque solo sea por el detalle de branding de poder ofrecer subdominios del tipo cliente1.tudominio.com, cliente2.tudominio.com, tucasa.tudominio.com, etc… si esto es así, y tienes tu dominio en OVH, estás de suerte, sigue leyendo. Si no es así, conmino a Mr. Wu a hacerse un post compartiendo su solución bind-based ;) (o siempre puedes gastarte unos eurillos al año en mantener un dominio en OVH para este menester).

Creación del subdominio y usuario en el panel de OVH

Elegimos nuestro dominio desde el panel de control de cliente de OVH, y vamos a la pestaña DynHost, donde creamos un DynHost y un usuario de control para gestionarlo

En el subdominio, introducimos el nombre (subdominio) deseado, en la IP, 1.1.1.1 (nos permitirá comprobar luego que el actualizador funciona correctamente)

A continuación, creamos un usuario, desde Gestionar los accesos – Crear un usuario, este tendrá la forma midominio.com-loquequieras y tu contraseña. También podremos asignar si ese usuario puede gestionar un único subdominio concreto, o todos (con *). Si solo vamos a configurar máquinas propias, elegimos esta última opción. Si no, creamos un usuario por cliente, por ejemplo, para mantener la privacidad de nuestra contraseña.

Con esto ya tenemos nuestro host configurado, con una IP falsa, como podemos ver en esta imagen:

Actualización programada del host

Es hora de irnos a nuestra máquina cliente y configurarla para actualizar esta IP a la real. Obviamente el método dependerá mucho de si es una máquina Windows (tarea programada con wget por ejemplo) o Linux (un simple cron con wget).

El protocolo de OVH es compatible con el de Dyndns.org , y en su página de guías sobre DynHosts ofrecen varios métodos y softwares para actualizar esta IP. Sin embargo, me han parecido anacrónicos y complejos, teniendo en cuenta que el propio OVH te ofrece una URL de actualización genial para realizar esta misma labor con un curl básico:

curl --user "tudominio.com-usuario:contraseña" "https://www.ovh.com/nic/update?system=dyndns&hostname=micasa.tudominio.com"

¡Y eso es todo! Una única petición con tu usuario y contraseña recién creados, y el subdominio/dominio que quieres actualizar. Basta con añadirla al cron cada 10 minutillos, y listo, ya tenemos nuestro propio servicio DynDNS bajo nuestro propio dominio. Podemos comprobar tras lanzar el comando, que en el panel de OVH ya nos figura la nueva IP, y esta es perfectamente funcional:

Kudos a mi viciño Oscar M. Lage, culpable inspirador de este post, y a los amiguetes de @ovh_es

Have fun!

But what I do have are a very particular set of system management tools.
Tools I have acquired over a very long career.
Tools that make me a nightmare for processes like you.

If you let me close your window now, that will be the end of it
I will not look you up, I will not un-register you…
But if you don’t:

I will look for you
I will terminate you
And I will uninstall you.

Tras asegurarme en el último artículo de disponer de Copias de seguridad incrementales de forma automática, era el momento de enfrentar otro problema recurrente: el de la sincronización de archivos.

Desde que nació mi hija pequeña, la cantidad de fotografías y vídeos que hacemos de nuestro retoño no para de crecer de forma brutal; son datos para mí críticos, al fin y al cabo, no volverá a tener tres meses, ni dar sus primeros pasos, así que el incluir estos datos en la copia de seguridad, era un sí, o sí.

Pero es que además nos gusta poder ver estos recuerdos en cualquier momento, en casa, en la oficina, estando con el portátil de vacaciones, etc… algo que primero suplí con Dropbox (12 Gb), luego con Google Drive (35 Gb gracias a una promo), y últimamente con Mega.co.nz (50 Gb). Pero apenas ha pasado año y medio, y ya no hay nube que baste, así que necesitaba buscar otra solución, o pasar por caja, por ejemplo con el plan de 1 Tb de Dropbox.

Meet Bittorrent Sync

Antes de elegir BTSync consideré varias opciones:

• El plan de 1 Tb de Dropbpox no es demasiado caro, 9.99 €/mes, pero no me gusta pagar por lo que no utilizo, y además solo permite compartir una carpeta
• Salvo la honrosa excepción de http://mega.co.nz todos los demás te obligan a elegir una carpeta de tu PC, y todo debe ir ahí, no te permite sincronizar varias carpetas en diferentes unidades de disco, lo que a mi se me hacía insufrible.
• OVH tiene su propia solución de almacenamiento y sincronización, Hubic, com planes muy atractivos, como 25 Gb gratis, 100 Gb por 1€/mes o 10 Tb por 10€/mes, pero su cliente de sincronización colgaba mi PC hasta límites insufribles.
• La posibilidad de tener todo en un FTP privado, lo que hacía complicado su uso desde móvil, o incluso desde escritorio para el resto de componentes de la familia

Tras analizar todo esto, y ver docenas de alternativas, elegí Bittorrent Sync, evaluando sus pros y contras, por estos motivos:

• PRO: Espacio ilimitado, hasta donde llegue nuestro disco duro, sin coste adicional
• PRO: Disponibilidad de mis ficheros en cualquier dispositivo, en cualquier momento
• PRO: Velocidad de actualización estupenda, sin límites de velocidad
• PRO: Clientes de escritorio ligeros y con excepcional rendimiento
• PRO: Beta Block-Level diffs, en la mayoría de los casos se sincronizan partes de archivo modificadas, en lugar de todo el archivo
• PRO: Si no usas un servidor centralizado, coste cero
• CONTRA: Si todos los PCs están apagados, no podrás acceder a tus contenidos, mientras que en Dropbox están siempre disponibles en su Interface Web. Para esto basta con añadir a la mezcla, aparte de tus PCs habituales, un servidor dedicado que esté siempre encendido. En mi caso ya lo tengo, ya que me dedico al desarrollo web, pero un simple VPS o dedicado de 5€ al mes (o un NAS siempre encendido en casa) te sirve para esta función, igualando esta ventaja de Dropbox.
• CONTRA: No dispones de interface web para ver tus contenidos. Esto lo solucionamos con un Apache/nginx, apuntado a la carpeta BTSync. Ajustamos que liste directorios y lo protegemos con usuario/contraseña, y dispondremos automáticamente de una interfaz web de la que poder descargar contenidos, o compartir con la familia y amigos.

Si te ha convencido la idea, la instalación como cliente es trivial, descargas tu cliente BTSync para Windows, Mac, Linux, FreeBSD… y te lías a compartir carpetas como si estuvieses loco. Y hasta puedes instalarlo en tu Android, iOS o Windows Phone y lo configuras para que suba todas tus fotos y vídeos.

En el resto del artículo vamos a ver cómo definir un nodo en un servidor, para asegurarnos de tener acceso a nuestros datos aunque todos nuestros PCs habituales estén apagados en un momento dado, lo que sería un nodo always-on.

Instalación de dependencias

Instalación desde PPA

sudo add-apt-repository ppa:tuxpoldo/btsync
sudo apt-get update

Para utilizarlo en nuestro PC desde escritorio:

sudo apt-get install btsync-user

Para su uso en el servidor que utilizaremos como servidor always-on:

sudo apt-get install btsync

Instalación manual de la última versión para el servidor always-on

Adaptamos la URL de descarga a 32/64 bits según convenga

cd /tmp
wget -O /tmp/btsync.tar.gz http://download.getsyncapp.com/endpoint/btsync/os/linux-x64/track/stable
tar -xzvf /tmp/btsync.tar.gz
mv btsync /usr/local/bin/
chmod +x /usr/local/bin/btsync

Configuración del sistema

Creamos una carpeta de configuración y hacemos que el propio ejecutable genere por nosotros una configuración por defecto, que editaremos a continuación

mkdir /etc/btsync
btsync --dump-sample-config > /etc/btsync/btsync.conf

Y modificando dicho fichero /etc/btsync/btsync.conf , configuraremos el sistema a nuestro gusto. Esta configuración es mínima, muy sencilla; en mi caso, utilizo la carpeta /home/btsync como almacén de todo el sistema, y defino el usuario y contraseña de acceso a la interface web.

mkdir /home/btsync

"device_name": "Servidor OVH",
"storage_path" : "/home/btsync/",
"login" : "admin",
"password_hash" : "$1$xyz$EkmDnELo2ZAMjAxWHcsTu2",
"directory_root" : "/home/btsync/"

El password_hash podemos generarlo desde un servicio online como http://maord.com/ o desde consola con algo del estilo

openssl passwd -1 -salt xyz AQUITUPASSWORD

Ahora crearemos un fichero de configuración que nos permita iniciar, detener o reiniciar el servicio cuando queramos, en /etc/init/btsync.conf copiaremos el siguiente código:

# Bittorrent Sync server.
#
# Sync your files and stuff.

description "BitTorrent Sync"

start on filesystem
stop on shutdown

respawn

expect fork

script
exec start-stop-daemon -S -c root:root -x /usr/local/bin/btsync -- --config /etc/btsync/btsync.conf
end script

pre-stop script
killall btsync
end script

Esto nos permitirá utilizar estos comandos para iniciar, detener o reiniciar el servicio

service btsync start
service btsync stop
service btsync restart

Uso de BTSync desde el servidor

Por defecto, BTSync escucha en el puerto 8888 en todas las IPs de nuestra máquina online, así que accedemos a él, sea por IP o por hostname ( http://aqui.la.ip.servidor:8888 ), y veremos una interface de este estilo:

Podemos definir qué columnas queremos ver en la interface desde el botón de configuración

Es hora de compartir en nuestro PC la primera carpeta, obtendremos el enlace o clave BTSync desde nuestro cliente de escritorio, que por ejemplo en Windows luce así:

Pulsando el botón Copiar obtendremos una clave de carpeta, que pegaremos a continuación en la interface web de nuestro servidor, utilizando el menú superior.

El sistema nos preguntará donde queremos sincronizar esta carpeta (por defecto, nos ofrecerá la indicada en btsync.conf como directory_root)

¡ Listo ! En unos segundos comenzará la sincronización

Uso y Ventajas de la sincronización Bittorrent

A partir de ahora bastará con copiar o mover contenidos de nuestro PC a la carpeta compartida mediante BTSync para que estos se propagen automáticamente a toda al red de nodos conectados, de forma muy similar a cómo lo haríamos con Dropbox, Google Drive o cualquier otro sistema de almacenamiento online, con la ventaja de que todos ellos ( salvo la honrosa excepción de http://mega.co.nz ) te obligan a centralizar todo en una nueva carpeta que ellos crean, pudiendo únicamente sincronizar dicha carpeta, mientras que BTSync nos permite compartir múltiples carpetas en múltiples unidades de disco diferenciadas, a nuestro gusto.

En esta captura se puede ver cómo sincronizo 84 Gb de fotos y videos familiares, entre 3 dispositivos (PC de casa, PC del trabajo y un servidor en OVH). En el momento de la captura, el PC de casa (fuente original de los ficheros) está apagado, pero esto no supone ningún problema, ya que al estar el servidor de OVH siempre activo, el PC del trabajo comienza la sincronización desde él, mostrando los dos pares conectados.

Además, si en un momento dado enciendo el PC de casa durante esta sincronización, detectará automáticamente el nuevo peer, y comenzará a subir contenidos por su parte, contribuyendo al upload, y haciendo la propagación de los datos mucho más rápida gracias a la propia naturaleza descentralizada del protocolo bittorrent.

Otro punto a favor de BTSync es que basta apuntar a la carpeta BTSync que queramos un vhost apache con listado de directorios y un usuario/contraseña de acceso mediante un .htaccess, para disponer automáticamente de una interfaz web de la que poder descargar contenidos, o compartir con la familia y amigos.

Y por último, si queremos rizar el rizo, ya no es necesario ni compartir via web las fotos y videos de la peque; instalamos BTSync en el PC de abuelos, tías y primos, compartimos con ellos la carpeta como solo lectura, y basta con que enciendan el ordenador para que puedan acceder, mágicamente, a todas las nuevas fotos de nuestro retoño, en su propio PC, de forma automática.

Soporte BTSync de dispositivos

Disponemos de clientes BTSync para Windows, Mac, Linux, FreeBSD y varios dispositivos embebidos, asi como para Android, iOS, Windows Phone y Kindle Fire, asi que la compatibilidad no debería ser un problema. Obviamente, en el móvil no dispondremos de espacio para sincronizar 80 Gb de datos, pero si podemos sincronizar una carpeta de «Documentos» pequeña que queramos tener siempre accesible, disfrutando de similar comodidad a la de Dropbox.

Y para nuestras fotos y vídeos desde el dispositivo móvil, podemos configurar en el mismo una sincronización unidreccional (solo subida) que nos permita disponer de sincronización automática de nuestras fotos y videos en nuestra nube personal.

Postdata para el escritorio de Ubuntu

El soporte visual para Ubuntu puede obtenerse además de forma muy lograda, sin necesidad de utilizar la interface web, con un par de PPAs adicionales

sudo add-apt-repository ppa:tuxpoldo/btsync
sudo apt-get update
sudo apt-get install btsync-gui

Si prefieres la versión GTK sin indicador:

sudo apt-get install btsync-gui-gtk

A finales del año pasado perdí gran parte de los datos de mi empresa. Y no porque no tuviese backups, sino por ser poco paranoico. En mi caso, todos los datos de un servidor central se copiaban a otro disco por medio de incrementales. De ahí, se trasladaban a otra máquina por rsync, y esa otra máquina los enviaba a dos servidores diferentes en nuestro proveedor de hosting. En total, 4 copias diferentes en tres lugares geográficos diferentes.

Pero bastó un fallo eléctrico en la placa del servidor (que destruyó el disco original y el de copias), combinado con un bug en rsync (tenía una versión «algo» desfasada) que hacía que al no poder leer de origen asumiese que origen estuviese vacío, y eliminase en destino.

En resumen: casca la placa, se lleva por delante el disco original y el de copias. Esto pasa en un fin de semana, no estando físicamente en la oficina. El sábado salta el rsync automático desde el servidor B, que al no poder leer de A, asume que está vacio, y borra todo en B (bug de rsync). Esa misma noche, lanza los rsync contra los servidores online, al estar B vacío, vacía C y D. Cuando el Lunes llego a la oficina y voy tirando poco a poco del hilo, casi infarto.

Al final pude recuperar gran parte del trabajo gracias a la copia mensual que hago en un disco externo USB y me llevo a casa (aquella en la que menos confiaba!), pero la experiencia me sirvió para aprender que, en copias de seguridad, nunca hay demasiada paranoia y que, por supuesto, debía buscar otra opción para mis copias. Lo primero fue un RAID en los discos de ese servidor, y lo segundo un sistema de copias desatendidas en múltiples localizaciones, incrementales, y no dependientes de rsync, a quien desde ese fatídico día odio, desprecio e insulto cada vez que tengo ocasión.

Meet Amazon S3

El bajo coste de almacenamiento en la famosa nube S3 (Simple Storage Service) de Amazon, unido a su réplica automática en 3 diferentes localizaciones geográficas, lo hace ideal para el almacenamiento de copias de seguridad. Si además podemos hacer que sean automáticas, sin intervención del usuario, e incrementales, para poder volver N días al pasado sin problema, tenemos una solución robusta y fiable para poder despreocuparnos de esta tarea.

El coste es, como ya comentaba, ridículo, esta es mi factura por las copias de mis servidores dedicados del mes de Septiembre (unos 38 Gb de datos, 43 Gb contando las incrementales)

Para Windows disponemos de Duplicati, un software con interface de usuario, con lo que no me extenderé más en su uso; para linux y derivados, vamos a ver una implementación con Duplicity, un software de backup de sobrada eficiencia, y Duply, un frontend más «amigable» a Duplicity, que se apoya a su vez en la interface a AWS de Amazon python-boto

Ajustes en Amazon S3

Lo primero es crear un bucket en Amazon, los pasos desde la consola de Amazon son bastante sencillos, crear el bucket, darle un nombre y elegir región (la más cercana a España es Irlanda) y crear un usuario de acceso y contraseña:

¿Estamos? Pues pasamos al servidor.

Instalación de dependencias

Empezamos por instalar las dependencias necesarias, en Ubuntu añadiremos el PPA de duplicity para disponer de la última versión, reemplazando «precise» por vuestra versión (lsb_release -c os dará la pista).

echo deb http://ppa.launchpad.net/duplicity-team/ppa/ubuntu precise main | sudo tee /etc/apt/sources.list.d/duplicity.list
sudo apt-get update

sudo apt-get install duplicity duply python-boto

Configurando nuestra copia de seguridad

Ahora crearemos nuestra primera tarea de copias (podemos tener ilimitadas, con diferentes configuraciones). La denominaremos con el original nombre «cloud_backup»

duply cloud_backup create

Lo que nos devolverá un mensaje de confirmación similar a este:

Congratulations. You just created the profile 'cloud_backup'.
The initial config file has been created as
'/root/.duply/cloud_backup/conf'.
You should now adjust this config file to your needs.

IMPORTANT:
Copy the _whole_ profile folder after the first backup to a safe place.
It contains everything needed to restore your backups. You will need
it if you have to restore the backup from another system (e.g. after a
system crash). Keep access to these files restricted as they contain
_all_ informations (gpg data, ftp data) to access and modify your backups.

Repeat this step after _all_ configuration changes. Some configuration
options are crucial for restoration.

Básicamente nos dice que ha creado el perfil de copias en ‘/root/.duply/cloud_backup/conf’ y que más vale que hagamos una copia de ese fichero por si la máquina «revienta» en el futuro, para ser capaces de restaurar dichas copias. En general esto no es necesario, siempre que tengamos a salvo nuestras credenciales de FTP, o en este caso, de Amazon AWS. Si lo es si además queremos encriptar dichas copias, una opción útil para los más paranoicos, pero que nos saltaremos en este tutorial básico.

Una vez tenemos nuestra primera tarea de copias creada, la configuraremos editando el fichero ‘/root/.duply/cloud_backup/conf’. Indico solo los parámetros más importantes que he modificado para este tutorial:

# no vamos a encriptar las copias
GPG_KEY='disabled'
#GPG_PW='_GPG_PASSWORD_'

# Mi bucket, en Irlanda, por ejemplo, se llama "marcosbl-servers"
# y la carpeta es el alias de cada máquina, cada una tiene una carpeta
TARGET='s3://s3-eu-west-1.amazonaws.com/BUCKET/CARPETABUCKET'
# Usuario de acceso al bucket, se gestionan desde la consola de Amazon
TARGET_USER='XXXXXXXXXXXXXXXXXXXX'
# Contraseña de acceso al bucket
TARGET_PASS='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

# la carpeta base de donde vamos a realizar nuestras copias
SOURCE='/'

# Mantendremos nuestras copias antiguas un máximo de tres meses
MAX_AGE=3M
# Mantendremos dos copias completas en todo momentos, por si una se corrompiese
MAX_FULL_BACKUPS=2

# Para evitar ralentización a la hora de leer las copias, subiremos el tamaño de paquete a 250Mb
VOLSIZE=250
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

Una vez configurada nuestra tarea, debemos indicarle qué queremos incluir en nuestra copia de seguridad. Para ello podemos utilizar este truco: editaremos ‘/root/.duply/cloud_backup/exclude’indicando las carpetas que queremos incluir, con un «**» al final para indicarle que solo queremos dichas carpetas.

+ /root
+ /home/www
+ /home/vmail
+ /home/flashpolicy
+ /home/mysql
+ /home/radicale
+ /etc
**

Si preferís un control más granular, podéis ver todas las opciones de include/exclude de Duply en http://duplicity.nongnu.org/duplicity.1.html en general basta con poner las rutas más profundas primero, tanto para inclusión como exclusión, y las menos profundas al final, o nos encontraremos con resultados extraños.

Creando nuestra primera copia

Una vez tenemos nuestra tarea configurada, y hemos indicado qué carpetas queremos salvaguardar, llega el momento de comprobar nuestra configuración:

duply cloud_backup backup --preview

Si nos parece que todo está correcto, es hora de lanzar nuestra primera copia:

duply cloud_backup backup

Tras el tiempo de rigor, nos dará unas estadísticas de resultado. En nuestro caso 90.831 archivos que ocupaban 18.8 GB han quedado salvaguardados de forma segura ocupando 7.07 GB en Amazon S3 (con un mareante coste total de unos 0.21€ al mes)

--------------[ Backup Statistics ]--------------
StartTime 1413942182.36 (Wed Oct 22 03:43:02 2014)
EndTime 1413944638.15 (Wed Oct 22 04:23:58 2014)
ElapsedTime 2455.79 (40 minutes 55.79 seconds)
SourceFiles 90831
SourceFileSize 15921487361 (14.8 GB)
NewFiles 90831
NewFileSize 15921487361 (14.8 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 90831
RawDeltaSize 15905323958 (14.8 GB)
TotalDestinationSizeChange 7593087053 (7.07 GB)
Errors 0
-------------------------------------------------

--- Finished state OK at 04:25:41.234 - Runtime 00:42:39.534 ---

Si ahora lanzamos el comando de nuevo, al existir ya una copia completa, se realizará de forma automática una copia incremental, en este caso se han modificado entre las dos 48 ficheros, hay 17 nuevos y se han eliminado 3, con un incremento de tamaño de 183 Mb, que han sido salvaguardados en 39 segundos.

duply cloud_backup backup

Last full backup date: Wed Oct 22 03:43:02 2014
--------------[ Backup Statistics ]--------------
StartTime 1413945201.72 (Wed Oct 22 04:33:21 2014)
EndTime 1413945228.27 (Wed Oct 22 04:33:48 2014)
ElapsedTime 26.55 (26.55 seconds)
SourceFiles 90836
SourceFileSize 15785987879 (14.7 GB)
NewFiles 17
NewFileSize 184389850 (176 MB)
DeletedFiles 3
ChangedFiles 48
ChangedFileSize 811334194 (774 MB)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 68
RawDeltaSize 191377039 (183 MB)
TotalDestinationSizeChange 188097319 (179 MB)
Errors 0
-------------------------------------------------

--- Finished state OK at 04:34:00.248 - Runtime 00:00:39.395 ---

Podemos ver el historial de copias con el comando status, en nuestro ejemplo veremos la copia completa (con 29 volúmenes de 250 Mb) y la incremental que hemos lanzado a continuación (1 solo volumen es suficiente)

duply cloud_backup status

Last full backup date: Wed Oct 22 03:43:02 2014
Collection Status
-----------------
Connecting with backend: BotoBackend
Archive dir: /root/.cache/duplicity/duply_cloud_backup

Found 0 secondary backup chains.

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Wed Oct 22 03:43:02 2014
Chain end time: Wed Oct 22 04:33:21 2014
Number of contained backup sets: 2
Total number of contained volumes: 30
Type of backup set: Time: Num volumes:
Full Wed Oct 22 03:43:02 2014 29
Incremental Wed Oct 22 04:33:21 2014 1
-------------------------
No orphaned or incomplete backup sets found.
--- Finished state OK at 04:36:32.714 - Runtime 00:00:00.574 ---

Lanzando copias incrementales automáticas

Una vez realizada la primera copia, el sistema se encarga de realizar una incremental cada vez que llamemos a «duply cloud_backup backup». Como hemos indicado que no se guarden copias superiores a tres meses, al llegar esta antigüedad, se eliminaría la vieja copia y se realizaría una nueva completa, siempre que utilicemos este comando sin más. Para ello basta con añadir una linea a nuestro crontab, por ejemplo, cada día a las 2 AM

# Copias a Amazon S3
0 2 * * * env HOME=/root /usr/bin/duply cloud_backup backup

Duply nos permite forzar una completa cuando queramos, con el comando full, incremental con incr, purgar con purge o purge-full, etc… lo que nos permite ajustar como queramos simplemente creando crons para estos períodos personalizados. Por ejemplo, con 3 crons podríamos tener incrementales diarias, con una completa cada 15 dias, y ejecutando un purge o purge-full una vez al mes, manteniendo asi dos completas y 30 dias de incrementales.

Listando las copias disponibles

Para ver en cualquier momento el estado de nuestras copias de seguridad, basta con hacer un

duply cloud_backup status

Last full backup date: Mon Oct 13 05:12:26 2014
Collection Status
-----------------
Connecting with backend: BotoBackend
Archive dir: /root/.cache/duplicity/duply_cloud_backup

Found 0 secondary backup chains.

Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Mon Oct 13 05:12:26 2014
Chain end time: Wed Oct 22 02:00:03 2014
Number of contained backup sets: 13
Total number of contained volumes: 13
Type of backup set: Time: Num volumes:
Full Mon Oct 13 05:12:26 2014 68
Incremental Mon Oct 13 05:16:22 2014 1
Incremental Mon Oct 13 05:33:06 2014 1
Incremental Mon Oct 13 05:40:33 2014 1
Incremental Tue Oct 14 02:00:02 2014 2
Incremental Wed Oct 15 02:00:02 2014 1
Incremental Thu Oct 16 02:00:02 2014 1
Incremental Sat Oct 18 10:56:06 2014 3
Incremental Sat Oct 18 10:56:21 2014 1
Incremental Sun Oct 19 02:00:02 2014 1
Incremental Mon Oct 20 02:00:02 2014 1
Incremental Tue Oct 21 02:00:01 2014 2
Incremental Wed Oct 22 02:00:03 2014 1
-------------------------
No orphaned or incomplete backup sets found.
--- Finished state OK at 04:05:20.170 - Runtime 00:00:00.859 ---

Como podemos ver, nos lista un extracto del estado de nuestras copias, tanto completas, como incrementales.

Cómo restaurar una copia

Recuperación completa

Podemos restaurar una copia con el comando restore de Duply. Es importante hacerlo como root o con sudo para que Duplicity pueda restaurar los metadatos originales del sistema de archivos, tales como permisos, propietarios, etc… este comando de ejemplo restaura la última copia a una carpeta definida, que no es necesario crear primero, ya que Duplicity lo hará por nosotros.

sudo duply cloud_backup restore /copia_recuperada

Recuperación parcial

Podemos usar el comando fetch para recuperar un archivo concreto.

sudo duply cloud_backup fetch etc/password /tmp/password

Podemos hacer lo mismo con una carpeta

sudo duply cloud_backup fetch etc /tmp/etc

Recuperación en una fecha específica

Cada comando de recuperación acepta una fecha, permitiéndonos recuperarnos en un momento concreto del pasado. Primero, utilizamos el comando status para ver qué fechas de copia tenemos disponibles:

sudo duply cloud_backup status

Number of contained backup sets: 2
Total number of contained volumes: 2
Type of backup set: Time: Num volumes:
Full Sat Oct 8 07:38:30 2014 1
Incremental Sat Oct 9 07:43:17 2014 1

En este ejemplo, recuperaremos la copia del dia 8; la única pega es que tendremos que escribir la fecha en formato w3.

sudo duply cloud_backup restore /copia_recuperada '2014-10-08T07:38:30'

Conclusión

Este sistema nos permite, con una línea de comandos sencilla gracias a Duply, acceder a toda la potencia de Duplicity y almacenar en los servidores de Amazon S3, con copias incrementales seguras, y obteniendo así una paz de espíritu considerable. Ya solo nos queda decir…

Vamos a ver como realizar esto de forma cómoda y sencilla mediante tareas Grunt, manteniendo al mismo tiempo la limpieza y optimización de nuestros assets CSS/JS. Grunt.js es una librería JavaScript que nos permite configurar tareas automáticas y así ahorrarnos tiempo en nuestro desarrollo y despliegue.

Antes que os asuste la extensión del post, indicar que el código está duplicado, primero completo, y luego explicado paso a paso, y que me ha llevado escribir este post unas 20 veces más que implementar todo el sistema.

1.- Planteamiento

En nuestro caso de ejemplo vamos a suponer que nos interesa disponer de:

• Algunos contenidos CSS y Javascript desde CDNs, con una URL genérica de última versión
• Cargamos otros con versiones concretas también desde CDNs
• Por último, cargamos otros más desde disco, sean propios o de terceros

La estructura de carpeta de estos estáticos será tal que:

/s
  /vendor
    /librerias.css
    /librerias.js
  /css
    /mi.css
    /todo.css
  /js
    /mi.js
    /todo.js

2.- Dependencias

Dando por supuesto que disponemos de NodeJS, y tras instalar grunt utilizando npm con un simple sudo npm install -g grunt-cli, empezaremos por definir los módulos de NodeJS que nos interesa importar creando en el root de nuestro proyecto un fichero package.json similar a este:

{
    "name" : "PuerLugoMin",
    "title" : "PuerLugoMin",
    "version" : "1.0.0",
    "devDependencies": {
        "grunt": "0.4.5",
        "grunt-contrib-concat": "0.4.0",
        "grunt-contrib-cssmin" : "0.10.0",
        "grunt-contrib-watch" : "0.6.1",
        "grunt-contrib-uglify" : "0.5.0",
        "grunt-curl" : "2.0.2"
    }
}

Una vez hecho esto, instalaremos estas dependencias con el comando

npm install

3.- La Tarea Grunt

Solucionadas las dependencias, definiremos una tarea Grunt de ejemplo Gruntfile.js también en el root de nuestro proyecto:

module.exports = function(grunt) {
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),
        "curl-dir": {
            's/vendor/': [
            "http://cdn.jsdelivr.net/g/jquery,bootstrap",
            "http://cdnjs.cloudflare.com/ajax/libs/bootbox.js/4.2.0/bootbox.min.js",
            "http://cdn.jsdelivr.net/bootstrap/3.1.1/css/bootstrap.min.css",
            "http://cdn.jsdelivr.net/bootstrap/3.1.1/css/bootstrap-theme.min.css",
            ]
        },
        concat: {
            options: {
                separator: '\n',
            },
            css: {
                src: ['s/vendor/bootstrap.min.css', 's/vendor/bootstrap-theme.min.css', 's/css/mi.css'],
                dest: 's/css/todo.css'
            },
            js : {
                src : ['s/vendor/jquery,bootstrap', 's/vendor/bootbox.min.js', 's/js/mi.js'],
                dest : 's/js/todo.js'
            }
        },
        cssmin : {
            css:{
                src: 's/css/todo.css',
                dest: 's/css/todo.css'
            }
        },
        uglify : {
            js: {
                files: { 's/js/todo.js' : [ 's/js/todo.js' ] }
            }
        },
        watch: {
            files: ['s/css/mi.css', 's/js/mi.js'],
            tasks: ['default']
        }
    });
    grunt.loadNpmTasks('grunt-curl');
    grunt.loadNpmTasks('grunt-contrib-concat');
    grunt.loadNpmTasks('grunt-contrib-uglify');
    grunt.loadNpmTasks('grunt-contrib-watch');
    grunt.loadNpmTasks('grunt-contrib-cssmin');
    grunt.registerTask('default', ['concat:css', 'cssmin:css', 'concat:js', 'uglify:js']);
    grunt.registerTask('update', ['curl-dir', 'concat:css', 'cssmin:css', 'concat:js', 'uglify:js']);
};

4.- La Tarea Grunt paso a paso

Vamos a ver este fichero por partes; para empezar, curl-dir (entrecomillado debido al -), define una función que descarga archivos de CDN en una carpeta de nuestra elección, en este caso lo configuro para descargar varias librerías populares en la carpeta relativa s/vendor, la primera con las últimas versiones de Javascript de jQuery y Twitter Bootstrap en un único archivo gracias a JSDelivr, y las demás con versiones concretas de otras librerías, indicando tanto las dependencias JS como CSS.

"curl-dir": {
	's/vendor/': [
	"http://cdn.jsdelivr.net/g/jquery,bootstrap",
	"http://cdnjs.cloudflare.com/ajax/libs/bootbox.js/4.2.0/bootbox.min.js",
	"http://cdn.jsdelivr.net/bootstrap/3.1.1/css/bootstrap.min.css",
	"http://cdn.jsdelivr.net/bootstrap/3.1.1/css/bootstrap-theme.min.css",
	]
},

Por su parte, concat define una función que concatena dichos archivos, utilizando el separador «\n» (salto de línea), para evitar conflictos con los finales de linea de cada archivo a unir. Tanto para el CSS como para el JS, definimos los archivos fuente como una colección en src, y el fichero destino en dest.

En mi caso llamo a los archivos finales dest: todo.css y todo.js respectivamente, y le paso a la función los nombres finales que tienen los archivos previamente descargados en disco en src; Aquí es donde viene parte de la gracia de este sistema, ya que no tengo que limitarme a los archivos descargados, si no que puedo indicarle archivos en disco que yo haya creado, o que haya descargado manualmente antes. Basta con indicar el orden de las dependencias de forma correcta para evitar problemas. En mi caso, mi.css y mi.js son los archivos sobre los que trabajo y escribo mi propio código, extendiendo el Javascript y CSS de las librerías previas, con lo que simplemente, lo añado al final de cada lista para que sobreescriban cualquier estilo o función definido por estas.

Una vez llamemos a esta función, los archivos serán concatenados en el orden especificado en el mencionado src y guardados en dest. Como adelanto, estos nombres de archivo todo.css y todo.js serán los que luego enlazaré desde mi HTML.

concat: {
    options: {
        separator: '\n',
    },
    css: {
        src: ['s/vendor/bootstrap.min.css', 's/vendor/bootstrap-theme.min.css', 's/css/mi.css'],
        dest: 's/css/todo.css'
    },
    js : {
        src : ['s/vendor/jquery,bootstrap', 's/vendor/bootbox.min.js', 's/js/mi.js'],
        dest : 's/js/todo.js'
    }
},

Una vez hemos descargado los archivos que nos interesan, procedemos a su Minificado, reducción de peso por el método de ofuscación o eliminación de elementos innecesarios, tales como saltos de línea, comentarios, etc… Para ello basta con indicar una función cssmin a la que indicaremos el fichero fuente con src y el destino con dest. En mi caso la elección es obvia, indico la ruta de mi fichero previamente concatenado en ambas variables, para que realice la compresión del mismo y lo sobreescriba.

cssmin : {
    css:{
        src: 's/css/todo.css',
        dest: 's/css/todo.css'
    }
},

Uglify es al Javascript lo que cssmin al CSS, asi que procedemos exactamente de la misma manera, utilizando su propia sintaxis para obtener un resultado más compacto:

uglify : {
    js: {
        files: { 's/js/todo.js' : [ 's/js/todo.js' ] }
    }
},

El módulo watch merece mención aparte: se encarga de quedarse en espera controlando cambios en disco sobre archivos que le indiquemos, y en caso de detectar alguno, realiza la tarea que a su vez le especifiquemos. Esto es muy cómodo si queremos vigilar, por ejemplo, los fichero mi.css y mi.js (los únicos que modificaré regularmente) y en caso de cambios, lanzar automáticamente la concatenación y minificado de los mismos. De esta forma, nada más guardar cambios en nuestro editor, watch salta de forma automática y actualiza nuestros ficheros finales todo.css y todo.js con los últimos cambios.

Para ello, deberemos definir una tarea, a la que llamaré default y que definiremos más tarde, que es la que le indica qué debe hacer al detectar cambios.

watch: {
    files: ['s/css/mi.css', 's/js/mi.js'],
    tasks: ['default']
}

Una vez definidas todas las funciones que necesitamos, debemos indicar a Grunt con qué paquete de NodeJS debe ejecutar cada una, así que incluimos los paquetes definidos al principio en packages.json

grunt.loadNpmTasks('grunt-curl');
grunt.loadNpmTasks('grunt-contrib-concat');
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-cssmin');

Dependencias instaladas, funciones creadas, dependencias cargadas, es el momento de decirle a Grunt qué comandos debe aceptar desde consola, o desde watch, y los definiremos registrando dos tareas, una para que watch regenere los ficheros locales ante cualquier cambio, y otra que refresque versiones de librerías de cuando en cuando, para mantenernos actualizados. Recordemos que a watch le indicamos que cuando hubiese cambios en mi.css o mi.js, llamase a la tarea default, asi que esa será la primera que crearemos:

grunt.registerTask('default', [ 'concat:css', 'cssmin:css', 'concat:js', 'uglify:js' ]);

Sencillo y eficiente, indicamos el nombre default, e indicamos qué acciones debe realizar según las funciones que creamos previamente:

1. Concatenar los CSS -> Genera un todo.css temporal
2. Minificar los CSS -> Genera el todo.css final
3. Concatenar los JS -> Genera un todo.js temporal
4. Minificar los JS -> Genera el todo.js final

El nombre de función default no ha sido definido al azar: si llamamos a grunt sin parámetros desde la consola, esa será la función que ejecute por defecto, salvo que se le indique otra.

Y ahora veremos como indicar otra tarea diferente, la que llamaremos update y que se encargará de descargar las últimas versiones de las librerías:

grunt.registerTask('update', [ 'curl-dir', 'concat:css', 'cssmin:css', 'concat:js', 'uglify:js' ]);

Como veis, es exactamente igual a la anterior, solo que antes de todo el proceso de concatenación y minificado, descarga las últimas versiones utilizando la función curl-dir que especificamos al principio.

5.- Utilizando nuestro automatismo Grunt

¡ Ya estamos listos para empezar a trabajar con Grunt !

Tenemos dos formas de hacerlo, la estrictamente manual, muy flexible, donde podemos invocar a Grunt de múltiples formas desde consola:

• grunt update: ejecutará descarga, concatenación y minificados a través de la función «update»
• grunt default: lo mismo, pero sin descarga
• grunt: sin parámetros, ejecutará lo mismo que indicando default
• grunt cssmin:css: si queremos invocar una de las funciones directamente, también podemos
• grunt curl-dir: otro ejemplo de lo anterior

¡ También en modo automático !

Por otra parte, para utilizar la modalidad de actualización directa basada en watch, bastará con ejecutar grunt watch para obtener algo como esto:

marcos@nabovalley:~/test$ sudo grunt watch
Running "watch" task
Waiting...

En este momento dejamos esa consola abierta, y comenzamos nuestro desarrollo. Cada vez que editemos el fichero mi.css o mi.js de nuestro proyecto, watch lanzará la tarea default especificada, que realizará la concatenación y minificado, entregando los ficheros finales todo.css y todo.js. Como estos ficheros son los que enlazo desde mi HTML, basta con guardar en el editor y recargar la web para apreciar los cambios, con todo el CSS y JS listos para pasar directamente a producción si es necesario.

Además, watch es capaz de hacer livereload, una configuración especial que levanta un servidor propio, y es capaz de recargar el navegador por nosotros en el mismo instante que hagamos cambios a uno de los archivos monitorizados. Para ello, basta con configurarlo:

options: {
  livereload: true,
},

Y añadir a nuestro HTML la etiqueta <script src="//localhost:35729/livereload.js"></script> que es la que se encargará de recargar cuando sea necesario.

6.- Tips adicionales

No olvidemos proteger nuestros archivos de dependencias y grunt añadiendo a nuestro .htaccess de Apache o similar las líneas:

RedirectMatch 404 /Gruntfile\\.js(/|$)
RedirectMatch 404 /package\\.json(/|$)

Y del mismo modo, si utilizamos un sistema de control de versiones, excluyamos la carpeta node_modules del mismo, por ejemplo mediante .hgignore

node_modules/

Conclusión

Hasta aquí este ladrillo, Grunt es una herramienta de automatización fantástica, con multitud de posibilidades, y de la que apenas hemos arañado la superficie. No dejes de dar un buen vistazo al enorme listado oficial de plugins para Grunt, seguro que se te ocurren nuevas e imaginativas formas de ponerlo a trabajar a tu servicio. No en vano, no hay ser más vago sobre la tierra que un programador.

Tras crear una cuenta y añadir el host que deseemos:

Instalaremos el cliente de actualización en el PC con IP dinámica. Este ejemplo es para Ubuntu 12.04, añadimos el PPA

sudo apt-get install python-software-properties
sudo apt-add-repository ppa:nathan-renniewaldock/ppa

Configuramos el PPA para que no nos modifique más que ddclient (el PPA toca otros paquetes si no)

vi /etc/apt/preferences.d/nathan-prefs

Y lo dejamos tal que asi:

Package: *
Pin: release o=LP-PPA-nathan-renniewaldock
Pin-Priority: 400

Package: ddclient
Pin: release o=LP-PPA-nathan-renniewaldock
Pin-Priority: 500

Actualizamos, e instalamos el cliente

sudo apt-get update && sudo apt-get install ddclient

Una vez instalado, solo tenemos que configurarlo a nuestro gusto:

vi /etc/ddclient.conf

daemon=600                              # Segundos entre actualizaciones, no lo pongas demasiado bajo
syslog=yes                              # Añadir log al syslog
mail=tu@email.com                       # Enviar mensajes a este email
mail-failure=tu@email.com               # Enviar fallos a este email
pid=/var/run/ddclient.pid               # Usar este PID
protocol=dyndns2                        # Protocolo
use=web                                 # Especifica de donde leer la IP pública
web=myip.dnsdynamic.com
server=www.dnsdynamic.org               # Especifica a donde enviar actualizaciones
login=tu@usuario.com                    # Tu cuenta en dnsdynamic.org
password='tucontraseña'
xxxxxxxxxxxxxxx.dnsget.org              # Host que deseas actualizar

Un reinicio de servicio y listo, en unos segundos deberías ya poder utilizar tu nuevo host

sudo /etc/init.d/ddclient restart

Para desactivar esta molesta «funcionalidad», que es un falso positivo en el 99% de los casos:

Win+R

services.msc [Intro]

Hacemos doble clic en «Detección de hardware shell»

Y marcamos, dentro de «Tipo de Inicio», la opción «Deshabilitado» y «Aceptar»

Y se acabó el problema.