我可以考虑采取备份的两个主要原因似乎是照顾当我同时使用快照和RAID与btrfs。 （这里是RAID，我的意思是RAID1或10）
因此，作为一个现场备份解决scheme，这似乎工作正常，它甚至不需要一个单独的数据存储设备！
但是，我听说RAID和快照都不被认为是正确的备份，所以我想知道我是否错过了任何东西。
除了btrfs还不是一个成熟的技术，你能想到我错过的任何东西吗？ 还是我的想法是正确的，这是一个有效的现场备份解决scheme？
不，这不对。
当您的文件系统或RAID卷损坏时会发生什么？ 或者你的服务器被着火？ 或者有人不小心格式化了错误的数组？
你失去了所有的数据， 以及你认为的非真实备份。 这就是为什么真正的备份与备份的数据完全不同的系统 – 因为备份可以防止有问题的系统发生数据丢失。 将备份与备份保持在同一个系统上，并且该系统上的数据丢失也会影响到您的“备份”。
对于现场备份， 只要您定期将快照“导出”到其他地方，作为被动数据存在，快照可能就足够了 。
并定期testing您的“发货快照”是否可以恢复。
这就是我如何实现我的一些服务器的快速备份：在ZFS上存储数据，获取ZFS快照，将delta发送到另一个服务器，在那里整个文件系统被重新创build（减去实际的服务运行）。
当然，最好的备份总是不在现场。 因此，在将快照“运送”到单独的系统之后，定期对快照进行“带出”。
因此，在我的系统中，接收快照增量的服务器会定期将其所有ZFS池（包括较早的快照）转储到磁带。
当然，testing你的磁带，以确保它可以恢复。
注意：您将希望快照在静默磁盘活动期间发生，并且最好与数据库协调（如果有的话）以确保一致性; 否则，治疗可能比疾病更糟糕。 这就是为什么NetApp和EMC的“实时快照”function非常有用：他们会推迟LUN的快照，直到使用LUN的数据库表明执行快照是安全的。
HopelessN00b说什么。 没有。
正确的备份与正在备份的设备位于不同的设备上。 当你失去两个或更多的驱动器会发生什么？ 当你的服务器房间烧毁时会发生什么？ 有人不小心摧毁了你的arrays会发生什么？
（轶事提醒：我曾经听说过一个有PXE设置自动安装最新的Fedora的人，他的UPS失败了，停电后，他的服务器重新启动，并设置为PXE启动，并… …安装Fedora的数据。点？发生奇怪的事情，幸运的是，他有适当的备份。）
您最好至less有三份数据，一份完全存储在异地，以防数据中心烧毁。
正确实施的快照必须得到你的存储的支持，因为体面的备份将它们用作创build备份作业的第一个阶段。 然而，使用快照进行主备份是个不错的主意。 原因：
1）快照和后端存储器可能会失败。 所以真正的备份必须使用单独的主轴设置，否则很可能同时丢失主要工作集和备份数据。
2）快照“咀嚼”可用空间。 使用昂贵且快速的存储来处理当前的热数据和卸载的快照以及备份是一种冰冷的数据，以便更便宜和更慢的存储是合理的。 它工作得很好，1）顺便说一句。
3）快照通常会减慢整个过程。 大多数系统使用写入时复制，并且这种方法创build碎片。 写入redirect速度更快，但吃了很多空间。 很less有供应商正确实施快照。 NetApp与WAFL和敏捷存储与CASL（我不与他们中的任何一个）。 几乎每个人都有问题。 例如，Dell Equallogic触发每个单字节更改15 MB页面更新（和浪费）。 这太贵了。
是的。 这是存储备份的完美方式。 没有什么是必要的，甚至做ingtegrity检查只是浪费时间。
只是为了确认 – 在我给出更多的build议之前…你为我的竞争对手工作，对吗？ 你真的吗？ 没有？ 哦。
对不起，NUTS。 一点都不。 对不起，老兄。
问题在于，您完全接受发生在（a）系统和（b）操作系统级别的任何错误。 你基本上只是防止有人删除一些数据。 尼斯。 这是一个经常发生的错误。
你没有保护的是：
还有一大堆其他的东西。
这是自然而然的，除非你为我的竞争对手工作 – 你总是需要做一个备份：
这就是为什么磁带摇滚 – 他们没有连接，任何短路或火灾或洪水不会伤害他们。 电源尖峰 – 磁带读取器，也许是机器人，但不在读者的磁带不会受到影响。
最好是备份异地（我是否已经提到了像火灾和洪水已经？）（再次，当你为竞争对手工作 – 没有这样的事情像build筑物的火灾，这是完全不需要的，因为是火灾保险，请，省钱）。
现在，你可能会想“哦，洪水永不发生”。 确保你确定。 看，这是一个09.09.09洪水的vodaphone数据中心的video。 我相信你会明白在计算机备份中的问题在哪里：
从两个RAID-1驱动器在半小时之内失败的经验教训：RAID 不是一个备份机制，不以任何方式，形状或forms。
RAID是一种可用性机制，能够在发生硬件故障的情况下减less停机时间，但对于例如病毒，数据删除/修改或简单的灾难性硬件故障，则无济于事。
许多经验丰富的pipe理员采取所谓的3-2-1备份规则：
您应至less有三份数据，包括主要来源。 即一个单一的备份是不够的，同一个物理系统内的副本不计算在内。
您应该至less使用两种不同的备份方法。
您应该至less有一个数据的异地副本。
快照违反了所有三个部分：
你只使用一台物理机器。 任何影响整个机器的事情，比如PSU故障，都可能带走所有的数据。
您只使用单一方法进行备份。 如果有任何问题，只有在危机情况下恢复备份时才会发现。
你没有备份异地。 洪水和火灾只发生在别人身上，直到发生在你身上…
因此：
您需要在局域网的另一台计算机上至less备份一次备份。
您需要至less有一个不是使用快照生成的备份。 也许一个古老的增量tar档案可能是为了？ 或基于rsync的副本？
您需要至less有一个远程备份，尽可能远离您的当前位置， 绝对不在同一栋楼。
还应该指出的是，块级快照与您的计算机上的插件相同，然后在磁盘上进行复制具有相同的一致性保证。 一般来说，你需要在恢复之后运行fsck ，或者希望日志足够了。
文件系统级别的快照应该更好，但仍不能保证文件的一致性。 对于许多应用程序（数据库服务器浮现），复制活动实例的文件可能完全无用，因为它们可能处于不一致的状态。 您将需要使用自己的应用程序级备份机制来确保存在干净的副本 – 对此，也适用3-2-1规则。
最后，请记住，现在我们只是在谈论当前数据的副本。 为了防范在一段时间内未被发现的故障（或者安全漏洞），您还需要在一段时间之前拥有几个过去的数据副本。
它本身并不是一个备份解决scheme 。 它会减less或消除某些故障情况下的停机时间，但不能完全保护您
它当然可以是一个更圆整的可用性+备份解决scheme非常有价值的一部分：
另外：确保你经常testing你的备份。 发现你的备份最糟糕的时间是不工作是当你需要从他们那里检索的东西…