备份服务器这个东西，很多人是等到硬盘坏了、数据丢了才想起来它的存在。平时觉得用不上，一出事就发现没有它寸步难行。说白了，备份服务器就是专门用来存备份数据的机器，它不跑业务，不对外提供服务，只干一件事：把生产环境里的数据定期搬过来存好，等哪天生产环境出问题了，能从它这里把数据拿回去。
为什么不能把备份直接放在生产服务器上。因为生产服务器本身就会坏。硬盘会坏，系统会崩，中勒索病毒之后整个机器上的文件都可能被加密。备份跟原始数据放在同一台机器上，等于把鸡蛋放在同一个篮子里。所以备份必须落在独立的物理设备或者独立的存储空间里，这是所有备份策略的起点。
策略这件事，第一个要搞清楚的是全量备份、增量备份和差异备份的区别。全量备份就是把所有数据完整复制一份，恢复的时候最简单，直接拿最新的全量包还原就行。代价是每次备份耗时长、占空间大。增量备份只备份上一次备份之后变化的数据，速度快、占空间小，但恢复的时候需要先还原最近一次全量，再把之后所有的增量按顺序叠上去，任何一个环节出问题都可能恢复失败。差异备份介于两者之间，每次备份的是自上次全量以来所有变化的数据，恢复时只需要全量包加最近一次差异包，比增量少了很多步骤。
实际用的时候，比较稳妥的组合是每周做一次全量，每天做一次差异或者增量。全量放在周末业务低谷期跑，平时每天跑增量，这样既控制了备份窗口，又保证了恢复效率。如果数据量特别大，全量一周一次都嫌频繁，可以拉长到两周一次，中间用增量补齐。
3-2-1原则是备份圈里被说得最多的一条。三个副本，两种不同介质，一份放在异地。三个副本意味着除了原始数据，至少还要有两份备份。两种介质比如一份放本地磁盘阵列，一份放磁带或者云端。异地这一条最关键，本地机房如果遭遇火灾、水淹或者被盗，本地备份跟着一起完蛋，异地那份就成了最后的救命稻草。云存储现在成本已经很低了，把备份加密后传到对象存储里，每个月花的钱可能比一顿饭还少。
备份频率要看数据的变化速度。一个每天新增几百条记录的数据库，一天备一次可能不够，得考虑每几个小时备一次，或者用数据库自带的日志归档功能做持续备份。一个静态的企业官网，内容几周都不变，一周备一次绰绰有余。别为了追求“实时”把所有东西都做成高频备份，那样存储成本和备份窗口的压力会大到没必要。
保留策略要提前定好。保留多少天、多少周、多少个月，取决于你的合规要求和实际需要。常见的是保留最近七天的每日备份、最近四周的每周备份、最近十二个月的每月备份。这样即使发现数据被污染是几周前的事，你依然能从更早的备份里找到干净版本。保留策略定好之后要写进自动化脚本里，别指望人工去删旧备份，人一定会忘。
备份做完不等于万事大吉。没验证过的备份等于没有备份。定期做恢复演练，从备份服务器上把数据拉回来，在一个隔离环境里还原，看看能不能正常启动、数据是否完整。这个动作至少每季度做一次，关键系统最好每月做。很多团队出问题的时候才发现备份文件损坏、密码丢失、或者备份脚本半年前就静默失败了，就是因为从来没验证过。
自动化是备份能不能长期坚持下去的关键。手工点按钮的备份，坚持不了三个月。用 cron 或者 systemd timer 把备份脚本跑起来，脚本里包含备份、压缩、加密、传输、清理旧文件、发通知这几步。通知这块别省，备份成功发一条简短的消息到邮件或者钉钉，失败了更要发。如果连续几天没收到成功通知，主动去查一下，别等出事才发现备份断了。
备份服务器本身的硬件不用太豪华。它不需要跟生产服务器一样的CPU和内存，但对磁盘容量和可靠性有要求。用RAID做磁盘冗余，用ECC内存减少静默错误，电源和网卡做冗余，这些跟普通服务器一样重要。如果备份服务器也三天两头出故障，那备份本身就不可靠了。
最后说一个容易被忽略的点：备份的恢复时间目标。你的业务能容忍多长时间的数据丢失，以及能容忍多长的恢复时间。这两个数字决定了备份策略的激进程度。金融交易系统可能要求丢失不超过几秒的数据，恢复时间不超过几分钟，那就要上实时复制加自动故障切换。一个内部文档系统可能丢一天数据也能接受，恢复花几个小时也没关系，那每天一次备份加手动恢复就够了。先把这个想清楚，再去选工具和定策略，比反过来要顺得多。