viernes, 11 de mayo de 2018

Las cintas no mueren, pero matan.

En la empresa para la que trabajo como administrador de copias de seguridad, Atos, realizamos copias de seguridad en cinta para nuestros clientes, como casi en todas partes. Tanto de clientes enormes como de pequeñas sedes remotas.

En una de estas sedes remotas utilizamos un tipo de cintas que es un estándar empresarial, las Linear Tape-Open Ultrium, si bien de cuarta generación (LTO-4, no es necesario especificar Ultrium ya que nunca se produjeron comercialmente las Accelis), introducidas en 2007, con una capacidad nativa de 800GB.

Y los 800GB son la única medida real del tamaño de la cinta. HP las publicita como cintas de 1,6TB, suponiendo que darán una compresión de 2:1 pero IBM indica realmente que son cintas de 800GB que dan 1,6TB con compresión (suponiendo otra vez 2:1).

Y la realidad es que la capacidad de las cintas depende mucho del tipo de datos que se meta en ellas. Para hacer backups de máquinas completas, con su Sistema Operativo lleno de ficheros binarios, un factor de compresión de 2:1 es excesivamente optimista. En esa sede remota de la que hablo, las cintas de 800GB están cargando entre 970GB y 1020GB (de 1,21:1 a 1,27:1, muy lejos de 2:1), con lo cual los backups completos semanales de 1140GB de esa sede que, según la publicidad, deberían caber en un cartucho, necesitan dos.

Siempre, siempre, un administrador de backup debe trabajar a partir de datos históricos de compresibilidad, y no fiarse de la versión edulcorada de los fabricantes de los cartuchos.

Los puntos de vista expresados en esta entrada son propios, y no representan necesariamente los puntos de vista de Atos SE, Atos España o ninguna de sus filiales.

miércoles, 20 de diciembre de 2017

Los backups incrementales y diferenciales

Una de las cosas con las que se enfrenta, con un poco de miedo, cualquier administrador de copias de seguridad es al backup diferencial.

¿Qué es un backup diferencial? La verdad es que ni siquiera los programas de backup lo tienen claro.

Para empezar, todos tienen claro lo que es un backup Full o completo: se copia todo lo que haya que copiar. Pero no se puede hacer backup de todo todos los días, sería un gasto enorme e inútil de recursos.

Entonces, se puede copiar cada día solamente lo que haya cambiado desde el día anterior. O solamente lo que haya cambiado desde que se hizo el backup Full.

Estas dos estrategias son interesantemente diferentes: si se copia solamente lo que haya cambiado desde el día anterior, todos esos backups serán pequeños, pero a la hora de restaurar (no perdamos de vista que los backups no son el objetivo: su propósito es poder restaurar) son necesarios tanto el backup completo inicial como todos estos backups parciales. En cambio, si se copia todo lo que haya cambiado desde el backup Full, estos backups parciales serán pequeños, sí, pero cada vez más grandes, sin embargo para restaurar solamente serán necesarios el backup completo inicial el el backup parcial en cuestión.

Estas dos estrategias, además, se pueden combinar de varias maneras. Y el problema es que reciben diferentes nombres allá donde se usen.

Uno de los grandes contendientes en la arena empresarial es EMC NetWorker. Para este programa la estrategia de copiar "lo que haya cambiado desde el día anterior" es llamada comúnmente backup incremental, y la de copiar "lo que haya cambiado desde el backup completo" es llamada normalmente backup diferencial. Aunque no es exactamente así: NetWorker tiene 9 niveles de backup diferencial. Así, un backup diferencial de nivel 1 es realmente "lo que haya cambiado desde el backup completo", uno de nivel 2 es "lo que haya cambiado desde el backup completo o desde el backup de nivel 1", etc., permitiendo un control fino de la estrategia de copia, mientras que un backup incremental es realmente "lo que haya cambiado desde el backup anterior". Nótese, por cierto, que en determinadas aplicaciones, como en el módulo de NetWorker para Microsoft SQL Server, el backup "incremental" tiene un uso especial (en MSSQL hace copia de los Transaction Logs), con lo cual no queda disponible para su uso regular. Para el control de lo que se ha copiado en cada uno de estos niveles, NetWorker maneja índices de ficheros.

Otro de los grandes programas es Veritas NetBackup. Para este programa, o su primo Veritas Backup Exec, la estrategia de copiar "lo que haya cambiado desde el día anterior" es llamada "Cumulative incremental" o más comúnmente incremental, y la de copiar "lo que haya cambiado desde el backup completo" es llamada "Differential Incremental" o más amigablemente backup diferencial, pero aquí no trabajan en base a índices de ficheros, sino que el backup incremental copia los ficheros que tengan el bit de Archivo en ON (los nuevos o que hayan sido modificados) y pone dicho bit a OFF, mientras que el backup diferencial copia los ficheros que tengan el bit de archivo a ON pero no modifica dicho bit. El comportamiento de ambos tipos de backups es el esperado, pero la interacción entre ambos es exactamente la contraria que en EMC NetWorker: los backups diferenciales de Veritas NetBackup o Veritas BackupExec "se apoyan", es decir, necesitan a la hora de una restauración, de un backup incremental previo si lo hubiera, mientras que en EMC NetWorker es exactamente al contrario.

El más importante de los programas de backup Open Source, Bacula, usa unas definiciones parecidas: un Incremental es exactamente lo que haya cambiado desde que comenzó el último backup de cualquier tipo, mientras que un Differential es exactamente lo que haya cambiado desde que comenzó (y es importante el detalle "desde que comenzó", ya que puede que no haya acabado) el último backup Full. De este modo, a la hora de la restauración se comportan igual que los de EMC NetWorker.

Para el no iniciado, pensar en términos de completo, diferencial e incremental puede suponer un esfuerzo mental extra. Es más sencillo trabajar solamente con el completo y el incremental, e introducir el diferencial a medida que se coge expericncia con el programa específico con el que se ha de trabajar.

viernes, 25 de julio de 2014

Configurando la red para máquinas virtuales

Siguiendo con la configuración de máquinas virtuales, es hora de configurar la red.

Quiero que mis máquinas virtuales atiendan servicios, así que necesito que tengan direcciones IP visibles desde la red física, a las que mi enrutador pueda dirigirse.

Ha sido muy difícil encontrar la documentación, y al final en realidad he tenido que recurrir a métodos de prueba y error, pero finalmente lo tengo.

En el servidor, hay que configurar un puente. Eso quiere decir que pasamos de esto:

#/etc/network/interfaces

# The primary network interface
allow-hotplug eth0
auto eth0
iface eth0 inet static
      address 192.168.2.25
      netmask 255.255.255.0
      network 192.168.2.0
      broadcast 192.168.2.255
      gateway 192.168.2.1
      dns-nameservers 127.0.0.1
      dns-domain rolamasao.org

a esto:

#/etc/network/interfaces

# The primary network interface
auto br0
iface br0 inet static
        bridge_ports eth0
        address 192.168.2.25
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.1
        dns-nameservers 127.0.0.1
        dns-domain rolamasao.org

Es importante notar que a partir de ese momento debemos considerar que la interfaz de red de nuestro servidor físico es br0, y no eth0.

Claro que de nada sirve tener un puente si los paquetes que llegan al puente no son retransmitidos hacia Internet. Por eso hay que modificar un parámetro del kernel:

# /etc/sysctl.conf - Configuration file for setting system variables

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Para que estos cambios tengan efecto es necesario reiniciar, pero siempre se pueden ejecutar a mano con un poquito de brctl, ifconfig, route y echo.

En las máquinas virtuales la configuración debe indicar que utilizan el puente br0, lo cual es bastante sencillo de hacer desde virt-manager. Ya dentro de la máquina virtual, tenemos una configuración bastante estándar. Simplemente hay que indicar que el enrutador por defecto es la máquina física, no el enrutador de la red:

#/etc/network/interfaces VIRTUAL

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.2.80
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.25
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.2.25

sábado, 19 de julio de 2014

Identificando máquinas virtuales

Últimamente me estoy metiendo a configurar máquinas virtuales en casa. Más adelante hablaré sobre todos los pasos necesarios, pero de momento me voy a referir al importante detalle de identificar la máquina en la que se trabaja.

Claro que todas las máquinas tienen nombre, pero ¿realmente leemos el nombre de máquina que aparece en el prompt de la shell?

root@vmserver:~#

¿Qué máquina es esa? Hay que fijarse mucho para ver que se trata de una máquina llamada vmserver. Y si tenemos varias máquinas abiertas en distintas pestañas de nuestro programa de terminal, es fácil confundirse. A mí me ha pasado ejecutar un poweroff en la máquina física pensando en apagar una máquina virtual. Y duele.

Así que me decidí a identificarlas por colores.

Las instrucciones de debajo son bastante generales pero has sido comprobadas en una máquina Debian. En otras distribuciones de Linux puede ser ligeramente diferente y en otros Unix muy diferente.

Toda sesión de shell de una máquina comienza ejecutando el fichero /etc/profile. Y este fichero a su vez llama a /etc/bash.bashrc (en el caso de que la shell en uso sea bash y el acceso sea interactivo).

Este segundo fichero define la variable PS1 de esta manera:

# set a fancy prompt (non-color, overwrite the one in /etc/profile)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

Esto prepara el bonito prompt al que estamos acostumbrados, con user@host:directorio$ .

root@vmserver:~#

Pero decidí que las máquinas virtuales tuvieran el prompt azul para distinguirlas de la máquina física, así que lo modifiqué de esta manera:

set a fancy prompt (non-color, overwrite the one in /etc/profile)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
# extra color for real/virtual machine differentiation
MACHINECOLOR=34
STARTCOLOR="\e[0;${MACHINECOLOR}m";
ENDCOLOR="\e[0m"
export PS1="$STARTCOLOR$PS1$ENDCOLOR"

Aparte de un detalle para controlar si estamos en un chroot e indicárnoslo, obtenemos el bonito resultado de

root@vmserver:~#

STARTCOLOR se encarga de iniciar el azul, y ENDCOLOR de finalizarlo, lo que es muy importante para evitar que todo el texto quede azul:

root@vmserver:~# ls
root@vmserver:~# echo 1
1
root@vmserver:~#

34 es el código para el azul. Hay otros:

Black 0;30
Red 0;31
Green 0;32
Brown 0;33
Blue 0;34
Purple 0;35
Cyan 0;36
Light Gray 0;37
Dark Gray 1;30
Light Red 1;31
Light Green 1;32
Yellow 1;33
Light Blue 1;34
Light Purple 1;35
Light Cyan 1;36
White 1;37


Lo importante es que estos no son códigos de bash sino secuencias de escape ANSI/VT-100, porque no las interpreta la shell sino la terminal.

Así, podemos usar otros códigos ANSI/VT100 para conseguir otros efectos. Como los que necesito en la máquina física.

# set a fancy prompt (non-color, overwrite the one in /etc/profile)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
# extra color for real/virtual machine differentiation
MACHINECOLOR=31
# root differentiation
if [ $(id -u) -eq 0 ] ; then
    MACHINECOLOR="7;$MACHINECOLOR"
fi
STARTCOLOR="\e[0;${MACHINECOLOR}m";
ENDCOLOR="\e[0m"
export PS1="$STARTCOLOR$PS1$ENDCOLOR"

Aquí utilizo el código 31 que corresponde al rojo, color universal de aviso, que en este caso me indica que estoy en la máquina real, para evitar meter la pata. Pero hay un detalle más: se comprueba si el usuario es root y si es así, se utiliza el código 7 para invertir los colores:

user@realserver:~$ ls
user@realserver:~$ echo 1
1
user@realserver:~$ su -
Contraseña: 
root@realserver:~# ls
root@realserver:~# echo 1
1
root@realserver:~# 

Con lo cual ahora es bastante más difícil equivocarse de máquina o no recordar que uno es root.

El pequeño problema es que normalmente PS1 es posteriormente redefinido en el fichero ~/.bashrc que es llamado desde ~/.profile:

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

Así que en el fichero ~/.bashrc de cada usuario, y en el fichero /etc/skel/.bashrc para los nuevos usuarios que se creen, hay que modificarlo a esto:

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    #PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
    PS1=$PS1
fi
unset color_prompt force_color_prompt

Y ya tenemos nuestras terminales perfectamente coloreadas.

    Referencias:
  1. http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html
  2. http://misc.flogisoft.com/bash/tip_colors_and_formatting
  3. https://wiki.archlinux.org/index.php/Color_Bash_Prompt_(Espa%C3%B1ol)
  4. http://www.termsys.demon.co.uk/vtansi.htm

miércoles, 8 de enero de 2014

Sobre el sistema de ficheros de Android

En particular, sobre Android 4.2.2

/storage es un directorio del sistema interno del teléfono. Dentro tenemos:

emulated
extSdCard
sdcard0

/storage/emulated es un tmpfs. Dentro tenemos:

0
legacy

/storage/emulated/0 y /storage/emulated/legacy son el mismo dispositivo montado dos veces en dos sitios distintos. Además, en realidad no es un dispositivo, es el directorio /data/media (en mi teléfono corresponde al almacenamiento interno, de 4GiB). Dentro tenemos los directorios creados por las aplicaciones.

/storage/extSdCard es la tarjeta microSD real, extraible (en mi teléfono corresponde al almacenamiento externo, de 32GiB). Dentro tenemos los directorios creados por las aplicaciones.

/storage/sdcard0 es un enlace simbólico a /storage/emulated/legacy

jueves, 1 de agosto de 2013

Descargar enlaces ed2k:// desde Chromium

Tras el éxito de Descargar enlaces ed2k:// desde Firefox y su segunda parte, Descargar enlaces ed2k:// desde Firefox (II) llega a sus pantallas la esperada tercera parte: Descargar enlaces ed2k:// desde Chromium, protagonizada por Chromium, tu PC y, en el papel de compañero, xdg-open.

Bueno, tras esta introducción cinematográfica (!), vamos a lo que importa.

Via http://unix.stackexchange.com/questions/38650/adding-bindings-for-ed2k-links-with-xdg-open.

Chromium, para abrir enlaces ed2k://, va directamente a intentar abrirlos con xdg-open, y esto no es configurable. Lo bueno es que xdg-open es una miniaplicación pensada para abrir cada tipo de fichero con la aplicación que tú quieras, y muy configurable.

Lo primero es crear un fichero de configuración del escritorio allí donde xdg-open lo va a buscar, en ~/.local/share/applications, configurando el acceso a los enlaces ed2k://. Dicho fichero lo llamaremos userapp-amule.desktop y su contenido será:

[Desktop Entry]
Name=aMule
Name[en_US]=userapp-amule
Exec=/usr/bin/ed2k %u
Icon=amule
Terminal=false
Type=Application
Categories=Network;P2P;
Comment=A client for the eD2k network
MimeType=x-scheme-handler/ed2k

Lo más importante es que establecemos la relación entre el MimeType x-scheme-handler/ed2k (correspondiente al pseudo-protocolo ed2k://) y la aplicación /usr/bin/ed2k.

Lo segundo es decirle a xdg-open que utilice este fichero tipo .desktop. Eso lo hacemos añadiendo la línea
x-scheme-handler/ed2k=userapp-amule.desktop
a las dos secciones del fichero ~/.local/share/applications/mimeapps.list (aunque pueda parecer redundante, es necesario).

Et voilà !

Chromium intentará abrir el enlace ed2k:// con xdg-open que usará nuestro querido /usr/bin/ed2k.

domingo, 5 de mayo de 2013

Otra vez lo hemos conseguido

http://www.debian.org/News/2013/20130504

Otra vez, lo hemos hecho.

Wheezy ya ha sido liberado como 7.0, y empieza la andadura de Jessie.