对于我的新服务器,我想设置一个合适的备份解决方案。我找到了一个很棒的设置,它可以通过 Dropbox 每天进行两次增量备份。我计划备份我的各种数据库、webroot 目录、/etc 目录/存储库和 /var/log。
我还需要知道什么才能进行正确的备份,这里的标准设置是什么,以确保在系统发生故障时可以快速从备份中恢复?
我正在考虑使用 Puppet,因为它描述了系统应该是什么样子。我的恢复过程如下:
- 安装 Puppet
- 运行我的 Puppet 配置
- 从 Dropbox 恢复我的备份(我应该创建一个脚本来执行此操作吗?可能)
这还应该允许我创建生产服务器的克隆以供在开发环境中使用,对吗?我是否遗漏了什么重要信息?
答案1
我们建立备份系统只有一个目的:实现恢复。没人关心备份,他们关心的是恢复。
有三种原因可能需要恢复文件:意外删除文件、硬件故障或存档/法律原因。“完整”备份系统可让您在所有这些情况下恢复文件。
对于意外删除文件,Dropbox 和 RAID 之类的东西会失效,因为它们只会反映对文件系统所做的所有更改,在这些情况下,已删除的文件就消失了。您的备份系统应该能够相当快地将文件恢复到最近的时间点;最好在几秒到几分钟内完成恢复。
对于硬件故障,您应该尽可能使用 RAID 和其他高可用性方法等解决方案,以确保您的服务保持正常运行,因为由于需要读取和写入(相对)较慢的媒体,系统的完全恢复可能需要数小时甚至数天。
最后,存档或特定时间点的系统完整备份(或等效备份)可用于合法和灾难恢复场景中的恢复。这些通常存储在异地,以防流星将您的数据中心变成冒烟的陨石坑……
您的完整备份系统应能够支持这三种类型中的任意一种的恢复,并提供不同的服务级别 (SLA)。例如,您可以决定,已删除文件可以以一个工作日的粒度恢复过去六个月的数据,以一个月的粒度恢复过去三年的数据;磁盘故障应能够在四小时内恢复,数据丢失时间不超过两个工作日。备份系统必须能够在备份计划中实施 SLA。
您的备份系统必须完全自动化这一点再怎么强调也不为过。如果备份不是完全自动化的,那么备份根本就不会发生。您的备份系统必须能够实现完全自动化的备份,开箱即用,几乎不需要或根本不需要特殊配置或脚本。
您必须定期测试恢复。如果从备份恢复失败,任何备份系统都是毫无用处的。我想我们大多数人都有类似的恐怖故事。您的备份系统必须能够在您实施的 SLA 内恢复单个文件或整个系统。
您必须持续购买备份媒体。无论您是只进行现场磁带备份还是全力进行异地云备份,请确保您的预算足以支付您所需的 GB(或 TB!)空间。
这是第 26 章的一部分的非常简短的摘要系统与网络管理实践,第二版,任何系统管理员或者渴望成为系统管理员的人都应该拥有、阅读和记住它。
我略过了很多不一定适用于您的特定情况或在您描述的小型环境中没有意义的内容。尽管如此,它应该合理地描述了您的“完整”备份系统应具有的功能以及它们为何必不可少。
答案2
- DropBox 是一种危险的备份方式。没有 SLA/QoS,而且以自动方式将如此多的数据转储到他们的服务器可能违反了他们的正常 TOS。他们明确表示不承担访问您的数据的任何责任 - 他们可能会自行决定切断访问权限、销毁数据或破产,且不会发出任何警告。
- 任何备份程序只有在您真正恢复后才“有效”,这是唯一可以确定的方法。许多备份软件都提供了“验证”功能,这对大多数人来说毫无用处,因为它只验证了某物已写入备份介质,不是即某物实际上对于恢复操作系统很有用。
- 坚持不懈地完成文档可确保您在灾难发生时能够遵循恢复程序 - 测试文档应该是测试系统恢复的一部分。此外,如果您被公共汽车撞到,其他人将能够完成这些程序(墨菲定律等等)。
- 恢复只有在有意义的时间段内完成才有用。例如,如果花了一年时间才恢复数据,那就毫无用处了。您应该确定您的情况需要哪些时间范围才能实现三个级别的功能:最低限度功能、日常操作、完整。测试您提出的解决方案,看看是否符合时间要求。
答案3
我首选的、经过验证的备份系统是:
- 所有数据库的每小时快照(以及每天存档一个快照,持续两周,每周存档一个快照,持续一年。)
- 一次性服务器。也就是说,所有服务器都存储在 git 中并自动部署(与您所说的 puppet 非常相似,但我们首选的工具是 chef。)本质上,只需使用 git 中的代码就可以从头开始建立新服务器,这意味着任何开发主机的构建方式都与您的生产服务器类似。
在这些情况下,puppetmaster 或 chef 服务器可能是一个潜在的故障点;同样,尽可能自动重建它们,并准备好脚本,以便在旧机器被撞倒的情况下,让现有节点尽快引导到新的服务器管理主机。我发现从备份重建这种主机有时比从头开始建立一个新的主机花费的时间要长得多(而且从备份中恢复可能会无意中重新引入导致它首先出现故障的相同缺陷或问题。)
另一方面,如果您拥有多个服务器、主机等,那么使用中央日志服务器是值得的。如果它们存放(并备份)在一个来源,则可以省去日志在其他主机上堆积并占用空间的麻烦。日志数据是黄金,但如果我有 20 个 api 服务器都在提供流量,并且我遭受了 DDoS 之类的攻击,那么没有日志聚合就意味着我大海捞针。如果您要存储基础设施日志(您应该这样做!),那么请将它们存储一次,放在一个强大的备份平台上。
祝你好運〜!
答案4
RAID 和 Dropbox“备份”等服务全部您的更改。包括您想要通过使用备份来恢复的错误。
这就是为什么我们这些系统管理员都非常焦虑,为什么像 RAID 或 Toytown 云文件存储服务这样的依赖于镜像文件更改的东西不是备份。这并不是说这些服务没有用。它们有用,但它们不是备份,因为它们实际上并没有为您提供数据完整性。
备份应该是备份时情况的快照,而不是不断覆盖数据发生的所有好事和坏事的实时日志。如果你去看看,有些云提供商会为你提供实际备份,它们的工作方式与 dropbox/skydrive 类型的服务不同。
说到底,您愿意承担什么样的风险以及您为减轻这些风险所花的预算,这都是您的选择。如果您认为像 Dropbox 这样的东西已经足够好了,那么这取决于您。但您需要清楚它能为您做什么和不能为您做什么 - 请不要自欺欺人地认为它是一个真正的备份。