我想为我的网站采取一个新的stream媒体服务器，通常包含video和audio文件。 但是，如果存储容量日益增加，我们如何保持stream媒体服务器的备份。
通常在数据库服务器（如Sql Server）上，备份可以很容易地进行和恢复，因为它们不占用中等范围应用程序的太多空间。
另一方面，我们如何能够采取stream媒体服务器的备份？ 如果服务器出现故障，应该有一个替代的服务器/解决scheme来减less服务器的停机时间。
YouTube的后端架构如何构build来处理这个问题？
我们所做的就是拥有多个FC SAN，每个FC SAN在不同的数据中心彼此同步，每个都连接到作为“原始”服务器的服务器组，将FC存储转换为NFS或CIFS / SMB。 然后将这些服务器分成一个负载均衡的VIP块，然后将相同的VIP服务器网页服务器进行反馈，然后通过FW / LB将其呈现给外部世界。
实际的内容会定期从一个或多个FC SAN盒中抓取到专用的SAN盒上，然后在另一个站点备份到磁盘上，然后将磁带存储在Iron Mountain上。 我在stream媒体业务:)
内容没有捷径，很大，你只需要处理它。 如果我是你，我会设置一个专用的备份机器，使用一大块可用的磁盘，并使用rsync来确保您拥有主内容存储库中每个文件的副本，尽pipe这将不可避免地最终成为您的实时数据。 然后采取该机器的磁盘或磁带备份，并定期删除老化的数据，以保持可pipe理性。
哦，youtube没有正确备份任何常规用户的内容，他们的devise确保他们有多个分布在世界各地的副本，但更多的性能比恢复能力。 他们会备份自己的内容或任何其他内容，而这些内容与他们没有合同义务存储的所有内容相比，只是海洋的一小部分。
现在，您正在发现为什么有一个stream式video/audio服务，并保持可靠，是不容易build立。 要获得完整的备份解决scheme，您需要：
如果您正在减less停机时间，则至less需要添加两倍于原始解决scheme的服务器数量，以及pipe理此networking的方法。 成本至less是原来解决scheme的两倍。
正如Chopper3所指出的那样，您可以在基础架构中构build“备份”的需求，因为添加内容时会自动进行镜像。
假设你的问题之一是“如何处理这个YouTube的后端架构”。 即使您从未在post中使用过问号，但答案是Google非常巨大，并且遍布全球的服务器数量众多，您可以确定数据存储在多台计算机上，因此如果其中一个发生故障，数据可以保持stream式传输。
常用的备份计划包括进行异地备份，但是如果您需要较长的正常运行时间，则可能需要异地备份和本地备份，以便从本地进行快速恢复，但是如果DC中有任何灾难必须使用非现场的。
有人提到了磁带备份，尽pipe我build议不要这样做，因为您似乎实际上不需要存档数据，而您可能只是希望能够将数据同步到另一台服务器进行备份。 有一些有用的工具，如rsync，可以保持数据同步，只会上传修改过的文件，从而不用做完整的备份。
有些方法可以使它过度复杂化，并且烧钱的方式设置了很多的冗余，但是有些东西告诉我买不起它，而且你不需要pipe理太多机器的麻烦。