去年10月8号，国庆后上班第一天，我打开某代账系统准备给客户报税，结果发现一家餐饮客户的Q3账套数据全没了。当时脑子嗡的一声——这家客户9月底刚做完账，凭证录了200多张，银行对账单也核完了。后来查出来是系统升级时出了bug，虽然最终从服务商的备份里找回来了，但中间停了三天，客户差点要解约，我最后免了人家2万块服务费才了事。
这事之后，我开始认真研究云代账系统的自动备份和灾备恢复。我们公司现在有47家代账客户，分布在3个不同系统里，账套安全这事不能再靠运气了。
以前我的备份方式很简单：每个月结完账，手动导出一次账套数据到本地硬盘。听起来没问题对吧？但实际执行下来，2023年全年我只导出了7次，按12个月算完成率不到60%。原因很现实——月底本来就忙，报税截止日前那几天恨不得长八只手，谁还记得导出数据？而且手动导出的格式也不统一，有的是Excel，有的是系统自带的加密包，真要用的时候还得找对应软件打开。
我算了一笔账：47家客户，如果按每家每月手动备份一次算，每次操作加整理大概8分钟，一年下来就是75个小时。这还没算漏备份的风险成本。所以2024年1月我给自己下了死命令：必须上自动备份。
今年2月到3月，我试用了四家云代账产品，最后定了一家年费6800元的。选型时我主要看三个点：
第一，备份频率能不能细到小时级。有的系统只支持每天凌晨2点备份一次，万一下午3点系统崩了，白天录的凭证就全丢了。我现在用的这家支持最短每4小时一次增量备份，满足我的要求。
第二，备份文件能不能自己下载。有些服务商说得好听“数据永久保留”，但实际只存在他们自己的服务器上，客户想迁走的时候各种推诿。我要求必须支持一键导出完整账套包，格式是标准的SQL和Excel双份。
第三，有没有异地灾备。3月份跟服务商的技术聊，他给我看了他们的架构：主服务器在杭州，备份数据实时同步到成都机房，两地直线距离1800公里。虽然我不懂底层技术，但至少知道鸡蛋没放在一个篮子里。
4月10号正式上线自动备份，我花了两个下午调参数。目前配置是这样的：
1. 全量备份每周日晚上23点跑一次，保留最近8周的数据。算下来47家客户的全量包大概占32GB空间，服务商送的50GB够用。
2. 增量备份每4小时一次，从早上8点到晚上24点，每天5次。这个主要防白天操作失误，比如会计误删凭证。
3. 每次备份完成后系统会自动发邮件到我手机，标题带“成功”或“失败”字样。前两周我每天翻邮件，发现4月18号下午2点那次增量备份失败了，原因是客户账套里有个附件文件名带特殊字符。联系技术处理后，加了条规则：文件名含特殊字符自动跳过并记录日志。
4. 本地再留一手。我买了个2TB的移动硬盘，每周五下午下班前把云端全量备份包下载到本地，双重保险。虽然麻烦点，但心里踏实。
配置好了不代表万事大吉，得实际演练。5月20号我挑了家业务最简单的客户——一家小超市，月凭证量不到30张——做恢复测试。步骤是这样的：先在测试环境建个空账套，然后把5月10号的全量备份包导入，再按顺序叠加5月10号之后的增量包。整个过程花了40分钟，数据完整恢复到了5月19号的状态。
但中间踩了个坑：第一次导入时没注意编码格式，导致凭证摘要里的中文全变成了乱码。后来发现备份包默认是GBK编码，而测试系统环境是UTF-8，得在导入时手动指定编码。这个细节我在操作手册里用红字标了出来。
第二次演练是6月15号，模拟主服务器宕机。我给服务商技术打电话，他说系统会自动切换到成都机房的备用环境，切换时间大概15分钟。实际测试下来用了22分钟，主要卡在DNS解析刷新上。虽然比承诺的慢，但能接受。恢复后我抽查了10家客户的6月账套，凭证、余额、报表都正常。
折腾这半年，我最大的感受是：别把备份当技术问题，它是个管理问题。现在我的日历上每周五下午4点有个固定提醒——“检查备份邮件+下载全量包”，雷打不动。另外，跟服务商签合同时一定要写清楚数据归属和导出条款，别只听销售口头承诺。我现在的合同里加了一条：如果服务商终止服务，需提前30天提供完整账套导出文件，格式必须兼容主流财务软件。
最后说个数字：从4月上线自动备份到现在9月底，系统累计跑了137次备份任务，失败3次，成功率97.8%。虽然没做到100%，但比去年手动备份的60%强太多了。至少现在晚上睡觉踏实了，不用担心一觉醒来客户数据没了。