指纹考勤服务器全灭之后，门口那台读卡器成了唯一的"备份"
公司一套用了多年的 BioStar（Suprema）指纹门禁，服务器端软件坏到只能从零重装，而数据库层面没有一份可用的备份。按常理这意味着全员重新登记指纹——直到想起一件事：
大门口那台指纹机是独立设备，用户数据和指纹模板都存在设备本地。 服务器死了，门每天照常开——设备里的数据还活着。它就是备份。
第一步：把服务器软件立起来
重装过程本身有两个小坑值得记：
- BioStar 这一代软件依赖 .NET Framework 3.5，要先从 Server Manager 加功能，否则安装器过不去；
- 装完后服务绑到了一个 169.254.x.x 的 APIPA 地址上（机器多网卡，服务挑了个没 DHCP 的口），客户端得先按这个 IP 连本机才能进得去。重启并禁用多余网卡之后，服务才乖乖回到正常的内网静态地址。多网卡服务器上装 C/S 架构的老软件，服务绑错网卡是保留节目。
第二步：从门禁机把 237 个用户拉回来
服务器空库跑起来后，添加设备——大门口的指纹机以设备自己的内网 IP 被自动发现。然后是关键操作：从设备读取用户（Get user from device）。
先试着拉了 User ID 1，确认数据结构完整、指纹模板还在。然后放开手脚：全量拉取——237 个用户连同指纹数据全部回到了服务器。到这一步，“重新登记全员指纹”这个最坏情况已经解除。
第三步：设备里只有工号，没有姓名
新问题浮出来：设备端存的用户基本只有 User ID（工号）和指纹模板，姓名字段是空的。237 个”编号幽灵”能开门，但没人知道谁是谁。
HR 那边也没有一份”工号 ↔ 姓名”的完整对照表——历史上登记时没人想过服务器会死。唯一能翻出来的线索，是一份 2020 年 4 月导出的整月门禁日志 CSV：日志里每条刷卡记录都同时带工号和姓名。
于是做了一件不太优雅但有效的事：把两年前的门禁日志清洗成”工号-姓名”对照表，用 BioStar 的导入功能反向灌回去。
第四步：导入功能的坑比想象的多
这个导入过程几乎每一步都有脾气：
- 原始 CSV 有空格、有重复工号，直接导预览只显示 5 行，莫名其妙——清洗去重后再导，用字段自动映射（auto mapping），突然就全认了；
- 先拿一小批已离职用户做试点（改坏了也不心疼），确认姓名确实按工号对上了才放大范围；
- 但抽查发现一个真坑：导入在写入姓名的同时，把用户的”有效期/到期日”字段覆盖成了 NULL——导入的列里没有这个字段，它不是”跳过不动”，而是”没提供就清空”。好在指纹模板不受影响，依然完好；
- 3 行数据的导入都要跑很久，全量更是慢——这类老软件的导入不是批量 SQL，是一行行走业务逻辑。
最后的收尾由 HR 同事按 Excel 清单手工补录剩余对不上的部分——自动化到九成，最后一成人工兜底，比硬磕到 100% 自动化划算。
设备本地存储这个”特性”，在服务器全灭的那天变成了救命稻草
教训
- C/S 架构门禁系统的设备端本身就是一份分布式备份——用户数据和生物模板存在设备本地，服务器全灭时第一反应应该是”先别动设备”，它们是最后的数据源；
- “工号 ↔ 姓名”对照表要独立于门禁系统存一份——设备端往往只存 ID；HR 侧如果也没有对照表，恢复时就只能像我们一样去考古历史日志；
- 老软件的导入功能，对”未提供的字段”可能是覆盖而不是跳过——导入前先拿一小批不重要的记录试点，抽查所有字段而不只是你导入的那几列；
- 门禁日志除了审计还有意外的价值——定期导出的日志里带着”ID-姓名”映射，等于免费维护了一份对照表，值得纳入例行导出归档。