在一次错误的模组更新后，你的 Minecraft 世界被破坏了。您的 Discord 机器人数据库在部署失败后消失了。您的 VPS 已在线，但您实际需要的文件却未在线。这正是服务器备份解释的重要性所在 - 因为仅正常运行时间并不能保存您的数据。
备份只是服务器数据的可用副本，您可以稍后恢复。不是承诺。不是您从未测试过的快照。不是您上个月要下载的文件夹。真正的备份可以让您在发生故障后恢复文件、数据库、配置，有时甚至是整个系统。
对于小型社区、机器人开发人员和游戏服务器管理员来说，备份并不是企业独有的功能。它们是针对正常问题的基本保护：人为错误、更新失败、帐户被黑、磁盘问题、不良插件和意外删除。如果您的项目全天候（24/7）运行，备份也应该同样可靠地运行。
服务器备份简单解释：备份实际上包括什么
大多数人认为备份意味着复制所有内容。有时确实如此，但通常这是浪费。良好的备份涵盖了可能会丢失的数据以及快速恢复服务所需的部分。
在游戏服务器上，这通常意味着世界数据、玩家数据、配置文件、插件文件夹和自定义资产。在 Discord 机器人上，它可能意味着源代码、环境配置、上传的资产，尤其是数据库。在 VPS 上，它可能包括网站文件、数据库、系统配置、SSL 文件、计划作业和部署脚本。
关键思想很简单：如果从头开始重建需要时间、金钱或导致停机，那么它可能属于您的备份计划。
这并不意味着每个备份都必须包括整个操作系统。完整的服务器映像很有用，但它们更大、存储速度更慢，并且并不总是每个恢复方案所必需的。有时您需要回滚一张数据库表，而不是回滚整台机器。这就是备份类型的重要性。
大多数用户需要了解的三种备份类型
完整备份复制范围内的所有内容。它是最容易理解和最容易恢复的，但它使用最多的存储空间并且创建时间可能更长。
增量备份仅保存自上次任何类型的备份以来更改的内容。这是高效且快速的，非常适合频繁的备份计划。权衡是恢复复杂性。如果链条中的一个环节丢失或损坏，恢复就会变得混乱。
差异备份保存自上次完整备份以来更改的所有内容。它位于中间。恢复比增量备份更简单，但存储使用量会随着时间的推移而增长，直到下一次完整备份重置周期。
对于大多数小型部署，最好的设置不是永远选择一个。它正在将它们结合起来。每周完整备份加每日增量备份很常见，因为它可以平衡速度、存储和恢复时间。
哪些服务器备份不能保护您免受哪些侵害
备份有助于恢复。它们不会取代安全、监控或维护。
如果您的服务器遭到破坏并且攻击者还删除了您的备份，那么您的计划就会失败。如果勒索软件同时加密生产数据和连接的备份存储，那么您的计划就会失败。如果您有备份但从未测试过恢复，您并不真正知道它们是否有效。
这就是为什么智能设置将生产与备份存储分开并保留多个版本。当前有一份备份总比没有好。多个还原点比一个还原点好。离线或隔离副本更好。
很多停机时间发生在事件发生后，而不是事件发生期间。技术故障是一个问题。缓慢、混乱的恢复过程才是更重要的。
您应该多久备份一次服务器？
这取决于数据变化的程度以及丢失几个小时的数据会有多痛苦。
如果您运行一个每周更改一次的小型个人项目，则每日备份可能就足够了。如果您主持一个活跃的 我的世界服务器，玩家的进度每分钟都可能发生变化。如果您的 Discord 机器人整天写入票据、经济数据、日志或用户设置，那么即使损失六个小时也可能是一个真正的问题。
更好的问题是：您可以承受丢失多少数据？这就是您的恢复点目标，即使您从未这么称呼它。
如果答案是有一天，则至少每天备份一次。如果答案是一小时，则每日备份是不够的。对于活跃环境，许多管理员使用分层方法：频繁的数据库备份、每日应用程序备份和每周完整系统备份。
您还需要考虑保留率。仅保留最新的备份是有风险的。如果损坏在三天前开始，而您现在才注意到，则您的最新备份可能已经包含该问题。保留多个版本可以为您提供恢复干净数据的空间。
为游戏服务器、机器人和 VPS 用户简单解释服务器备份
对于游戏服务器来说，一致性很重要。在世界正在积极保存时复制实时文件可能会导致恢复损坏。某些平台和脚本可以很好地处理此问题，但一般规则很简单：以不捕获半写入数据的方式进行备份。在活动较少的时段安排备份会有所帮助。
对于 不和谐机器人，数据库往往比机器人代码更有价值。代码通常存在于版本控制中或者可以重新部署。用户生成的数据不能。如果您的机器人存储审核历史记录、级别数据、票证或服务器设置，请首先优先考虑数据库备份。
对于 VPS 用户来说，最大的错误是假设提供商会自动处理所有事情。有些主机提供快照或托管备份，有些则不提供，有些仅涵盖基础设施级别的故障。这很有用，但可能无法保护您免受自己的错误的影响。如果您删除应用程序文件或覆盖数据库，基础架构冗余不会神奇地恢复您的项目。
这就是为什么值得检查您实际拥有哪种备份：文件级、数据库级、基于快照或完整映像备份。名称比恢复结果更重要。
良好的备份策略在实践中是什么样子的
一个好的备份策略在设计上是无聊的。它按计划运行，将数据存储在单独的位置，保留多个还原点，并在紧急情况之前进行测试。
对于许多用户来说，实用的版本是这样的：自动备份而不是手动备份，至少一个服务器外副本，足够长的保留窗口以捕获延迟的问题，并定期恢复测试。如果您的服务是创收的或对社区至关重要的，请添加监控和警报，这样失败的备份就不会被忽视。
压缩和加密也很重要，特别是当备份包含个人数据、令牌或带有秘密的配置时。较小的备份更容易存储和移动。如果存储被公开或转移，加密备份会更安全。
尽管如此，还是需要权衡取舍。更频繁的备份意味着更多的存储使用和更多的 I/O。保留时间越长意味着成本越高。完整映像备份很方便，但对于小事件，文件级恢复通常更快。正确的设置是您可以始终如一地维护的设置，而不是听起来令人印象深刻的设置。
恢复测试是大多数人跳过的部分
仅当您恢复备份时，备份才能得到验证。
这就是简单设置胜过复杂设置的地方。如果您的恢复过程需要十页笔记，依赖于一个缺失的脚本，或者需要您仅在压力下记住的手动修复，那么恢复速度将比预期慢。
测试恢复应该回答一些基本问题。可以恢复最新的备份吗？可以恢复旧版本吗？多久时间？恢复后应用程序或服务器是否真正正确启动？权限、配置和数据库连接是否完好无损？
您不需要企业工具来做好这项工作。你需要可重复性。如果备份是自动化的并进行恢复，即使是小团队或单独的开发人员也可以构建可靠的流程。
对于注重性能的托管环境，这一点更为重要。快速部署非常棒。快速恢复可以防止用户长时间注意到问题。这就是 ACLClouds 等提供商如此重视实用基础设施功能而不仅仅是原始规格的原因之一。
导致真正停机的常见备份错误
第一个错误是备份到同一服务器。如果磁盘发生故障，生产数据和备份数据都会一起消失。
第二种是依靠手动备份。手动作业被跳过。他们被延误了。它们在更新之前就被遗忘了，而这正是您最需要它们的时候。
第三是忽视数据库。人们经常复制文件并假设这涵盖了所有内容，然后意识到他们的应用程序状态一直存在于 SQL 中。
第四是从不检查保留或存储限制。当空间耗尽或旧版本被过度删除时，备份可能会悄然失败。
第五是混淆快照与完全保护。快照很有用，但它们本身并不总是完整备份策略。它们可以是计划的一部分，而不是整个计划。
最安全的心态很简单：假设失败最终会发生，然后使恢复快速且可预测。
备份并不是光鲜亮丽的基础设施。当服务器启动顺利时，没有人会炫耀它们。但是，当插件破坏世界、部署擦除配置或数据库表在凌晨 2:13 消失时，备份就是短暂修复和完全重建之间的区别。让它们保持自动化、独立，并确保它们在关键时刻恢复。