obnam的预期表现是什么？或者：为什么这么慢？

最近几天，我一直在使用obnam，尽管它看起来非常有前途，并且似乎可以提供备份工具中我想要的所有功能，但是我对它的性能感到非常失望。实际上，它是如此之慢，我怀疑这里的obnam甚至不是错误，而是我的环境中的某种原因导致了它。

所以我主要是想知道，是否还有其他人正在使用obnam或是否足够了解其内部结构以识别问题。

从目前为止我所知道的，obnam似乎为每个备份的文件派生了一个单独的gpg进程。从htop，strace和iostat来看，初始备份的速度主要受持续派生的限制，而CPU和驱动器（不涉及网络）大多空闲于20％以下的利用率。

我的备份总计约有500.000个文件，总共有170 GiB数据。因此，对于每次备份运行，gpg都会分叉500.000次。实际上，对于最初的运行几乎要花费整整一天的时间，对于大多数文件保持不变的另一次运行，则要花三个小时以上的时间，我什至都不感到惊讶。但这真的是用户应该期望的性能吗？为了进行比较：rsnapshot的增量运行（相同的数据，同一台计算机，相同的驱动器）大约需要4分钟。当然，不涉及加密，但这不应该那么重要。

因此，要明确地说：其他人的机器是否每秒也不能运行gpg（加密一小块数据）超过50次，最终使obnam成为几乎无法使用的缓慢工具？还是只是我？

（FWIW，我的计算机是Core i5-2500，具有8G RAM和SSD驱动器，运行Gentoo。备份已完成到HDD上，但是我看不到备份到SSD的任何区别，因为它不是I / O。 -界。）

这是有关如何加快Obnam速度的很好的阅读（可能会快10倍）：http ://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

摘要：在命令行或配置文件中添加“ --lru-size = 1024 --upload-queue-size = 512”。请注意，这会稍微增加obnam的内存使用量。

我想我可以通过几种方式来解决这个问题。首先，我将尝试使用以下方法自己进行诊断。

1. obnam日志

对于初学者，您可以obnam像这样记录消息：

$ obnam --log obnam.log

您也可以通过--log-level开关提高日志记录级别，以获取更多详细信息。

--log=FILE          write log entries to FILE (default is to not write log
                    files at all); use "syslog" to log to system log, or
                    "none" to disable logging
--log-level=LEVEL   log at LEVEL, one of debug, info, warning, error,
                    critical, fatal (default: info)

2.分析

您还可以obnam从该项目的FAQ中的摘录中获取有关正在执行的操作的配置文件：

如果OBNAM_PROFILE环境变量包含文件名，那么概要分析数据将存储在此处，以后可以使用以下命令查看 obnam-viewprof：

  $ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less

使用还可观察到与特定设置无关的性能问题obnam-benchmark tool。

3.开票

如果仍然不确定是否要进行性能调查，那么我可以在该项目的网站上打开一张票。据我所知，开发人员的反应有些灵敏，他们可能是最能消除项目问题的人。

obnam似乎仅使用SFTP，因此应该很清楚是什么引起了问题。我还将考虑单独对SFTP性能进行基准测试，以便在尝试从obnam测试本身获取此信息之前，可以了解理论上系统与网络连接的最大值。

附加数据点

找到了这篇博客文章，作者在此类别中比较了几种选择。文章标题为：比较rsnapshot和obnam计划的大型备份。

这篇文章强调了IMO的一些非常差的性能，obnam这似乎与您所描述的内容息息相关。

表现

完全备份/ home（花了几天！）后，几天后又进行了一次新运行（通过Linux time命令计时）：

备份了3443706个文件，以127h48m49s的平均速度214.2 KiB / s的速度上传了94.0 GiB; 1.24 GiB（0 B / s）实际7668m56.628s用户4767m16.132s sys 162m48.739s

从obname日志文件中：

   2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0
   2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 
   2012-11-21 23:09:36 INFO Backup performance statistics: 
   2012-11-21 23:09:36 INFO * files found: 3443706 
   2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 
   2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s
   2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends
   2012-11-21 23:09:36 INFO obnam version 1.2 ends normally

因此：大约需要5天才能备份大约100 GB的已更改数据…无论是在CPU方面还是在RAM方面，机器上的负载都不是很高。/ backups / backup_home中的磁盘使用量为5.7T，/ home的磁盘使用量为6.6T，因此似乎有一些dedup。

快照性能

/ home的完整备份（根据日志文件）：

   [27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started   
   [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid 
   [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/    
   [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ 
   [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/
   [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/
   [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid
   [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully

因此：〜1.5天即可获得6.3TB的完整备份。一天后进行增量备份：

     [29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started
     [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid
     [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/
     [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/
     [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/
     [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid
     [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully

因此：15分钟...，更改后的数据总计为21GB。

不够彻底，但要提一提的缺点之一obnam是它与.vs 比较慢attic。

Obnam优点：

• 有据可查
• 活动邮件列表
• 可用包

Obnam缺点：

• 非常慢
• 大备份

阁楼专家：

• 小得多的备份（即使没有重复数据删除）
• 更好的重复数据删除
• 快多了

阁楼缺点：

• 存储库格式未记录
• 不是一个庞大的用户社区

显示了一些测试数据，似乎表明这obnam确实很慢。

通过本地wifi连接从本地SSD到远程HD：

    rsync:           0:24  0:01
    Attic ssh:       0:28  0:05
    Attic sshfs:     0:51  0:08
    Obnam sftp:      8:45  0:21
    Obnam sshfs:    25:22  0:22

参考文献

• Obnam调整博客文章

Obnam的默认配置（自2015年2月8日起）不适用于备份包含大量小文件的目录。我遇到了与上述完全相同的问题。

对我来说，解决方案是在命令行中添加--lru-size = 8192 --upload-queue-size = 8192。这解决了问题，使沮丧的用户变成了非常满意的Obnam用户。（我现在在我的标准配置文件中有这些设置。）

不幸的是，Obnam的教程没有预先提到这些设置的重要性。该常见问题解答提供了更多详细信息。在具有许多小文件的系统上，实际上必须设置性能参数。