接到一个工单字面就一行“192.168.50.2 老MES备份 操作流程”。字越少活儿越重。干过工厂运维的都懂MES制造执行系统是一天都不能停的而标题里那个“老”字意味着这台服务器可能已经默默跑了七八年系统是老的Windows数据库是老的SQL Server当年实施的人可能已经离职安装盘早不知道丢哪儿了。这种机器一旦磁盘亮红灯或者系统崩了能不能恢复、多久能恢复全看备份做得怎么样。我这篇就把这套“老MES备份”的完整操作流程拆开讲清楚。从最开始的现场勘察到数据库备份怎么做、应用文件和配置怎么拷再到备份完怎么验证、恢复演练怎么搞最后是这些年攒下来的一堆翻车案例和排查方法。不管你手里那台MES是哪个行业的只要还是这种单机部署的老架构这套流程基本都能照着改改用。1. 老MES备份到底在备份什么很多人一提备份就想到“把文件夹复制一下”但这正是老MES备份事故的第一大来源。先搞清楚一台MES服务器上都有哪些“家当”你才知道该备份什么。1.1 一台老MES服务器上面压着哪些家当MES系统的典型部署形态尤其是在中小型工厂里基本就是一台服务器扛下了所有数据库、应用服务、文件存储全在一台机器上。你手里这个192.168.50.2大概率就是这样一台机器顶三台用。先说数据库。这是整个MES的心脏车间过站记录、工单报工、产量统计、质量检验、设备参数全在里面。中小厂最常见的是SQL Server老一点的有SQL Server 2000/2005稍微新一点是2008/2008 R2。这些库通常不大但从生产开始累积到现在可能已经几十GB甚至上百GB。数据库一旦丢了生产追溯就断了审厂的时候拿不出数据那问题就不是停机几天能解决的。再说应用和配置。MES应用一般装在某个目录下比如D盘或C盘的某个文件夹。应用本身可能不值钱值钱的是配置文件——数据库连接串、服务器IP、端口、路径、功能开关全写在app.config、web.config或者注册表里。这些配置要是丢了就算你把数据库恢复得再好应用也连不上。另有一些老MES系统客户端需要在每台电脑上配置服务器地址这个配置也要记录下来。最后是附件文件。MES系统缓存了不少文档类的东西最常见的就是条码标签图片、工单PDF、检验报告、上料记录图片、现场返工照片有时候还有和ERP对接的接口文件。这些文件一般在一个共享目录里平时没人关注但真到追溯的时候少一张图片可能就说不清楚当批产品的情况。还有一样东西很容易被忽略操作系统本身。老MES的部署往往没有自动化安装脚本当初实施人员是手工配的环境包括Windows的组件、服务、ODBC数据源、Com组件注册、杀毒软件白名单、计划任务。这些“环境状态”虽然不是一个文件但恢复系统的时候全靠它们。1.2 老系统备份为什么总翻车老MES备份最坑的地方在于它不是一套新系统没法按新架构的“三副本、异地容灾”来设计你只能在现有条件下做尽量靠谱的方案。老系统翻车原因我见过不少排在第一的是“假备份”。有人之前用U盘把整个目录拷了一遍或者在D盘复制了一份整个文件夹就当成备份了。结果真正需要恢复的时候才发现数据库文件正被SQL Server占用复制出来的mdf根本不是一致性的恢复出来库是坏的或者压根没拷到。排第二的是“单点备份”。备份文件保存在服务器本地硬盘上而且是和数据同盘比如都在C盘。真到系统盘挂了的时候数据盘也没了备份一起陪葬。这种备份做了等于没做。排第三的是“备份了但没法验证”。文件在内容对不对不知道。有的厂每个月都跑备份计划但从来没试过恢复直到出事儿才发现备份文件早就损坏了或者版本不对、路径不对恢复根本起不来。所以在聊具体操作之前我想先立个观念老MES备份不是“拷贝一份文件”的简单动作而是“在尽可能不打扰生产的前提下把数据库、应用、配置、附件都拿到手并且保证关键时刻能还原回能用的状态”这么一件事。后面的操作流程都是围绕这个目标展开的。2. 上手前先做这几件事别急着双击备份工具也别一上来就敲sqlcmd。老MES系统不是教科书环境你只有先摸清现场才知道备份怎么做才不会翻车。2.1 现场盘点把家底摸清楚我一般上手第一件事是先把目标机器192.168.50.2的“家底”盘一遍。这个环节大概花20到30分钟但能帮你避开后面80%的坑。第一步看服务。在服务器上跑一下net start | findstr /i sql mes scheduler把服务管理器打开看看有哪些相关的Windows服务。常见的有SQL Server的服务名字一般是MSSQLSERVER或者实例名、MES应用的服务还有可能是调度任务、打印服务、共享文件夹服务。一台老MES机兼任打印服务器的情况我见过不止一次盘点的时候没发现后面恢复的时候就漏了。第二步看数据库。打开SQL Server管理工具或者用命令行查一下实例名、数据库列表、恢复模式SELECT name, recovery_model_desc FROM sys.databases;这个查询很重要因为它直接决定了后面备份怎么做。如果恢复模型是FULL但平时没人做日志备份日志文件会一直长大后面备份和恢复都会很麻烦。第三步找连接串和配置。去MES应用目录下找配置文件常见的有app.config、web.config、connectionstrings.config也可能直接写在某个ini文件里。看里面的服务器地址、数据库名、账号确认这台机器对外提供的连接信息。同时别忘了看看注册表老系统很爱把连接信息写在注册表里。第四步问人。不要觉得自己是运维就什么都自己摸老MES背后的业务细节只有车间的人清楚。问几个问题这台机器还有什么额外的兼职哪些目录是重要的共享目录有没有定时任务在每天跑以前出过故障吗当时是怎么处理的问完之后把答案记在运维笔记里后面恢复的时候这些信息比任何工具都管用。2.2 备份目标别选错位置这一步的重要性我给排到最高。备份的位置如果和源数据在同一块物理硬盘上那这备份就是自欺欺人。硬盘坏了源数据和备份一起没。理想情况192.168.50.2这台MES的备份应该放到另一台服务器或者一台NAS上。比如我常用的做法是通过共享目录把备份文件写到内网另一台存储设备上路径类似 \192.168.50.8\backup\MES_2025。如果现场确实没有第二台机器那最低标准也是准备一块大容量移动硬盘备份完成后从服务器上拔走放到另外的地方保存。再提醒一个容易被忽略的问题备份目录的权限。老服务器上跑SQL Server的服务账号通常不是管理员你得给SQL服务账号和备份计划任务用的账号都配上目标目录的写权限不然到时候备份报“无法打开备份设备”你就得临时改权限慌里慌张最容易出错。2.3 备份窗口和频率怎么定老MES最怕打扰生产。车间两班倒甚至三班倒MES全天都在采集数据你大白天的跑一个大容量全量备份即便数据库是在线备份也会占用不少磁盘I/O运气不好就可能让过站扫描变慢车间马上打电话来投诉。所以实操上我建议把时间窗口定在凌晨2点到4点之间。尽量不要选月末月初那时候车间在集中做产量报表数据库压力大。备份前最好和带班班长或者生产主管打个招呼告知凌晨会做备份正常不影响使用但万一备份失败需要重启服务的话会提前通知。频率方面我的默认策略是这样的数据库每天至少1次完整备份如果数据重要且恢复点要求高可以再加每2~4小时一次日志备份应用目录、附件目录每天同步一次配置文件和注册表每次变更后手动备份一份。每周做一次全量、离线归档把备份拷贝到移动硬盘或者刻录到光盘留一份长期保存。整体原则是日常备份尽量不影响生产但关键备份绝对要有。3. 备份实操流程照着抄就能用盘完现场接下来就是正式操作。这一节我按照实际操作顺序来写从数据库开始再到文件和配置最后是外发归档每一步都给出能直接用的命令和脚本。3.1 数据库备份最核心的一步先说SQL Server环境下的数据库备份。老MES里的数据库一般不大完整备份跑得也快凌晨2点做一次通常几分钟就结束了。核心命令如下BACKUP DATABASE [MESDB] TO DISK ND:\MESBackup\DB\MESDB_FULL_20250103.bak WITH INIT, NAME NMESDB-完整备份, STATS 10;其中D:\MESBackup\DB是提前建好的目录盘符根据现场情况调整反正原则就是不要和系统盘混一起。STATS 10表示每完成10%打印一次进度方便确认备份没卡住。如果是SQL Server 2000那种老版本没有SSMS的可视化操作也没关系用osql命令行osql -S 192.168.50.2 -U sa -P password -Q BACKUP DATABASE [MESDB] TO DISKD:\MESBackup\DB\MESDB.bak WITH INIT这里密码我是用-P参数带进去的。老系统的SQL密码可能设得很简单也可能根本已经没人知道正确的密码。如果不知道sa密码那就得提前联系当初实施方的工程师或者翻档案记录因为备份是需要权限的。再补充一个差异备份的写法。完整备份每周1次中间每天可以用差异备份减小备份量和恢复时间BACKUP DATABASE [MESDB] TO DISK ND:\MESBackup\DB\MESDB_DIFF_20250103.bak WITH DIFFERENTIAL, INIT, NAME NMESDB-差异备份;恢复的时候先恢复最近一次完整备份再恢复最后一次差异备份实测能省不少时间。恢复示例RESTORE DATABASE [MESDB] FROM DISK ND:\MESBackup\DB\MESDB_FULL_20250103.bak WITH REPLACE; RESTORE DATABASE [MESDB] FROM DISK ND:\MESBackup\DB\MESDB_DIFF_20250103.bak WITH RECOVERY;恢复模型这块我多说两句。查出来如果是FULL模式一定要配套做日志备份不然日志文件会疯长磁盘迟早爆掉。日志备份命令BACKUP LOG [MESDB] TO DISK ND:\MESBackup\DB\MESDB_LOG_20250103_0200.trn;如果用FULL模式但不做日志备份那我建议直接把恢复模型改成SIMPLE省心代价是恢复只能做到最近一次完整/差异备份的时间点不能做到“秒级”。对大多数老MES来说车间能接受“恢复到最后一次备份”但接受不了“日志文件把磁盘塞满导致系统卡死”所以怎么选你自己权衡。3.2 应用、配置和附件文件备份数据库备份完了接着处理文件和配置。我用的主力工具是robocopyWindows自带的文件复制工具比xcopy稳支持断点重试、日志记录。先把MES应用目录整个拷到备份目录robocopy D:\MESApp D:\MESBackup\App /MIR /R:2 /W:5 /LOG:D:\MESBackup\logs\app_20250103.log参数解释一下/MIR是镜像目录保证备份目录和源目录一致/R:2是失败重试2次/W:5是重试间隔5秒/LOG是把日志写到文件里。第一次跑建议不要加/MIR先普通复制一遍因为/MIR会把目标目录里多余的文件删掉万一目标目录里你放了别的备份文件会给误删。等确认目录结构没问题了再改用/MIR做增量镜像。应用目录里通常有不少临时文件、日志文件这些不用备份反而会让备份体积膨胀。可以用 /XD 参数排除掉比如robocopy D:\MESApp D:\MESBackup\App /MIR /XD D:\MESApp\temp D:\MESApp\log /R:2 /W:5 /LOG:D:\MESBackup\logs\app_20250103.log配置文件要单独备份。首先把MES程序目录里的app.config、web.config、连接串配置文件复制出来加日期后缀保存。其次是注册表老系统的连接信息经常写在注册表里用命令导出reg export HKLM\SOFTWARE\YourCompany\MES D:\MESBackup\reg\mes_reg_20250103.reg /y导出完注册表再用文本打开看一眼确认里面没有硬编码的密码之类的敏感信息需要特殊处理注释说明恢复的时候怎么用就够了。服务列表也是个容易被忽略的东西。执行 sc query 把服务状态导出至少保留一份这样恢复的时候能对照重建服务sc query D:\MESBackup\config\services_20250103.txt sc query type service state all D:\MESBackup\config\services_all_20250103.txt附件目录如果比较大同样用robocopy处理。注意附件目录可能有一个共享名比如D:\MESShare车间电脑映射的是\192.168.50.2\meshare。你备份的时候最好连共享权限配置一起记下来恢复的时候才能还原访问方式。最后提一个操作禁忌备份应用目录的时候如果MES应用正在运行robocopy可能会碰到文件被占用的报错日志里会显示RETRY。如果重试几次还是失败别硬来可以在备份窗口里先停掉相关的MES应用服务拷贝完再启动。停服务前一定先通知车间别一声不吭把夜班给停了。3.3 外发归档与备份记录本地备份做完下一步是把备份“挪出去”。没有异地备份的备份只能算半成品。网络拷贝这一步我一般先把备份目录映射成网络驱动器再robocopy过去net use Z: \\192.168.50.8\backup /user:backupuser yourpassword robocopy D:\MESBackup Z:\MES_20250103 /MIR /R:3 /W:10 /LOG:D:\MESBackup\logs\netcopy_20250103.log net use Z: /delete目标机器的共享目录权限要提前配好。如果公司有NAS那就更简单了直接把备份目录映射到NAS的共享上。我个人的习惯是备份至少两份一份在内网另一台机器/NAS上一份在移动硬盘上每周手动拔走离线保存。移动硬盘拷完就带走别一直插在服务器上否则硬盘跟着机器一起挂了又是单点。备份记录写在最后但重要性排在前面。每次备份完我习惯写一行记录日期、备份类型完整/差异/日志、文件大小、校验值、备份目标路径、执行人。直接写在一个文本文件里放在备份目录下2025-01-03 02:00 完整备份 MESDB.bak 12.3GB SHA256 5ef... \\192.168.50.8\backup\MES_20250103 2025-01-03 02:15 应用镜像 MESApp 5.8GB 文件数 12453 \\192.168.50.8\backup\MES_20250103备份有了记录才谈得上后续的验证、审计和追溯。4. 验证和恢复演练不能省备份这东西平时没人关心出事的时候才想起来。而最怕的就是备份文件在但恢复不了。所以我做备份流程的时候永远把“验证”两字刻在前面。4.1 备份文件的常规校验最简单的验证是执行RESTORE VERIFYONLY它不真正恢复数据库而是检查备份文件的结构完整性RESTORE VERIFYONLY FROM DISK ND:\MESBackup\DB\MESDB_FULL_20250103.bak;输出显示“验证成功”就说明文件没损坏。再用RESTORE HEADERONLY看备份文件的基本信息比如备份时间、数据库名、备份类型防止恢复的时候搞混文件RESTORE HEADERONLY FROM DISK ND:\MESBackup\DB\MESDB_FULL_20250103.bak;文件级别的校验不要跳过。我习惯每天备份完以后给备份文件算个哈希值记在记录里。算哈希不用装额外工具Windows自带certutilcertutil -hashfile D:\MESBackup\DB\MESDB_FULL_20250103.bak SHA256日常操作中我一般每月把现有备份文件重算一次哈希和当初记录的值比对如果变了说明文件有问题尽早发现尽早重备。4.2 低成本做一次恢复演练验证备份文件没坏只证明“文件能读”但不能证明“系统能跑”。真正的底气来自于在另一台机器上完整恢复一次。实操上不需要搞多豪华的恢复环境一台装了同版本SQL Server的测试虚拟机就够。把备份文件拷过去恢复数据库RESTORE DATABASE [MESDB] FROM DISK ND:\TestRestore\MESDB_FULL_20250103.bak WITH MOVE MESDB TO D:\TestRestore\MESDB.mdf, MOVE MESDB_log TO D:\TestRestore\MESDB_log.ldf, REPLACE, RECOVERY;如果是老版本的备份文件比如SQL Server 2000的备份拿到高版本SQL Server上恢复一般没问题反过来高版本备份拿到老版本SQL Server上恢复就报错这一点在准备恢复环境的时候就要注意。恢复完了别急着关虚拟机重点跑几个验证动作通过SQL查询确认数据库里的关键表有数据比如工单表、过站记录表启动一遍MES应用看能否连上恢复出来的库如果客户端也要配连接地址改一下配置连一次测试服务器试试。我见过不少恢复演练库是恢复成功了结果应用起不来一查是连接串里的服务器名没改这种低级错误在演练的时候发现最好真出事的时候才尴尬。恢复演练的频率我建议至少每季度一次。老MES这种系统平时没人去动它的备份时间越久恢复路径的不确定性越大。每次演练都相当于给自己攒了一次“保命经验”。5. 常见问题排查实录老MES备份的日常不会一帆风顺。这里把几个我实际遇到过的、容易踩的坑整理出来做成速查清单顺便讲讲我自己的排障思路。5.1 故障速查清单现象可能原因排查思路与解决提示“无法打开备份设备”备份目录不存在、SQL服务账号无权限、磁盘空间不足先建目录、检查目录权限、用dir命令看磁盘剩余空间备份文件比数据库实际大小大好几倍日志文件一直没截断FULL恢复模型下日志膨胀查恢复模型做日志备份确认不需要点恢复就改SIMPLE备份过程中数据库很慢在线备份占用了IO业务正好在用避开高峰调整备份时间或加MAXTRANSFERSIZE等参数缓解robocopy报错一直RETRY文件被应用锁定停应用服务再做或者跳过该文件加 /XF 排除计划任务到点没跑服务账号密码过期、触发时间不对查看计划任务历史记录确认“上次运行结果”换新密码后更新任务网络复制备份失败网络断线、共享目录不存在、权限不够手动先net use测试连通性确认路径和登录凭据备份完应用启动失败备份过程中误改了配置或服务被停掉别用坏的备份动作影响原系统确认配置改回原值这份清单不是一次能遇到的但每一行背后都有真实事故的影子。最让我头疼的是第一类问题因为看起来是“备份设备打不开”但实际上有可能是磁盘满也可能是SQL服务账号权限被某些安全加固策略改了排查起来要一层层试。5.2 印象最深的三个翻车现场说几个具体的事你们感受一下。第一次翻车是接手一台MES看备份目录里躺着好几个很大的文件夹以为备份齐全。结果某天系统盘损坏恢复的时候才发现那些文件夹只是应用目录的复制件数据库从来没被备份过。那几天只能硬着头皮从坏盘上抢救数据虽然最后找回了大半但其中一部分数据只能和车间一条条核对。从那以后我备份流程里永远强制加上“数据库备份日志检查”这一步每天都要确认bak文件确实生成且大小正常。第二次翻车是FULL恢复模式但没人做日志备份。数据库日志文件涨到了将近1TB把整块磁盘塞满MES完全卡死连备份命令都跑不动了。那次是半夜赶到现场先把日志文件shrink掉然后给数据库恢复模型改成SIMPLE再做完整备份。教训也很简单FULL模式不是随便开的配套的日志备份策略跟不上反而是埋雷。第三次翻车是备份放在服务器本地另一块盘上结果机器整体报销两块硬盘一起坏掉。那次我才明白本机磁盘上的备份在真正的灾难面前约等于零。现在我的习惯是数据库备份完成后必须再有一份网络备份每周还要加一份离线盘这个习惯坚持了很多年虽然多花时间但再也没在恢复数据上受过罪。还有个小技巧分享一下老MES服务器上的时间同步往往不准时间不准会影响备份文件的命名、计划任务的执行甚至数据库事务日志的时序。我每次上手都会看一下服务器时间是否准时偏差大的话顺手校准。这个看起来不起眼但能让备份记录更可信排查问题的时候也少一个变量。我把这套流程反复用了很多年也配合不同厂的情况调整过遇到的问题远比上面写的多。但核心思想一直没变老MES备份不是做一个动作而是做一套闭环——勘察、备份、外发、验证、记录每一步都做到位关键时刻才顶得上。你做的时候可能觉得麻烦但等你真正靠着一份备份救回过一次数据你只会后悔之前没做得更勤快。