Já sabemos que um sem número de aplicações podem precisar de uma cópia intermediária íntegra antes de ter os dados copiados para uma mídia, a exemplo dos dumps do Mysql / Postgres; RMAN do Oracle; clone de VM do XEN etc.
Ocorre que nem sempre temos espaço em disco suficiente para gerar essa redundância, o que pode gerar problemas.
FIFO é uma operação avançada mas muito eficiente na medida que, uma vez aberto, os dados só são disponibilizados quando lidos. Exemplo:
1. FIFO é criado (ex.: no Linux, mkfifo /tmp/fifo)
2. Conteúdo é enviado para um FIFO (ex.: echo “teste” > /tmp/fifo): o mesmo fica com 0 bytes mas aguardando uma ação.
3. Conteúdo é lido de um FIFO (ex.: cat /tmp/fifo).
Ou seja: se fizermos um script antes do Job de backup do Bacula, é possível utilizar o FIFO para copiar o dump de bancos ou clone de VM sem ocupar espaço no disco rígido do cliente.
Exemplo para MySQL (RunClientBeforeJob):
#!/bin/sh
FIFO="/var/bacula.sql"
if [ -r $FIFO ]; then
rm -f $FIFO
if [ "$?" -ne "0" ]; then
exit 1
fi
fi
mkfifo $FIFO
if [ "$?" -ne "0" ]; then
exit 1
fi
screen -d -m -S mysqldump -t mysqldump su -s /bin/bash -c "mysqldump -u root -p123456 teste > /var/bacula.sql"
No exemplo, o screen é utilizado para que o script não fique suspenso e o Bacula fique eternamente aguardando a execução do mesmo. O dump é redirecionado para o FIFO: /var/bacula.sql, e o FileSet do Job de backup deve ser configurado para copiá-lo. Também é necessária utilizar a opção ReadFifo no FileSet. Exemplo:
FileSet {
Name = "dump_mysql_fifo"
Include {
Options {
signature = MD5
ReadFifo = yes
}
File = /var/bacula.sql
}
}
Por fim, é recomendável que um script depois do Job de backup delete o FIFO criado, na medida que não vai ser mais necessário:
#!/bin/sh
FIFO="/var/bacula.sql"
rm -f $FIFO
Disponível em: 
Português
