在redis.io站点中，它指出RDB不如AOF持久。 这是否意味着存在数据库损坏的可能性，如果在保存操作期间电源丢失，则完全丢失数据？
如果底层数据存储有问题，RDB文件可能会损坏。 Redis包含一个实用程序redis-check-dump来validation文件，您可以使用它来检查新写入的转储文件的一致性。
如果RDB在启动时损坏，则Redis将无法启动并报告一个有点神秘的错误。 有一个拉请求：
https://github.com/antirez/redis/pull/1744
使检查程序自动运行，但尚未合并（还）。
转储文件写入后台线程，这意味着它不能包含密钥空间的100％最新副本。 为了得到这个，你需要使用AOF文件，并在每次写入之后将其设置为同步（这会影响性能）。
Redis架构允许您为此构build许多不同的解决scheme。 你可以用“never”fsync打开主服务器上的AOF文件，然后创build两个从服务器，其中一个服务器每隔10分钟创build一个RDB文件，另一个服务器使用带“always”或“everysec”fsync的AOF文件。 只要磁盘没有失败，这将给你主机上的内置冗余，但如果是这样的话，你可以从从机取得AOF文件，并用它把主机带回来。 如果失败了，你可以去RDB从机，但在这种情况下，你可能会丢失自从最后10分钟转储以来写入的数据。
这种灵活性是使Redis如此强大的一部分：您可以根据要存储的数据select要使用的冗余级别。
或者，您可以使用托pipe的Redis服务，让他们担心细节。
.rdb本身“不能”被损坏，因为转储首先被保存到一个tmp文件并在之后被重命名为转储。 当然，重命名时可能会出错。 所以有一个非常小的机会，但不太可能。