我在为一家小公司制定备份解决方案时遇到了问题。
大纲
一个 NFS 共享（在网络中的 Linux 服务器上）
5 个 HDD（周一至周五）
需要每天更换它们（通过 USB-Docking-Station 连接），
然后从网络上的客户端安装它们并复制数据。
共享始终位于同一位置，每个 HDD 始终安装在此共享下。
问题：
1) 无法安全地卸载硬盘，一旦客户端连接到共享，设备就会一直处于繁忙状态。即使服务器和客户端之间没有任何联系）
2）更换 HDD 后（例如：换出 monday-hdd，放入 tuesday-hdd）客户端无法保持连接并立即使用新放入的 HDD，我必须断开共享并重新连接。
是否有一个解决方案可以让我
a) 每天在服务器和客户端上切换磁盘而无需强制 umount -l？
以及
b) 使客户端能够继续使用连接的共享，而无需重新连接？
答案1
也许每天有不同的份额，并在切换时同时插入 2 个驱动器
插入星期二驱动器 安装为星期二文件夹 启动 NFS-星期二共享 使用客户端脚本卸载并安装新的一天的共享（相同的本地安装） 客户端现在正在使用新驱动器 停止 NFS-星期一共享 卸载星期一驱动器，拔下电源，并放入存储中
重复上述步骤？应该可以相对轻松地编写脚本（无需进行物理动作）
答案2
使用 NFS 共享进行备份通常不是一个好主意。它是一个持久连接（或等效连接），备份在文件系统上实时可用，并且需要维护 NFS 客户端，如上所述。
为什么不使用 bareos 或者只是 ssh 备份？
如果使用 ssh，我会在每个硬盘中创建名为“mon”、“tue”等的目录，具体取决于该磁盘适用于一周中的哪一天。
然后客户端可以通过 ssh 将备份传输到磁盘：
tar ... | ssh $backupuser@$backupserver "cat > /mnt/$(date +%a|tr A-Z a-z)/$HOSTNAME.tar"
这样，如果安装了错误的磁盘（或没有安装磁盘），星期几目录将不存在，备份将失败，而不是覆盖以前的备份。如果配置正确，您的监控（或 cron 作业）应该会就此发出警报。
如果您真的无法避免使用 NFS，至少可以考虑在备份之前挂载 NFS 共享，并在备份之后立即卸载。但这是一个不靠谱的解决方案。例如，如果备份脚本被终止，第二天的备份将无法挂载 NFS 共享。
从长远来看，设置 bareos 可能是一个更好的解决方案。