我之前写过一篇介绍 Keybase 加密网络服务体验 的文章，里面提到 Keybase 对于用户的公共目录提供了 Keybase.pub 这个静态文件托管网站，方便其它用户访问 Keybase KBFS 里保存的公共文件。

所以之前我都会把我的 MDwiki 知识库 也同步更新到我的 Keybase 下的 wiki 公共目录，这样就可以把我的 nocwat.keybase.pub 作为一个备用的 Wiki 网站，如果我的 VPS 服务器无法访问，也可以通过 Keybase.pub 访问 Wiki 知识库。

然而最近我才后知后觉地发现原来 Keybase 从今年 3 月份开始就已经关闭了 Keybase.pub 静态文件托管服务，理由则是使用这项服务的用户数量太少，因此也就需要考虑新的 Keybase 静态文件托管方案了。

kbpbot

我稍微看了一下 Keybase Book 中关于 Kebyase Sites 的介绍文章，里面关于 Keybase.pub 的介绍还没有更新，不过还好目前 Keybase 提供的 kbpbot 机器人还是可以正常使用的。

kbpbot 机器人原本是为了支持用户使用自定义域名发布网站而开发的，为自定义域名配置正确的 CNAME 和 TXT 记录之后，访问域名时 kbpbot 就可以读取指定的 Keybase 目录中的文件，然后将静态文件内容返回给访问者。

由此也可以看出，kbpbot 也必须有访问对应的 Keybase 目录的权限，自定义域名静态文件托管才能正常工作。得益于 Keybase KBFS 文件系统的设计，公共目录、私有目录、团队目录都可以给 kbpbot 赋予访问权限：

提示

KBFS 文件系统中的所有文件都会自动签名加密，如果需要了解更多关于 KBFS 的使用方式，可以参考 Keybase 官方的 Introducing the Keybase Filesystem 这篇文章。

• 公共目录：

  kbpbot 默认就可以访问用户的所有公共目录，不需要专门配置，例如我的 Wiki 知识库的 KBFS 路径就是：/keybase/public/nocwat/wiki；

• 私有目录：

  用户只需要在私有目录下建立一个自己和 kbpbot 能访问的子目录，这里多个 Keybase 用户名使用逗号隔开即可，例如：/keybase/private/yourname,kbpbot/XXX；

• 团队目录：

  团队目录则更加简单，将 kbpbot 作为读者加入你的团队，然后使用团队目录路径，例如：/keybase/team/yourteam/XXX。

然后是最重要的自定义域名配置，按照 Keybase Sites 文章里介绍的方式添加对应的 DNS 记录即可。例如我的 MDwiki 知识库使用的是 wiki.vp8.win 自定义域名，为 kbpbot 添加如下 DNS 记录：

• CNAME 记录：

  名称为 wiki，记录值为：kbp.keybaseapi.com；

• TXT 记录：

  名称为 _keybase_pages.wiki，记录值为：kbp=/keybase/public/nocwat/wiki。

其中比较关键的就是 TXT 记录了，kbp=XXX 记录值就是用来告诉 kbpbot 机器人，用户访问此域名时需要访问什么 KBFS 目录。如果你用的是私有目录，把 TXT 记录值换成类似于 kbp=/keybase/private/yourname,kbpbot/XXX 就可以了。

域名配置完成生效之后，就可以通过自定义域名访问你的静态站点了。由于 kbpbot 还支持自动申请和更新 Let’s Encrypt HTTPS 证书，用户访问站点时将会自动使用 HTTPS 访问，完全不需要维护 HTTPS 证书之类的，这一点还是非常方便的。

另外 kbpbot 甚至还支持使用 Keybase Git 代码仓库来访问静态文件，只是不支持私有代码仓库（只有自己才能访问私有 Git 仓库），需要使用团队仓库，同样也要将 kbpbot 作为读者加入你的团队。

例如团队名称还是上面的 yourteam，如果建立一个 teamwiki 仓库，就可以使用 keybase://team/yourteam/teamwiki.git 这种地址来 clone 仓库了，然后存放一些静态文件内容并提交。

最后我们把 Git 仓库对应的域名 TXT 记录值修改为：kbp=git@keybase:team/yourteam/teamwiki，用户就可以通过域名 HTTPS 访问静态站点了。

同步 KBFS

我的 Wiki 主站是放在目前博客的 VPS 服务器上运行的，整个 Wiki 知识库目录通过 Resilio Sync 与本地的 Windows / Linux 电脑进行同步，本地使用 Markdown 编辑器修改 Wiki 内容后就可以自动更新到 VPS 服务器上。

Keybase KBFS 对应的 Wiki 目录，我则是直接在 Linux 上使用 rsync 命令将同步过的本地 Wiki 目录更新到 Keybase，好处就是可以基于 rsync 的同步机制自动只更新差异的文件，这里需要先启动 Keybase 应用程序哦：

~# rsync -ruv --exclude=notes.sqlite --exclude=.sync ~/Documents/wiki/ /run/user/$(id -u)/keybase/kbfs/public/nocwat/wiki/

rsync 的 --exclude 参数可以忽略不需要同步的文件，这里我指定 notes.sqlite 忽略 Markdown 编辑器使用的数据库文件，并指定 .sync 忽略 Resilio Sync 使用的内部同步目录。

Linux 系统上 rsync 的目标目录是：/run/user/$(id -u)/keybase/kbfs，与当前本地用户的用户 ID 有关；Windows 系统如果 Keybase 客户端启用了在资源管理器中显示 KBFS 盘符，rsync 的目标目录可能就是这样：K:\（实际的 KBFS 盘符可能并不是 K 盘）。

总结

我的 MDwiki 知识库在 Keybase 上的备用网站 wiki.vp8.win 目前已经正常运行一段时间了，而且 Keybase 的静态文件托管服务在国内访问也很正常，并没有出现被墙之类的问题。

由于 kbpbot 除了 Keybase 公共、私有和团队 KBFS 目录，还支持使用 Git 仓库，我们也可以将类似 Hexo 这种静态博客通过 Keybase Git 来管理，本地修改构建之后提交到仓库更新，这样小伙伴们通过 Keybase 来托管静态博客也还是比较省事的。

虽然 Keybase 被 Zoom 收购之后发展势头不太好，更新节奏也变慢了，但还是希望 kbpbot 的静态文件托管服务能继续维持下去，毕竟 Keybase 提供的各项加密网络服务还是非常出色的，祝大家玩的开心哦。

之前为了能在 Windows 上使用 Bash 等类似 Unix（Linux）系统的体验，我都是安装了 Cygwin、MSYS 等运行环境，都体验上都存在一些问题：Cygwin 上的程序基本都需要重新编译出基于其运行库（cygwin1.dll）的版本，MSYS 虽然提供了 Linux 下常用的开发工具链、移植过的运行库等等，但基本还是受限于 Windows API 本身的。

当我看到 Windows 10 Build 14316 内部预览版时爆出的 Bash on Ubuntu 功能之后还是比较期待的，因为微软并不是以虚拟机的方式运行 Ubuntu 系统，而是直接集成了新的 Windows Subsystem for Linux 子系统，这样能直接在 Bash on Ubuntu 环境里编译运行 Linux 程序还是非常方便的。

考虑到预览版稳定性的问题，我一直没有加入 Win10 Insider 预览体验会员，这几天看到 Win10 Redstone 1 年度更新到来之后终于可以直接体验了。虽然我使用的 Win10 企业版一直接收不到更新推送，而且使用微软官方的 Media Creation Tool 也无法在企业版上更新，但还好还是可以直接下载 Redstone 1 企业版的 iso 进行更新。

安装体验

Win10 年度更新的持续数小时的痛苦安装过程这里就不表了，更新完成后首先在设置中开启开发者支持，然后在 控制面板 - 程序和功能 中开启 Windows Subsystem for Linux 功能，开启之后需要重启系统，重启之后在命令行中运行 bash 命令下载安装，根据你的网络情况可能又需要一两个小时（强烈建议挂代理的），安装完成之后会提示配置用户，接着就可以正常启动 Bash on Ubuntu 了：

第一步就可以先运行 sudo apt-get update 更新 Ubuntu 软件仓库，看起来一切正常：

另外可以确认下 Windows 10 上运行的 Ubuntu 子系统的基本情况：

从上面的截图可以看出 Bash on Ubuntu 会把所有 Windows 分区都挂载到 /mnt 目录下方便使用（这点和 Cygwin 的 /cygdrive/c 以及 MSYS 的 /c 路径有点类似哦），默认运行的是 Ubuntu 14.04 LTS 系统，用户看到的 Linux kernel 是 3.4.0 版本。

接着就可以安装运行一些常用的 Linux 命令了，awk、sed、svn、git 等和系统内核关系不大的命令都能正常工作，ifconfig 和 ping 等命令会运行失败，体验一圈下来还是能满足我的使用需求的。

rsync 备份性能测试

我之前写过一篇文章 rsync在 Linux/cygwin/msys 环境下的备份性能对比 对比 Linux 原生的 rsync 命令和 Windows 上几种常见的非原生 rsync 实现的备份性能，结果不出意外 Linux 原生 rsync 的效果是最好的。

现在既然 Win10 已经支持了还算完整的 Ubuntu 子系统，那么我就可以拿 Ubuntu 子系统里的 rsync 命令来测试一下备份文件的性能到底如何了，而且这里值得一提的是 Bash on Ubuntu 安装好之后就已经自带 rsync 命令了（没有也可以妥妥的 apt-get 自动安装哦）。

先看看 Bash on Ubuntu 自带的 rsync 命令是 3.1.0 版本的，可以直接和我们目前使用的存储服务器配合测试：

为了对比方便我在相同的客户端上分别运行 RHEL6 Linux 系统和开启了 Bash on Ubuntu 的 Win10 系统使用 rsync 命令进行文件备份的上传和下载性能测试，存储服务器上运行的是标准 rsync 服务器（没有开启 SSH 用户验证）。

测试中也使用和上面的备份性能对比文章相似的配置，服务器使用 24 个 SATA 盘建立 RAID0 磁盘阵列做底层存储，客户端和服务器之间都是千兆网络，客户端上的文件读写都使用内存文件系统（Linux 上使用 tmpfs，Windows 上使用 ImDisk 工具生成内存盘）防止客户端本地硬盘读写性能成为瓶颈。

先看看 RHEL6 Linux 系统下的 rsync 备份性能结果：

/dev/shm # rsync -hv 0.dat test@192.168.1.35::sync/
Password:
0.dat

sent 1.61G bytes  received 27 bytes  82.50M bytes/sec
total size is 1.61G  speedup is 1.00

/dev/shm # rsync -hv test@192.168.1.35::sync/0.dat .
Password:
0.dat

sent 59 bytes  received 1.61G bytes  91.93M bytes/sec
total size is 1.61G  speedup is 1.00

可以看到 Linux 系统下 rsync 写一个大概 1.6 GB 的文件可以达到 82.50 MB/s，读可以到 91.93 MB/s。

然后在 Win10 的 Bash 环境中同样使用自带 rsync 命令进行测试：

zzm@ZZM-VOLANS:~$ rsync -hv 1.dat 192.168.1.35::sync/
1.dat

sent 1.57G bytes  received 30 bytes  89.90M bytes/sec
total size is 1.57G  speedup is 1.00

zzm@ZZM-VOLANS:/mnt/h$ rsync -hv 192.168.1.35::sync/1.dat .
1.dat

sent 45 bytes  received 1.57G bytes  95.34M bytes/sec
total size is 1.57G  speedup is 1.00

看起来结果还是比较惊喜的，Win10 Bash 上的 rsync 命令可以基本跑满千兆网卡的带宽，备份性能甚至比 Linux 上的效果还好了那么一点点。这样不得不说我之前写的那篇文章里总结的 Windows 推荐使用 Cygwin 做 rsync 客户端的建议在 Bash on Ubuntu 推出之后就要过时咯。

总结

从 Win10 年度更新的简单试用和性能测试情况来看，Bash on Ubuntu 目前还算比较符合我的预期的，毕竟我最想要的直接在 Windows 上编译 Linux 二进制程序就更加方便了，看起来也不需要专门开虚拟机来进行编译工作中需要用到的 Linux 内核和应用程序了。当然目前 Bash on Ubuntu 仍然有不少问题和限制（毕竟还是 beta 阶段），还是希望微软能在后续更新中解决咯，祝大家玩的开心。

近日在 Linux 环境中做版本迁移的时候遇到一个问题：需要将一个目录遍历拷贝到另一个目录中，但需要忽略其中的某些文件，由于目录中东西比较多，忽略的项也不好一一指定。普通的 cp 命令并没有排除某个文件或文件夹的参数，比较丑陋点可以 cp -r 拷贝完目录之后再去删除无用的，但如果做批量脚本操作就不爽了，经过实际试验之后暂时找到两个比较好的方法。

1、使用 rsync 进行拷贝：

rsync 本来是文件同步备份的工具，相对于普通的 cp 命令，rsync 在控制方面就强多了，而且 rsync 对遍历目录也支持，有 --exclude 参数可以忽略指定的文件或文件夹。

rsync -vaP --exclude=".*" --exclude="Makefile" dir1 /home/dir2

如上面演示的就可以排除掉隐藏文件和 Makefile 文件，-a 参数已经包含遍历处理参数 -r。

2、使用 find 加 cpio 进行拷贝：

备注：此方法来自 Advanced Bash-Scripting Guide，需要了解的童鞋自己去参考了。

用过 find 的童鞋都知道，find 对文件的过滤那是非常强大的，配合 cpio 来进行目录的遍历拷贝就可以实现过滤指定的文件或文件夹，当然也可以做到只备份特定的文件或文件夹，你可以用 find 的各种过滤参数达到拷贝哪天的文件，拷贝近期更改的文件等特殊效果，而且 find 支持正则表达式，这种方式想比第一种使用 rsync 跳过文件的方式更加灵活，因此非常推荐使用此方式进行目录拷贝。

cd dir1
find . -regextype posix-egrep -mindepth 1 ! -regex './(dev|tmp)($|/.*)' ! -name Makefile -a ! -name .svn | cpio -admvp /home/dir2

小解释下：

find 的 -regextype 参数指定正则表达式类型，posix-egrep 为 egrep 用的扩展正则表达式，-mindepth 使 find 的输出中不包括目录本身，-regex 参数指定过滤的文件的正则表达式，-regex 前面的感叹号表示跳过，'./(dev|tmp)($|/.*)' 这个正则表达式即表示跳过目录中的第一层 dev 和 tmp 目录以及下面所有的文件和文件夹，最后两个 -name 指定要跳过文件名为 Makefile 和 .svn 的文件，这样在备份版本库的时候非常有用。

cpio 命令将 find 的输出文件列表依次拷贝到 /home/dir2 目标目录中，-a 表示不更新文件的访问时间，-d 指定自动创建目录，-m 指定保留文件的修改时间，-p 指定 cpio 工作在 Copy-pass 模式，这是专门用来拷贝目录树的一种模式。

PS：如果有更加简单的方法，欢迎提出指正哦~~~ ^_^

rsync是一个开源免费的文件同步和备份工具，可用于本地备份，本地与远程服务器之间的备份，可以实现增量和差异备份，而且由于比较好的算法，在文件备份速度上也相对其它一些文件备份工具有明显的优势。

但 rsync 一直以来没有 Windows 下的原生客户端，都是基于 cygwin 环境实现，实际备份性能会受一些影响，近日看到 rsync 的 基于 MSYS 的 Win32 原生客户端已经被 port 出来，故简单做下性能对比测试。

测试环境：

rsync服务器为 RHEL5 Linux 64bit，8个SATA盘的RAID0做下层存储，采用单千兆网络和千兆交换机
rsync客户端为：RHEL5 Linux 64bit，Windows 2003 Enterprise 32bit

测试时 rsync 均通过匿名方式访问，不经过SSH做用户验证，由于考虑到测试的 rsync 客户端的系统盘速度有瓶颈，客户端文件读写都通过内存文件系统来实现（Linux 上使用 tmpfs，Windows 上使用 ImDisk 模拟内存盘）。

使用同样的客户端主板分别在 Linux 和 Windows 内存中产生 1.5GB 的测试文件，然后通过 rsync 客户端进行备份到服务器（写操作）和从服务器上恢复（读操作）的操作。

备份命令示例：
rsync -hv x.dat 192.168.1.125::rsync0/

测试软件列表：

• 标准 Linux rsync 客户端（RHEL 5 系统自带）
• cygwin rsync 客户端
• MSYS rsync 客户端
  http://sourceforge.net/projects/mingw/files/MSYS/Extension/rsync/
• RsyncWin32 客户端
  http://sourceforge.net/projects/rsyncwin32/

测试结果：
 

从测试结果看，由于 rsync 本身面向类 Linux 环境开发，在 Linux 系统中有着非常好的性能，cygwin rsync 与 Linux 相比有一定差距，但实际使用中还是比较稳定的，而 MSYS rsync 还处于测试阶段，虽然没有出现备份错误，但在千兆网络环境下性能非常差，RsyncWin32 则相对而言问题比较多，备份过程中甚至会出现备份错误。

综上看来，目前在 Windows 上使用 cygwin rsync 做备份客户端仍然算是比较好的解决方案，MSYS rsync 的问题可以啥时候有空再看看咯。