当我将快照和 RAID 与 btrfs 结合使用时，我能想到的进行备份的两个主要原因似乎得到了解决。（这里所说的 RAID 是指 RAID1 或 10）
- 意外删除数据：快照涵盖此情况
- 驱动器故障和钻头腐烂
- 彻底失败：RAID 涵盖这种情况
- 驱动器返回坏数据：RAID + btrfs 的错误纠正功能涵盖了这种情况
因此，作为现场备份解决方案，这似乎运行良好，甚至不需要单独的数据存储设备！
但是，我听说 RAID 和快照都不被视为适当的备份，所以我想知道我是否遗漏了什么。
除了 btrfs 还不是成熟的技术之外，您还能想到我遗漏了什么吗？或者我的想法是正确的，这是一个有效的现场备份解决方案？
答案1
不，这不对。
如果您的文件系统或 RAID 卷损坏，会发生什么情况？或者您的服务器着火了？或者有人意外格式化了错误的阵列？
你会丢失所有数据和您认为您拥有的非真实备份。这就是为什么真实备份与您备份的数据完全不同的系统 - 因为备份可以防止相关系统发生可能导致数据丢失的事情。将备份保存在与备份相同的系统上，该系统上的数据丢失也会影响您的“备份”。
答案2
为了现场备份，快照可能足够好，前提是您定期将快照“导出”到其他地方，它在那里作为被动数据存在。
并且，定期测试您的“已发送快照”是否可以恢复。
这是我实现一些服务器的快速备份的方法：将数据存储在 ZFS 上，拍摄 ZFS 快照，发送三角洲到另一台服务器，在那里重新创建整个文件系统（减去实际运行的服务）。
当然，最好的备份是总是因此，在将快照“运送”到单独的系统后，定期对快照进行“录制”。
因此，在我的系统中，接收快照增量的服务器会定期将其所有 ZFS 池（包括早期的快照）转储到磁带中。
当然，还要测试你的成品以确保它可以恢复。
注意：您需要在静止磁盘活动期间执行快照，并且最好与数据库（如果有）协调以确保一致性；否则，治疗可能比疾病更糟糕。这就是 NetApp 和 EMC 的“实时快照”功能非常有用的原因：它们将推迟 LUN 的快照，直到使用 LUN 的数据库指示执行快照是安全的。
答案3
HopelessN00b 说过。不。
正确的备份应放在与备份设备不同的设备上。如果丢失两个或更多驱动器，会发生什么情况？如果服务器机房被烧毁，会发生什么情况？如果某人意外破坏了您的阵列，会发生什么情况？
（轶事提醒：我曾经听说过有人将 PXE 设置为自动安装最新的 Fedora。他的 UPS 出现故障。停电后，他的服务器重新启动并设置为 PXE 启动，然后...在他的数据上安装了 Fedora。我的观点是？奇怪的事情发生了。幸运的是，他有适当的备份。）
最好的情况下，你至少拥有三份数据副本，其中一份完全存储在异地，以防数据中心发生烧毁。
答案4
是的，这是存储备份的完美方式。不需要其他任何东西，甚至进行完整性检查也只是浪费时间。
先确认一下——在我给出更多建议之前……你为我的竞争对手工作，对吧？你真的为我工作，对吧？不？哦。
抱歉，NUTS。不，一点也不。抱歉，兄弟。
问题是，你完全可以接受 (a) 系统和 (b) 操作系统层面发生的任何错误。你基本上只能防止有人删除某些数据。很好。这是一个经常发生的错误。
您没有保护的是：
- 电源峰值导致机器损坏。我经历过这种情况，也见过这种情况。
- 一些有缺陷的 RAID 控制器或内存在磁盘上写入 sh** - 一切都出问题了。
还有一长串其他的事情。
这是当然的，除非你为我的竞争对手工作 - 你总是请做好备份：
- 在另一台计算机上
- 至少要隔离电源尖峰（即使您有 USV）。
这就是磁带之所以如此重要的原因——它们没有连接，任何短路（火灾或洪水）都不会损坏它们。电源峰值——磁带读取器和机器人可能会受到影响，但不在读取器中的磁带不会受到影响。
最好的方法是进行异地备份（我是否已经提到过火灾和洪水之类的事情？）（再说一次，当您为竞争对手工作时 - 不存在建筑物火灾这种事，完全没有必要，火灾保险也是如此，请省下这笔钱）。
现在，您可能会想“哦，洪水永远不会发生”。确保您确定。看，这是 2009 年 9 月 9 日 Vodaphone 数据中心发生洪水的视频。我相信您会明白内部/计算机备份的问题出在哪里：