我有一个备份服务器，它创建要备份的目录树的xz压缩tar档案。这些 tar 存档可能会变得很大（多 TB），可以split分成多个部分（2.5TB），并且每个部分都被写入 LTO-6 磁带，然后这些磁带会去异地。
现在我想添加加密。我可以在拆分之前使用公私密钥加密以及一个或多个收件人（管理员公钥）对 tar 存档进行 GPG 加密。
然而，在恢复的情况下，至少有一位管理员需要将他的私钥放在备份服务器上，因为文件太大而无法在其他任何地方解压。
GPG 在幕后使用混合加密方案，使用对称密码（如 AES）和会话密钥，只有该会话密钥才能为接收者加密公私密钥。
有没有办法让管理员提供会话密钥来解密要恢复的文件，而无需将私钥放在备份服务器上？
我当然可以重新发明轮子：
但是是否有“标准”或内置或最佳实践方法来实现上述目标？
本质上，我正在寻找一个完全无声的、非交互式版本的
freebsd-update fetch
freebsd-update install
和
portsnap fetch update
我正在考虑一个基于 ZFS/iSCSI 的架构，用于在普通 PC 硬件的小节点上运行并运行 FreeBSD 9 的 HA/横向扩展/无共享数据库平台。
它会起作用吗？什么是可能的缺点？
建筑学
存储节点具有直接连接的廉价 SATA/SAS 驱动器。每个磁盘都导出为单独的 iSCSI LUN。请注意，该层不涉及 RAID（无论是硬件还是软件）、分区、卷管理或任何类似的东西。每个物理磁盘只有 1 个 LUN。
数据库节点运行 ZFS。ZFS 镜像 vdev 是从来自 3 个不同存储节点的iSCSI LUN 创建的。在 vdev 之上创建了一个 ZFS 池，并在其中创建了一个文件系统，该文件系统又支持一个数据库。
当磁盘或存储节点出现故障时，相应的 ZFS vdev 将继续在降级模式下运行（但仍有 2 个镜像磁盘）。一个不同的（新的）磁盘被分配给 vdev 来替换出现故障的磁盘或存储节点。ZFS 重新同步发生。如果故障存储节点或磁盘再次可用，它总是会被完全回收。
当一个数据库节点出现故障时，该节点以前使用的 LUN 是空闲的。启动一个新的数据库节点，它从发生故障的数据库节点留下的 LUN 重新创建 ZFS 虚拟开发/池。出于高可用性的原因，不需要数据库级复制。
可能的问题
如何检测vdev的降级？每 5 秒检查一次？ZFS 有任何可用的通知机制吗？
甚至可以从构成 vdev 的现有 LUN 重新创建新池吗？有什么陷阱吗？