主页 / server / 问题 / 746537
Accepted
tudor -Reinstate Monica-
Asked: 2016-01-04 20:43:43 +0800 CST

BareOS 中的增量备份大小过大

  • 772

我有一个 BareOS 安装，对默认配置文件的修改很少。正在执行完整、增量和差异备份。大多数客户端似乎都按预期进行了备份。

但是，我的一个客户似乎在每个增量周期中重复备份超过 10% 的整个文件系统。

如何找到重复备份的最大文件和文件夹？

BAT 在这里似乎不是很有帮助，因为它只列出了文件节点本身的大小，而不是整个文件夹的大小。我正在有效地寻找一个du在 BareOS 框架内工作的命令，以进行特定的备份尝试。

bareos

2 个回答

  1. 请注意，在第一部分末尾添加了一个重要更新

    不幸的是，即使很容易准确地检查特定备份发生了什么，要获得备份文件的文件大小也不是那么容易。

    让我们通过一些例子来深入了解。

    就我而言，bconsole我可以从中获得最后一份工作的清单：

    *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         |
 [...]
 +-------+------------------------+---------------------+------+-------+------------+-------------------+-----------+

    从上面可以看到两个job：

    • Job 7060：一个“I”增量备份，有趣的 2 个文件，总共 74MB 的数据；
    • Job 7062：一个“F”ull备份，有趣的890492文件，总共181GB的数据；

    让我们关注 Job 7060，因为它是增量的。让我们检查备份了哪些文件：

    *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         |
+-------+-----------------+---------------------+------+-------+----------+------------+-----------+
*

    所以 Job 7060 对一个文件（Backup_Plone.bkf）和一个目录（包含文件夹）感兴趣。

    不幸的是，正如您所看到的，输出list files jobid=7060并没有提供您需要的文件大小，所以......它很有用，希望如此，但不能解决您的问题。

    让我们先一步。

    我一直在浏览bareos 官方文档，无法找到从 bconsole 中获取“文件大小”的正确方法。所以我决定采用重法：直接对目录进行 SQL 访问。

    注意：在处理对目录的直接访问时，请格外小心，因为每一个不正确的操作都可能导致严重的损坏，并导致相关的数据丢失！

    一旦连接到数据库引擎（MySQL，在我的例子中......但这是一个细节，与 PostgreSQL 一样），我看到备份的文件元数据存储（......等等）在：

    • File表：它主要存储所有元数据，除了...
    • Filename表：它存储备份文件的文件名
    • Path表：它存储备份文件的完整路径

    大吃一惊，我发现该File表不包含字段size。所以不可能，通过一个简单的查询，得到我们需要的东西。无论如何，我发现了一个有趣的LStat领域（稍后会详细介绍）。

    所以我启动了以下 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

    并得到以下结果：

    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)

    至于该LStat领域，我在官方 BareOS 开发者指南中看到：

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

    所以，现在，问题是：

    • LStat 是否包含文件大小？

    而且，正如我敢打赌“是的！绝对！”：

    • 如何从 LStat 字符串中检索 FileSize？

    快速搜索“BareOS LStat”让我得到了几个结果。几秒钟后，我收到了这个帖子，其中包括关于 LStat 字段的几条评论，包括一个用于正确解码它的小 PERL 脚本。这是（*由 Brian McDonald 提供，2005 *），稍作修改以更好地满足您的需求：

    #!/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;
}

    当启动并给出 LSTAT 字符串时，它会报告大量数据，包括文件大小（st_size，输出的最后一个字段）：

    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

    所以，现在，我们有了文件大小，但不幸的是，在单个查询中很难找到单个备份作业的最大文件。

    存在几种解决方案：

    • 如果您正在运行 MySQL 5.6.1 或更高版本，或者支持 BASE_64 编码/解码的 DBMS 引擎，您可以查询 LSTAT 的 SUBSTR，然后要求 DB 引擎将其值解码为 Base64 值。例如，请参见此处

    • 你可以写一个存储过程。实际上它应该已经存在于 PostgreSQL 中，至于这个（谁声明：“ ...为 lstat 字段添加了示例 postgresql 存储过程...... ”）；

    • 你可以编写一个小 PERL 脚本，查询目录并查看解码内容

    • ...

    希望这就足够了;-)

    更新 1

    我刚刚发现了BVFS API的存在，明确地“ ......主要用于希望为 Bareos 开发新 GUI 界面的开发人员...... ”。

    这些 API 提供了一组新的命令（所谓的“点命令”），包括一个有趣的命令，.bvfs_lsfiles它在控制台上显示一些元数据，包括 LSTAT字段。所以：

    1. 绝对有可能在不直接访问底层 DB/Catalog 的情况下获得 LSTAT 字段。

    此外，在 BareOS 15.2 中引入了新的“API 模式 2”，增加了对 JSON 输出的支持。我刚刚测试过：

    1. 启用 V.2 API 后，返回的 JSON 对象.bvfs_lsfiles包含正确解码的文件大小字段。

    下面举个例子：

    *.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
      }
    ]
  }
}*

    所以，最后，使用最新版本的 BareOS，最初的问题似乎可以在不直接访问目录的情况下解决。

    • 1
  2. Best Answer

    虽然我很欣赏 @damiano-verzulli 的努力，但 FreeNode 上的 BareOS IRC 频道中的讨论却没有得到这样的回应：

    事实证明，Kjetil Torgrim Homme 已经编写了一个脚本来执行此操作，名为bacula-du. （以及许多其他有用的脚本！）

    它们都已列出并可从此处获取：

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

    特别bacula-du是这样解释的：

    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（1.4版）

    我必须在这里添加一个小注释。为此，它必须有权访问数据库（显然）。在默认配置中，它使用基于用户的安全机制，因此您必须以 bareos 用户身份运行命令才能使其工作，例如

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

相关问题