不要问为什么。我需要设计一个增量文件备份解决方案（写入 USB 连接的磁盘阵列），该解决方案具有超级简单的界面，允许任何最终用户（甚至是接待员）将任何文件的版本还原到他们的本地工作站。
我最初的想法是设计一个解决方案，将最后 10 个版本（或过去 30 天内的所有版本）存储在同一目标文件夹中，但在文件名后附加一个递增数字（filename_1.ext filename_2.ext）。最终用户可以看到文件名的日期时间，以确定该版本的创建时间。最终用户可以使用 SAMBA 通过 Windows 资源管理器中的映射驱动器浏览文件。我能想到比这更简单的方法。
以下是服务器端可能需要解决的一些潜在挑战：
备份频率与性能有关。我们讨论的是一个可能包含 100,000 个文件和 5TB 数据的数据存储文件夹。增量备份需要每小时至少运行一次。因此，它必须是一个专为处理相当大的文件集合而设计的解决方案。我预计这可能不是问题，因为文件更改量很低，每小时最多更改 100 个文件。
数据重复。是的，存储很便宜，但如果有多个版本，后端存储需求就会很大。我认为不可能进行数据重复删除，并让最终用户能够使用简单的 SAMBA 文件共享浏览文件版本。（查看了 RDIFF，您需要运行 rdiff 命令才能恢复。）
因此，我愿意接受一种解决方案（免费或低成本），即用户无需将驱动器映射到备份文件夹，而是可以打开 Web 界面浏览文件并根据需要下载。虽然不像映射驱动器那么简单，但这将允许后端处理文件版本的重建。
有什么解决方案的建议吗？
答案1
一种低技术的解决方案是使用带有--link-dest选项的 rsync。可以设置它来创建增量快照，这些快照对用户来说就像完整副本一样。诀窍是，更改的文件会被复制，而未更改的文件会硬链接到上一个快照中的副本。
Ubuntu 软件中心提供的脚本rsnapshot可自动执行 rsync 的这种使用。然后，问题就变成了在用户的系统上安装不同的挂载点、定时备份脚本使用的可写挂载点以及用户在其主文件夹中随时可见的只读挂载点。或者，您可以设计另一种方式来访问备份，正如您所建议的那样，使用浏览器。