每个人都同意备份很重要。达成协议很容易。困难的部分是不会给你奖杯的部分:例程。备份不是您一次性做出的决定,而是您每天坚持的做法,就在没有出问题且似乎永远不会出问题的情况下。
操作应用程序的人都知道,“我们配置了备份”和“我们能够在需要时在二十分钟内恢复”之间存在差距。这一鸿沟与操作规程、自动化、验证和测试交叉。这是一项默默无闻、平淡无奇的工作,只有在它缺失时才会被注意到。
本文假设您已经了解备份的重要性。这里的重点是实用的:如何使备份成为日常生活中的可靠保障,而不是在最糟糕的时刻发现毫无根据的信念。
良好实践#1:如果它不是自动的,那么它就不存在
依赖于某人记得运行它的备份是会失败的备份。不是因为无能,而是因为人性。人们会忘记、旅行、生病、改变优先事项。第一个也是最重要的做法是消除人工执行备份的工作。
备份需要在设定的时间单独运行,无需任何人按下按钮。实际上,每个平台和每个数据库都为此提供了机制,无论是本机调度还是编排工具。自动化成本低;依赖记忆的代价最终是全部的。
自动化还有一个额外的好处:它是一致的。它每天都以相同的方式运行,这使得结果可预测且可审计。手动备份从定义上来说就是不规则的,而不规则的地方就是隐藏漏洞的地方。
最佳实践 #2:监控备份,而不仅仅是系统
这是我经常看到的错误。该组织自动执行备份并认为问题已解决。几个月后,他发现该过程已经默默地失败了数周,磁盘已满,凭证过期,更改破坏了脚本。没有人知道,因为没有人在寻找。
备份需要主动监控。当备份失败时,您必须收到通知,并且同样重要的是,当备份完全停止发生时,您必须收到通知。消失的无声备份与失败的备份一样危险,因为安全感仍然完好无损,而保护却消失了。
经验法则:将备份失败视为一次事件,并向真人发出警报。一封没有人阅读的电子邮件不算数。如果备份失败而您不知道,那么您就没有备份,您就会产生一种错觉。
最佳实践 #3:定期测试恢复
这是区分专业人士和业余爱好者的做法,也是几乎每个人都会跳过的做法。备份是工作的一半。另一半,真正重要的一半,是恢复。
只有成功恢复后,备份才是真实的。在此之前,这是一个假设。假设在细节上失败了:文件已损坏、丢失了一部分、版本不兼容、恢复过程中有一个没有人记录的步骤。您不想在危机中发现这些事情。
成熟的做法是定期测试修复体,作为例行公事。在隔离环境中恢复,检查应用程序是否再次运行,测量需要多长时间。这个测试回答了唯一重要的问题:“我可以回来吗?”,然后生活才会向你发出请求。认真的组织将其作为定期演习,有时甚至是全面的灾难演习。
良好实践#4:在不同的地方拥有多个副本
被称为 3-2-1 的经典规则继续适用于日常生活:三份数据副本,位于两种不同类型的媒体或目的地上,其中之一位于主位置之外。您无需记住号码;你需要明白其中的原理。
原则是不要把所有鸡蛋放在一个篮子里。备份到同一服务器并不能防止服务器丢失。使用同一帐户备份到同一云提供商并不能防止帐户被盗而删除所有内容。地理分离和控制分离可以防止最坏情况的发生。
越来越重要的一层是不可变的备份,即在一段时间内无法更改或删除的副本,即使具有管理访问权限的任何人也无法更改或删除。针对勒索软件(通常在加密其余部分之前先攻击备份),不变性已成为日常生活中最有价值的防御措施之一。
批判性反思:做好事情的隐形成本
出色的备份会在存储、工程时间和纪律方面产生成本。由于这种成本的回报只有在可能永远不会发生的灾难中才会出现,因此放松的压力始终存在。跳过本月的测试。减少保存频率。推迟战略审查。每一项放松措施单独来看似乎都是无害的,但加在一起就会损害保修。
与双向运作的[LGPD1]也存在紧张关系。一方面,需要保证数据的可用性,这就需要强大的备份。另一方面,备份是存储个人数据的另一个地方,需要在保留策略中对其进行保护、访问控制和处理。不加判断地永久保留备份会成为隐私责任。良好的实践包括知道何时丢弃。
还有更深层次的文化挑战:备份是无形的工作。那些维护得好的人永远不会受到赞扬,因为结果是没有问题。领导层需要重视这种默默的工作,否则当压力来临时,它永远是第一个被削减的人,直到有一天,它的缺席要承担全部费用。
还剩下什么
日常备份是持续的例行工作,而不是初始配置。自动执行、监控故障、真正测试恢复并维护单独的副本。坚持这样做,月复一月,即使看起来没有必要,尤其是当它看起来没有必要的时候。
每个团队都应该能够冷静回答的问题是:“如果我们现在失去了一切,我们需要多长时间才能回来,一路上我们会失去多少?”如果答案是令人不舒服的沉默,那么在现实检验它之前,例行公事就需要引起注意。
如果您维护应用程序并且不确定今天是否可以恢复它们,那么值得冷静地检查您的日常工作。博客上还有其他关于连续性、DevOps 和可靠操作的文本,对这些实践进行了补充。
另请阅读
- [应用程序备份:它是什么、为什么重要以及为什么几乎每个人都低估2
- [日常生活中的灾难恢复:避免危机的做法3
- [应用后端:小团队不能犯错误的良好实践44
- [应用程序维护计划:实施快速指南5
- [灾难恢复:在需要之前没有人愿意支付的保险66
- [应用程序中的缓存:良好实践快速指南(及其隐藏的错误)7
