传奇M2报错后全区人物装备全没的停服排查与回档恢复教程

M2报错后全区角色等级、背包、仓库、行会装备全部消失，优先按“停服防覆盖、看M2日志、定位角色库、用备份回滚、无备份做文件级抢救”处理。全区丢档通常不是玩家自己误操作，而是DBServer角色库被清空、被旧备份覆盖、异常关机写坏、SQL库回滚到空实例，或者M2加载时读了错误数据目录。下面按单机架设、局域网开服、云服三种环境通用处理。

一、出事后第一动作：别反复点启动

M2弹错以后很多人习惯关掉再开、再关再开，这个动作最容易造成二次损坏。角色数据文件正在被DBServer占用时，强制重启会让Hum.db、Mir.db、FDB、SQL表头写入一半，原来能扫出来的数据也会变成0字节或空记录。正确做法是先全停：

1. 游戏控制中心或启动器点停止，按M2Server、DBServer、LoginSrv、各个Gate顺序关；直接用任务管理器也行，结束M2Server.exe、DBServer.exe、LoginGate.exe、SelGate.exe、RunGate.exe、LogDataServer.exe等进程。
2. 如果是SQL版，到服务里停MySQL或SQL Server对应实例，别让数据库继续写日志。
3. 不删任何文件、不覆盖任何目录，先把当前出事状态整份拷出来。假设服务端在D:\MirServer，复制到E:\MirServer_broken_当天时间，后面无论怎么修都有退路。
4. 杀毒软件隔离区看一下，M2Server.exe、DBServer.exe、各类引擎dll如果被隔离，先恢复并加信任，再判断是不是杀毒误删导致加载空库。

二、看M2报错内容定方向

不同报错对应不同根因，不要不看日志直接回档。

1. Access violation at address xxx in module M2Server.exe
一般是M2核心文件损坏、配置文件有异常字符、杀毒拦截、解压不完整。先核对Mir200下M2Server.exe大小是否正常，重新解压同版本完整包；再查Mir200\Envir里Merchant.txt、MonGen.txt、QuestDiary、各种列表文本是否有乱码、多余空格、半角全角混用。BLUE/LegendM2若卡授权，检查引擎版本、注册文件、授权是否过期。
2. DB Connect Error、数据库连接失败、LoginSrv connect failed
角色丢档伴这个错，说明M2根本没读到角色库。Access型查DBServer.ini里数据路径；SQL型查IP、端口、库名、账号密码，本地库填127.0.0.1，MySQL默认3306，SQL Server看实例名和sa密码；数据库服务没启动就先启动服务。账号能登但进角色空，重点不是网关而是DBServer到角色库这一层。
3. Map file not found、地图加载失败、Invalid filename
这类一般不会直接清全区装备，但会让M2加载中断，后续如果管理员手动换了错误服务端目录，就可能把角色库指向空文件夹。按报错地图名补Map目录和MapInfo配置即可。
4. 时间格式报错、Script Goto死循环、RegenMonsters exception
时间格式改系统区域为yyyy-MM-dd，或清!Setup.txt里相关日期参数；脚本死循环按日志定位NPC和QuestDiary段落，调ScriptGotoCountLimit后重启；刷怪异常查MonGen和地图怪物对应。它们本身不直接清装备，但会诱发你误重启。
5. 端口被占用、M2空白不加载
netstat -ano查15000、5000、7000/7100/7200等对应端口，结束占用进程；网关全没起来时M2看起来像启动了，实际角色数据交互异常。换端口或释放占用再起。

三、定位角色和装备存在哪

不同引擎存法不一样，找错目录回档没用。

1. 老LEG/BLUE/Hero类文件库
账号在MirServer\LoginSrv\IDDB，存ID.db、ID.db.idx之类；角色在MirServer\DBServer\FDB，常见Hum.db、Mir.db、Guild.db，或者Account.fdb、RoleData.fdb、RoleEquip.fdb等。装备、背包、仓库、技能、坐标主要在角色FDB/DB里。
行会在Mir200\GuildBase，沙巴克在Mir200\Castle；仓库单独配置时在Mir200\Envir\Storage；部分版本玩家数据还会放Mir200\Envir\UserData。全区丢要同时看FDB/DB和这些附属目录。
2. GOM/GEE类
有的仍用DBServer\FDB存角色，有的用Mud2\DB或独立SQLite，比如GEE可走Mud2\DB下GEEM2.db；GOM看版本，SQL版常见HeroDB。改回档前先确认引擎配置到底走文件还是走SQL。
3. SQL版
MySQL看my.ini里datadir，找herodb或自定义库；SQL Server用Management Studio看实例和库表。全区空了优先怀疑还原错了bak、附加了空mdf、或者同步脚本truncate了角色表。

四、有备份：按时间点回滚

先确认玩家说的“全区没”是报错前正常、报错后空，还是报错前就已经回档。选备份点取M2报错之前最近一次完整备份，且要比玩家最后在线时间早一点，避免把备份点之后的合法产出也回掉。

文件库步骤：

1. 全停M2、DBServer、LoginSrv、Gate，停SQL服务（如果是SQL版）。
2. 把当前DBServer\FDB、LoginSrv\IDDB、Mir200\GuildBase、Castle、Storage整目录再备一次到别的盘。
3. 从备份目录取对应日期的FDB/DB，覆盖回DBServer\FDB；账号异常再覆盖IDDB。只回角色就只换FDB，别顺手把Envir脚本也盖了，除非确认脚本也一起坏。
4. 检查StdItems.db或物品数据库编号是否和当前客户端一致，物品编号变了会出现装备变木剑、属性全乱；跨版本回档必须保证StdItems一致。
5. 启动顺序按LoginGate/DBServer/M2/控制中心或版本原顺序来，进游戏抽几个老玩家名查等级、背包、仓库、行会。全空依旧，说明备份本身就是空库，换更早备份。

SQL步骤：

1. 全停服务，备份当前data目录或做一次mysqldump/SQL Server完整备份。
2. MySQL用备份sql重新导入，或把data下对应库目录用备份库目录替换；SQL Server用SSMS还原herodb.bak，选WITH REPLACE注意会覆盖现有库。
3. 核对DBServer配置里的库名、账号权限，重启DBServer再起M2。
4. 登录验证前先通过DBServer管理菜单按人物名称查找，能查到记录再放玩家进，避免又因权限问题读空。

自动备份目录一般在服务端Backup，或者面板计划任务生成的sql/fdb压缩包。云服务器先问厂商要系统快照，很多机房快照比本地备份新，但快照会连同期系统状态一起回，需评估其它业务影响。

五、无备份：先做文件级抢救

没备份不等于完全找不回来，但别乱用来路修复器。

1. DBServer自带数据管理查找
保持服务端可启动状态（如果还能起），打开DBServer.exe，管理、数据管理、人物名称输入角色查。若角色被禁用、被标记删除，可按管理功能启用；若查出来完全没记录，说明FDB/DB已被覆盖或清空，走文件恢复。
2. 回收站和文件历史
服务器上如果是误删FDB/IDDB/DB目录，先看回收站；Windows开过文件历史记录的，控制面板、文件历史记录按时间挂载恢复。操作前对原盘停止写入。
3. 磁盘未覆盖恢复
FDB/DB被删但没新数据写入，用Recuva、DiskGenius等扫描原服务端所在盘，找Hum.db、Mir.db、*.fdb、HeroDB相关文件，恢复到另一块盘。千万别把恢复文件直接写回原服务端目录，避免覆盖残留扇区。
4. 云快照和厂商备份
云主机提IP、实例ID、故障时间，让厂商看自动快照、镜像、数据库备份。即使你本地没备，厂商快照常能回整个D盘或系统盘；回快照前把出事后的FDB再拷出来，避免快照也不完整。
5. M2缓存类提取谨慎用
部分站会让你下“缓存提取工具”扫Mir200\Cache里UserCache、ItemCache。这类操作对新手风险高，第三方工具可能带马，也会把不完整缓存写进正式库造成更乱。无备份且M2没重启过可让有经验的工程师在隔离机做，不建议直接生产环境跑不明exe。
6. 数据库修复命令仅限SQL且先备份
MySQL表损坏用CHECK TABLE、REPAIR TABLE；SQL Server用DBCC CHECKDB查损坏，再按报告修。文件库不要拿SQL命令硬修，用对应引擎的DB编辑/修复工具，且只在副本上试。

六、全区丢档的常见根因对照

1. 异常关机/强杀M2
断电、死机、任务管理器强结束，正在写角色数据时会半截落盘。表现：重启后能进区但全员空身甚至0级。预防是控制中心正常停、数据库自动存盘间隔别太长。
2. 用空FDB覆盖
合区、换版本、挪服务器时，把新服务端空DBServer\FDB直接盖了老FDB。表现：启动正常、登录正常、所有角色像新建。预防是覆盖前比对文件大小、角色数，先起DBServer查总数再放玩家。
3. SQL还原错库/空bak
还原时选了空备份、旧备份、别的区库。表现：全区回几天前甚至全空。预防是还原前SELECT查角色表行数，确认bak生成时间。
4. 数据目录配置指错
!Setup.txt、DBServer.ini、引擎配置器里数据路径写成别的盘或空目录。表现：M2不报严重错，但读到的都是新空库。预防是改路径后先用DBServer查人物数。
5. 杀毒/安全软件隔离DBServer或dll
M2用降级模式启动，加载默认空配置。表现：报错后重开全空。查隔离区、加信任、用管理员权限起。
6. 插件或第三方“清档/合区/转数据”工具出错
非官方合区工具、转库工具、清脏数据脚本，最容易把装备表清掉。任何批量操作前先全量备FDB/IDDB/SQL。

七、回档后校验清单

别只看能登录就完事。按下面逐项抽测：

1. DBServer查人物总数，和报错前GM日志、在线名单、充值记录比对。
2. 抽老玩家查等级、职业、地图坐标、金币、背包、仓库、穿戴；抽查行会长和沙巴克官员装备。
3. 查仓库密码、好友、任务进度是否随角色库一起回来；单独备份了Storage/QuestDiary的要合并。
4. 查爆率、商店、NPC脚本没被回档误盖；如果只回FDB不回Envir，脚本保持当前版，避免回旧脚本出现命令不兼容。
5. SQL版回档后给DBServer账号重授权，避免能启动但部分角色读不出。
6. 起服后观察M2日志半小时，看是否还有DB Wait Error、ProcessHumans、RunDB异常；有就继续查数据库连通性和文件权限。

八、后续防再丢的配置

1. 每天全量备MirServer，至少拆备DBServer\FDB、LoginSrv\IDDB、Mud2\DB或SQL库、Mir200\Envir、GuildBase、Castle。备份放非系统盘，云服再传一份对象存储。
2. 文件库可每2到6小时自动复制FDB压缩；SQL库用mysqldump或SSMS维护计划，保留7到15天。
3. M2和DBServer都走管理员权限，整个MirServer加杀毒白名单；改任何脚本、DB、合区前先手动备一份带日期的目录。
4. 正常停服用控制中心停止，不任务管理器强杀；服务器系统计划任务别在写盘高峰重启。
5. 换版本、合区、迁服务器时，先在新环境只启DBServer查角色数，再起M2放少量测试号，确认装备、仓库、行会都在再公测。
6. 记录启动顺序、数据路径、备份密码和保留策略；出事时按“停服、备坏档、看日志、定路径、回最近备份、校验”六步走，不凭感觉覆盖。

如果M2报错截图里有具体红字，比如Access violation地址、DBConnectError、Map文件全名、时间格式错误，按对应段处理更快；全区空档优先怀疑FDB/DB被覆盖或SQL回错库，先别修小脚本，先把角色库备份和回滚做对最省时间。