Tamanho de backup incremental excessivo no BareOS

Observe que uma atualização importante foi adicionada no final da primeira parte

Infelizmente, mesmo que seja muito fácil verificar exatamente o que aconteceu com um backup específico, não é tão fácil obter o tamanho dos arquivos de backup.

Vamos nos aprofundar com alguns exemplos.

No meu caso, bconsoleposso obter a lista dos últimos trabalhos com:

*list jobs
 Automatically selected Catalog: CatalogoBareos
 Using Catalog "CatalogoBareos"
 +-------+------------------------+---------------------+------+-------+------------+-------------------+-----------+
 | JobId | Name                   | StartTime           | Type | Level | JobFiles   | JobBytes          | JobStatus |
 +-------+------------------------+---------------------+------+-------+------------+-------------------+-----------+
 [...]
 | 7,060 | backup-XXXXXXXX        | 2016-01-02 16:00:50 | B    | I     |          2 |        74,225,116 | T         |
 | 7,062 | backup-YYY             | 2016-01-02 16:04:47 | B    | F     |    890,482 |   181,800,839,481 | T         |
 [...]
 +-------+------------------------+---------------------+------+-------+------------+-------------------+-----------+

Acima, você pode ver dois trabalhos:

• Job 7060: um backup incremental "I", interessantes 2 arquivos para um total de 74MB de dados;
• Trabalho 7062: um backup "completo", arquivo 890492 interessante, para um total de 181 GB de dados;

Vamos nos concentrar no Trabalho 7060, pois é incremental. Vamos verificar quais arquivos foram copiados:

*list files jobid=7060 
 c:/allXXX_Backup/PLONE/Backup_Plone.bkf
 c:/allXXX_Backup/PLONE/
+-------+-----------------+---------------------+------+-------+----------+------------+-----------+
| JobId | Name            | StartTime           | Type | Level | JobFiles | JobBytes   | JobStatus |
+-------+-----------------+---------------------+------+-------+----------+------------+-----------+
| 7,060 | backup-XXXXXXXX | 2016-01-02 16:00:50 | B    | I     |        2 | 74,225,116 | T         |
+-------+-----------------+---------------------+------+-------+----------+------------+-----------+
*

Portanto, o Job 7060 interessava a um arquivo (Backup_Plone.bkf) e a um diretório (a pasta que o continha).

Infelizmente, como você pode ver, a saída de list files jobid=7060NÃO apresenta o tamanho de arquivo que você precisa, então ..... é útil, espero, mas não resolve seu problema.

Vamos dar um passo à frente.

Eu viajei ao longo da documentação oficial do bareos sendo incapaz de encontrar a maneira correta de obter "tamanhos de arquivo" de dentro do bconsole. Então decidi pegar o caminho mais pesado: acesso SQL direto ao catálogo.

Nota: Por favor, seja extremamente cuidadoso ao lidar com o acesso direto ao catálogo, pois cada ação imprópria pode levar a sérios danos, com perda de dados relacionada!

Uma vez conectado ao mecanismo de banco de dados (MySQL, no meu caso .... mas isso é um detalhe, pois com o PostgreSQL é a mesma coisa), vi que os metadados do arquivo de backup são armazenados (...

• Filetabela: armazena quase todos os metadados, com exceção de...
• Filenametabela: armazena o nome do arquivo do backup
• Pathtabela: armazena o caminho completo do arquivo de backup

Com uma grande surpresa, descobri que a Filetabela não inclui um sizecampo. Então não é possível, com uma simples consulta, conseguir o que precisamos. De qualquer forma, encontrei um LStatcampo interessante (mais sobre ele, mais tarde).

Então, iniciei a seguinte consulta SQL:

select 
  f.JobId,f.LStat,f.MD5, fn.Name, p.Path
from
  Filename fn,
  File f,
  Path p
where
  f.JobId=7060 and
  fn.FilenameId = f.FilenameId and 
  p.PathId = f.PathId

e voltou com os seguintes resultados:

mysql> select f.JobId,f.LStat,f.MD5, fn.Name, p.Path
    -> from
    -> Filename fn,
    -> File f,
    -> Path p
    -> where
    -> f.JobId=7060 and
    -> fn.FilenameId = f.FilenameId and 
    -> p.PathId = f.PathId
    -> ;
+-------+------------------------------------------------------+------------------------+------------------+-------------------------+
| JobId | LStat                                                | MD5                    | Name             | Path                    |
+-------+------------------------------------------------------+------------------------+------------------+-------------------------+
|  7060 | A A IH/ B A A A EbJQA A A BWheFw BWheFw BTD/En A A L | 8ZuPGwdo9JYJileo+sVlfg | Backup_Plone.bkf | c:/all***_Backup/PLONE/ |
|  7060 | A A EH/ B A A A A A A BWhRjY BWgz4o BTD/En A A L     | 0                      |                  | c:/all***_Backup/PLONE/ |
+-------+------------------------------------------------------+------------------------+------------------+-------------------------+
2 rows in set (0.00 sec)

Quanto ao LStatcampo, no Guia oficial do desenvolvedor do BareOS , vi:

> Column Name   Data Type   Remark
> [...]
> LStat         tinyblob    File attributes in base64 encoding

Então, agora, o problema é:

• O LStat inclui o tamanho do arquivo?

e, como eu apostaria em um "SIM! Com certeza!":

• Como o FileSize pode ser recuperado da string LStat?

Uma busca rápida por "BareOS LStat" me leva a vários resultados. Em poucos segundos recebi este tópico, incluindo vários comentários sobre o campo LStat, incluindo um pequeno script PERL para decodificá-lo corretamente. Aqui está ( * cortesia de Brian McDonald , 2005 * ), ligeiramente modificado para atender melhor às suas necessidades:

#!/usr/bin/perl

my $base64_digits =
    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
my $base64_values = { };
my $val = 0;
foreach my $letter ( split(//, $base64_digits ) )
    { $base64_values->{ $letter } = $val++; }

print "Please, enter your LSTAT string:";
my $lstat = <STDIN>;

my $vals = decode_stats($lstat);

print "Here are the results:\n";
foreach my $key (keys %{$vals}) {
   printf("%15s: %s\n",$key, $$vals{$key}) ;
}
exit;

sub decode_stats
{
  my $stats = shift;
  my $hash = { };

  # The stats data is in base64 format.  Yuck! - I mean Yay!
  # Each value is base64 encoded incorrectly, a deficiency we have
  # to correct here.  In particular, some values are encoded with a single
  # base64 character.  This results in a 6 bit value, and you have to
  # understand how bacula padded and manipulated those values before storing
  # them in the DB.

  # the fields are, in order:
  my @fields = qw(
    st_dev st_ino st_mode st_nlink st_uid st_gid st_rdev st_size
    st_blksize st_blocks st_atime st_mtime st_ctime LinkFI st_flags data
  );

  # Decoding this mess is based on reading src/lib/base64.c in bacula, in
  # particular the to_base64 function, which is how these got in the DB in
  # the first place.
  my $field_idx = 0;
  foreach my $element ( split( /\s+/, $stats ) )
  {
    my $result = 0;
    for ( my $i = 0; $i<length($element); $i++ )
    {
        if ($i) { $result <<= 6; }
        my $r = substr($element, $i, 1 );
        $result += $base64_values->{$r};
    }
    $hash->{ $fields[$field_idx] } = $result;
    $field_idx++;
  }

  return $hash;
}

Quando iniciado e fornecido uma string LSTAT, ele relata muitos dados, incluindo o tamanho do arquivo (st_size, último campo da saída):

verzulli@iMac-Chiara:/tmp$ perl pp.pl 
Please, enter your LSTAT string:A A IH/ B A A A EbJQA A A BWheFw BWheFw BTD/En A A L
Here are the results:
     LinkFI: 0
   st_atime: 1451614576
     st_ino: 0
   st_flags: 0
   st_mtime: 1451614576
     st_dev: 0
   st_nlink: 1
 st_blksize: 0
  st_blocks: 0
       data: 11
     st_gid: 0
    st_mode: 33279
     st_uid: 0
    st_rdev: 0
   st_ctime: 1393553703
    st_size: 74224640

Portanto, agora temos o tamanho do arquivo, mas, infelizmente, não é facilmente acessível em uma única consulta para encontrar o maior arquivo de uma única tarefa de backup.

Existem várias soluções:

• se você estiver executando o MySQL 5.6.1 ou posterior, ou um mecanismo DBMS com suporte para codificação/decodificação BASE_64, poderá consultar um SUBSTR do LSTAT e solicitar ao mecanismo de banco de dados que decodifique seu valor como um Base64. Por exemplo, veja aqui

• você poderia escrever um procedimento armazenado. Na verdade, ele já deveria estar presente no PostgreSQL, como para isso (que afirma: " ...Adicionou procedimentos armazenados de amostra postgresql para o campo lstat.... ");

• você poderia escrever um pequeno script PERL, consultando o catálogo e passando pelo material de decodificação

• ...

Espero que isso seja suficiente ;-)

Atualização 1

Acabei de descobrir a existência da API BVFS , explicitamente " ...destinada principalmente a desenvolvedores que desejam desenvolver uma nova interface GUI para Bareos... ".

Essas APIs fornecem um novo conjunto de comandos (os chamados " dot-commands "), incluindo um interessante .bvfs_lsfilesque mostra no console alguns metadados, incluindo o campo LSTAT . Então:

1. é definitivamente possível obter o campo LSTAT sem acesso direto ao banco de dados/catálogo subjacente .

Além disso, com o BareOS 15.2, um novo "modo API 2" foi introduzido, adicionando suporte para saída JSON. Acabei de testar isso:

2. com a API V.2 habilitada, os objetos JSON retornados por .bvfs_lsfiles, contém o campo de tamanho do arquivo, devidamente decodificado .

Aqui segue um exemplo:

*.bvfs_update
Using Catalog "MyCatalog"
*.bvfs_lsfiles path=/var/log/2016/01/06/ jobid=79
107131  34080   3614785 79  P0A CCMR IGA B A A A H1V BAA BI BWjIkK BWjJAx BWjJAx A A C  shorewall.log
107131  34081   3614786 79  P0A CCMQ IGA B A A A BT1 BAA Q BWjIkK BWjI7p BWjI7p A A C   system.log
*.api 2
{
  "jsonrpc": "2.0",
  "id": null,
  "result": {
    "api": 2
  }
}*
*.bvfs_lsfiles path=/var/log/2016/01/06/ jobid=79
{
  "jsonrpc": "2.0",
  "id": null,
  "result": {
    "files": [
      {
        "type": "F",
        "stat": {
          "dev": 64768,
          "nlink": 1,
          "mode": 33152,
          "ino": 533265,
          "rdev": 0,
          "user": "root",
          "group": "root",
          "atime": 1452050698,
          "size": 32085,
          "mtime": 1452052529,
          "ctime": 1452052529
        },
        "pathid": 107131,
        "name": "shorewall.log",
        "fileid": 3614785,
        "filenameid": 34080,
        "jobid": 79,
        "lstat": "P0A CCMR IGA B A A A H1V BAA BI BWjIkK BWjJAx BWjJAx A A C",
        "linkfileindex": 0
      },
      {
        "type": "F",
        "stat": {
          "dev": 64768,
          "nlink": 1,
          "mode": 33152,
          "ino": 533264,
          "rdev": 0,
          "user": "root",
          "group": "root",
          "atime": 1452050698,
          "size": 5365,
          "mtime": 1452052201,
          "ctime": 1452052201
        },
        "pathid": 107131,
        "name": "system.log",
        "fileid": 3614786,
        "filenameid": 34081,
        "jobid": 79,
        "lstat": "P0A CCMQ IGA B A A A BT1 BAA Q BWjIkK BWjI7p BWjI7p A A C",
        "linkfileindex": 0
      }
    ]
  }
}*

Então, no final, com uma versão recente do BareOS, o problema original parece ser solucionável sem acesso direto ao catálogo.

Embora eu aprecie o esforço de @damiano-verzulli, uma discussão no canal BareOS IRC no FreeNode iludiu esta resposta:

Acontece que Kjetil Torgrim Homme já escreveu um script para fazer isso, chamado bacula-du. (Juntamente com alguns outros scripts úteis!)

Eles estão todos listados e podem ser obtidos aqui:

http://heim.ifi.uio.no/kjetilho/hacks/

Em particular bacula-dué explicado como isto:

Usage: bacula-du [OPTIONS] -j JOBID 
       Summarize disk usage of directories included in the backup JOBID

Main options are:   
    -a, --all             write counts for all files, not just directories
    -S, --separate-dirs   do not include size of subdirectories   
    -t, --threshold=SIZE  skip output for files or directories with usage below SIZE.  default is 1 octet.   
    -L, --largest=NUM     only print NUM largest directories/files 

There is also an alternate mode which can be useful as a faster alternative to a verify job.

Usage: bacula-du --md5sum -j JOBID   --md5sum              
       output list of all files in job in md5sum format 

bacula-du (versão 1.4)

Há uma pequena observação que devo acrescentar aqui. Para que isso funcione, ele precisa ter acesso ao banco de dados (obviamente). Na configuração padrão, ele usa um mecanismo de segurança baseado no usuário, portanto, você deve executar o comando como o usuário bareos para que funcione, por exemplo

$ sudo -u bareos ./bacula-du -j 1429
done reading database.
   807160 /log/
     6372 /var/openldap-data/
     6372 /var/
   813532 /admin/
...
119983392 /