是否有内置冗余(例如par2)的反向增量备份解决方案？
我正在设置一个主服务器，主要用于备份。我有大约90 in的个人数据，必须以最可靠的方式进行备份，同时仍然保留磁盘空间。我希望有完整的文件历史，以便我可以回到任何特定日期的任何文件。
由于数据的大小，每周备份都不是一个选项。相反，我关注的是增量备份解决方案。但是，我知道一组增量备份中的单个损坏会使整个系列(超过一个点)无法恢复。因此，简单的增量备份不是一种选择。
我研究了许多解决这个问题的方法。首先，我将使用反向增量备份，以便使这些文件的最新版本丢失的可能性最小(旧文件不那么重要)。其次，我想用某种冗余来保护增量和备份。Par2平价数据似乎非常适合这项工作。简而言之，我正在寻找具有以下要求的备份解决方案：
incremental)
- Par2 metadata
- Efficient反向增量(以节省磁盘空间并确定最近备份的优先级)
- 文件历史记录(包括增量上的反向奇偶数据和备份数据
- )，
- 文件历史记录保留了带宽(节省带宽；不对每个增量复制整个目录)。大多数增量备份解决方案都应该以这种方式工作。
这将(我相信)确保文件完整性和相对较小的备份大小。我已经看过了许多备份解决方案，但它们都有一些问题：
metadata
- duplicity
- Bacula--简单的普通增量备份
- bup--增量和实现par2，但不是反向增量，也不保留par2 --增量、压缩和加密，但不是反向incremental
- dar --增量和par2易于添加，但不是反向增量和没有文件history?
- rdiff-backup --这对于我所需要的几乎是完美的，但它没有par2 support
到目前为止，我认为rdiff备份似乎是最好的折衷方案，但它不支持par2。我认为我可以很容易地将par2支持添加到备份增量中，因为它们不是每个备份都被修改的，但是其余的文件呢？我可以递归地为备份中的所有文件生成par2文件，但这将是缓慢和低效的，而且我不得不担心备份和旧par2文件中的损坏。特别是，我无法区分已更改的文件和损坏的文件之间的区别，我也不知道如何检查这些错误或它们将如何影响备份历史记录。有谁知道更好的解决办法吗？是否有更好的办法来处理这个问题？
谢谢你阅读我的困难和任何意见，你可以给我。任何帮助都将不胜感激。
回答 2
Stack Overflow用户
发布于 2012-05-16 08:16:34
http://www.timedicer.co.uk/index
使用rdiff备份作为引擎。我一直在研究它，但这需要我使用linux或虚拟机来设置一个“服务器”。
就我个人而言，我使用WinRAR使伪增量备份(实际上是对最近文件的完整备份)每天由预定的任务运行。同样，它也是一个“推送”备份。
它不是真正的增量(或反向增量)，但它根据上次更新的时间保存不同版本的文件。我的意思是，它保存了今天，昨天和前几天的版本，即使文件是相同的。您可以设置存档位以节省空间，但我不再费心了，因为所有备份都是小电子表格和文档。
RAR有自己的奇偶或恢复记录，可以在大小或百分比上设置。我用1% (1%)。
它可以保存元数据，我个人跳过了高分辨率的时间。
它可以是有效的，因为它压缩文件。
然后我要做的就是把文件发送到我的备份。我把它复制到另一个驱动器和网络中的另一台计算机上。不需要真正的服务器，只需要共享。但是，对于太多的计算机，您不能这样做，因为Windows工作站有10个连接限制。
因此，为了我的目的，这可能适合你，备份我的文件每天都已更新的文件，在过去7天。然后，我有另一个预定备份，备份在过去90天中更新的文件，每个月运行一次，或者每30天运行一次。
但是我使用Windows，所以如果您实际上正在设置Linux服务器，您可能会查看Time。
Stack Overflow用户
发布于 2012-02-26 19:49:56
由于没有人能够回答我的问题，我会写一些可能的解决方案，我发现了研究的主题。简而言之，我认为最好的解决方案是对ZFS文件系统进行rdiff备份。原因如下：
- ZFS校验所有存储的块，可以很容易地检测错误。
- 如果设置了ZFS来镜像数据，则可以通过从好副本复制来恢复错误。即使数据被复制了两次，
- 占用的空间比完全备份占用的空间更少。
- 原始和镜像中出现错误的几率都很小。
f 29
就我个人而言，我没有使用这个解决方案，因为ZFS在Linux上的工作有点棘手。Btrfs看起来很有前途，但是经过多年的使用还没有被证明是稳定的。相反，我有一个更便宜的选择，就是简单地检查硬盘智能数据。硬盘驱动器应该自己进行一些错误检查/校正，通过监视这些数据，我可以看到这个过程是否正常工作。它不如附加的文件系统奇偶，但总比没有好。
对于研究可靠备份开发的人来说，更多的注意事项可能很有趣：
- par2似乎是一款过时且错误的软件。zfec似乎是一种速度更快的现代替代方案。在bup中的讨论发生在不久前：https://groups.google.com/group/bup-list/browse_thread/thread/a61748557087ca07
- It's更安全地计算奇偶校验数据，甚至在写入磁盘之前。也就是说，不要写入磁盘，读取它，然后计算奇偶校验数据。从ram中执行此操作，并根据原始数据进行检查以获得额外的可靠性。这可能只适用于zfec，因为par2太慢了。
https://stackoverflow.com/questions/9247048
复制相似问题
腾讯云开发者
