本节摘要:Access 的长寿秘籍是三件机械小事按日历执行:每日自动备份且异地存放、每周压缩修复给文件瘦身体检、每月看一眼体积与性能曲线。本节把华彩的维护日历整张搬出来,附一份压缩失败的急救顺序。
上一节结束时系统已经健康上岗。健康是状态,运维是习惯——这一节全部内容都指向"让好状态靠日历延续,而不是靠热情支撑"。
先纠正两个流行迷思。其一,"我天天复制文件到 U 盘就是备份了"——若 U 盘常年插在同一台机器上,勒索病毒、失窃、火灾会一并带走原件与备份,这叫搬运不叫备份。其二,"导入向导里勾选了保存导入步骤"——那只是操作日志的备忘,不是数据副本。
真正的备份只需满足三条检验:分离(存储介质或位置独立于原件)、定期(不依赖人想起)、可恢复(真的演练过从备份还原)。落地配置不必复杂:
华彩商贸 备份方案现状 频率 每天晚上由主机上的计划任务执行文件级复制 位置 主机本地留七天的滚动窗口 加 异地网盘目录每日同步 命名 后端库_年月日 版本号 带时间戳防覆盖 演练 每季度挑一个假日备份 在空闲机器上完整还原跑一遍业务流程
计划的实现可以是一行脚本加系统计划任务(文件复制没有任何技术含量),关键是把它当成基础设施而不是美德。第五条"演练"最常被跳过也最致命——没人验证过的备份等于薛定谔的保险单。演练全程四十分钟,一年两小时换一整套心理安全感,这是我见过的杠杆率最高的运维投入。
Access 删除记录并不立即释放磁盘空间——被删数据只在逻辑上标记作废,物理页仍占着地方;长期增删之后文件虚胖、索引碎片化、查询变慢都是同一件事的症状。压缩修复(Compact & Repair)就是那台榨汁机:重建所有表的数据页、回收空间、重建索引统计。
两条正确使用姿势:

例行检查不追求高深,四个数字外加一条目视:
月度巡检卡 五分钟版 1 文件体积 环比涨幅超过百分之二十 要么数据真涨了 要么压缩没跟上 2 记录总量 各核心表行数记进台账 增长斜率就是提前升级的路标 3 编译状态 VBE 里点调试编译 零报错保持代码层干净 4 快查基准 固定跑三个代表查询 抄下秒数 与上月对比 突然劣化即预警 5 目视 随便开两窗体一报表 使用者抱怨的边角问题自己先看见
第 3 条专门解释一句:调试编译能把残留在代码里的语法问题一次性揪出,很多人最大的惊吓来自"某个同事不知何时手滑改坏了模块而窗体一直没触发那段"。每月扫雷一次,炸雷概率大幅下降。
回顾本章与上一节,你会发现所谓运维就是把开发期散落的动作重新编码为日历与清单。三个原则收束:
空谈原则不如亮家底。华彩项目运行两年后沉淀的最终版本如下,各家可等比缩放:
每日(自动,计划任务 19:30 触发) 压缩修复生成当日副本 到 NAS 的 日备 文件夹 按 yyyymmdd 命名 保留最近十四份 更早的由任务自动清理 每周(人工按钮 十秒) 销售主管按下 主控台上的 周归档 按钮 当周副本另存至 移动硬盘 硬盘平日锁抽屉 每月(对账日顺手) 月度体检卡五个数字誊进台账折线 抽查一张上周报表与线上数字核对 每季(半下午) 还原演练 找台空闲电脑把某个历史副本完整跑起来
这套表的精髓不在频率而在分工:机械的部分全部交给机器,需要判断的部分才占用人的十分钟。
去年七月周五午后雷暴跳闸,恢复供电后打开库直接弹"无法识别的格式"。按急救四步走:压缩修复无效→新建库全量导入对象成功救回九成六→昨日备份补差→全程四十分钟。复盘出的两个整改至今有效:给 NAS 与两台录入机各配了小功率后备电源,撑二十分钟够保存退场绰绰有余;把"雷雨季提前手动备份一次"写进了日历备注。那次真正的幸运是当天上午刚好做过日备——你永远不知道意外与备份哪个先来,所以只能让备份天天都在。
日历解决"何时",还要回答"放哪"。介质三档各有角色:
| 去处 | 定位 | 注意事项 |
|---|---|---|
| 本机另一块物理盘 | 防误删与软件级损坏的第一现场 | 防不了整机故障,只是缓冲垫 |
| 局域网存储设备 | 主要归集地,按日期滚动保留十四份上下 | 要配后备电源,断电是它的天敌 |
| 离线异地一份 | 抵御勒索、失窃、火灾的最后底牌 | 每周或每月轮换拔下带走 |
三条配套细则决定这套体系的成色。其一,备份文件跟随主库一起加密——明文副本堆在共享目录等于把保险柜钥匙插在门上;其二,旧副本轮换写死在脚本里,指望人工清理的团队没有撑过三个月的;其三,每季度把离线那份实际恢复一次,备份的可信度只认最近一次成功演练。
这个每周五分钟的功课也有自己的安全守则,顺手立齐。第一,无人在线时才可执行:压缩是对文件的独占重写,有人正录着单你按下修复按钮,等于当众抢夺方向盘——日历安排在开机或关机窗口正是为此。第二,它不是撤销键:修复救的是存储结构与损坏页,误删的数据找它没用,出路只有备份恢复,两条线永远别混。第三,关注前后体积差:压缩后体积几乎不变但系统一直缓慢,说明臃肿不是碎片而是真实数据增长,该看归档策略而不是继续压缩——把体检指标和动作意图对上号,例行功课题中的每一个数字才有含义。
下一节我们处理一门更软的手艺:当需求变化来临,怎么优雅地迭代而不砸了正在运行的系统。