“仅推送”备份？

您提到的问题实际上是一旦您制作完成后，保护备份的问题。

1. 解决这个问题的标准方法是使用某种forms的定期取走现场的可移动媒体。

   • 通常情况下，使用LTO磁带介质，您可以定期将所有备份磁带从现场转出，这样您现场唯一的备份磁带就是主动在磁带库中logging备份数据的备份磁带。
   • 我也偶尔看到了USB闪存驱动器和可移动驱动器。 这种方法可以防止恶意操作和物理灾难。
2. 这种方法稍有不同就是使用一次性写入介质，以便备份一旦完成就不能删除。
   • CD / DVD或WORM LTO媒体。 通常这种方法在范围上稍微有限，因为它可以很快地花费昂贵和费力。
     • 举个例子，在我工作的一个高度安全的环境中，我们有脚本将服务器日志连续复制到备份服务器上，然后每晚将它们刻录到DVD上，作为保存其中的信息的机制。 如果出现问题或者被黑客攻击，清除服务器上的日志将不会有太大的好处。

现在，随着磁盘到磁盘备份系统的激增，这两种方法都不可行，也不可行，但实现这一目标的方法有很多。 他们基本上分为两类。

1. 正如评论中所提到的，一类是使用公钥encryption来分离密码级别的读写权限。
   • 一个这样的服务是tarsnap 。 由于使用不同的密钥来读取和写入数据，因此可以将每个密钥存储在不同的位置，以便危害备份的攻击者无法读取它们。
   • Tarsnap远不是这种服务的唯一提供者，你甚至可以用广泛可用的公钥encryption工具推出自己的解决scheme。 但是，他们大概还是可以“备份”备份（摧毁或破坏备份）。
   • 这对于合规情况或数据隐私非常重要的情况非常有用，担心的是攻击者能够获取信息（读取备份），但不能防止攻击者破坏或损坏备份。
2. 另一类是实际分割权限，以便您的备份服务器不具有修改或覆盖数据所需的权限。
   • 实现这一点的显而易见的方法是只在文件系统级别提供备份服务器/服务的读写权限，而不能修改或删除权限。
   • 您可以通过将备份服务器与备份服务器分开来实现同样的目的，这样做会影响实际的备份，而不仅仅是损害用于创build备份的服务器。
     • 这是我现在使用的方法，用于$ [corporate_overlord]。 备份被复制到异地（磁盘到磁盘系统），但是主备份节点和异地节点是使用不同的帐户访问的，因此危害一个节点不会让另一个节点受到危害。 每个节点都可以读取其他的数据，但每个节点只能修改/删除自己的数据。
3. 这两种方法甚至可以结合起来，为两个世界真正的偏执/最好的。

最后，即使您使用的是磁盘到磁盘的情况，也没有理由不能实现有效地使备份脱机的解决scheme。 您可以设置一个系统，在备份完成后自动将容纳备份的服务器/磁盘置于脱机状态，并且只有在计划发生下一次备份时才会使其恢复联机状态，或者将存储备份的卷重新挂载为已读-只要。 似乎比设置上面的权限更多的工作，但是可能的。

人们显然关心这个问题，这就是为什么像tarsnap这样的服务存在。 这使用单独的读写键。

要执行备份，您只需要有可用的写入密钥。

您可以将读取密钥安全地保存在要备份的系统中，并且只有在需要恢复文件时才能使用。

在将备份发送到备份服务之前，使用密钥对备份进行encryption。

我的理解是，一个标准的svnserve服务器（一个为Subversion版本控制库处理“svn：//”或“svn + ssh：//”协议的服务器）允许人们将新版本提交到一个版本库，但是实际上不可能“丢失”以前提交给版本库的版本。

（您的在线备份空间可能已经为您设置了这样的服务器）。

我们处理这个问题的方式是使用亚马逊S3，它允许写入新的对象，但不能通过服务器上的凭证删除，然后在存储桶上使用versoning，即使入侵者存储不良备份，旧的（好的）备份仍然那里。

到目前为止工作得很好。