一、迁移前准备：环境一致性与文件备份
更换服务器前，必须确保新旧环境兼容，避免因引擎或数据库差异导致数据损坏。
1. 环境一致性检查
• 引擎版本：新服务器需安装与老服务器完全相同版本的引擎（如 GOM、GEE、Hero），不可直接使用新版引擎覆盖，否则可能导致数据库结构不兼容。
- 服务端路径：建议新服务器将服务端解压至与老服务器完全相同的路径（如均为 D:\MirServer），减少后续配置文件路径修改的复杂度。
- 停止服务：操作前，在老服务器上彻底关闭 M2Server、DBServer、LoginSrv 等所有进程，确保数据文件未被占用。
2. 定位核心数据文件
传奇的数据存储分为账号库和人物库，迁移即复制这些物理文件。
- 账号数据库：位于 MirServer\LoginSrv\IDDB\ 目录。该文件夹内的 .dbs 或 .db 文件存储了所有注册账号、密码及角色关联信息。
- 人物数据库：位于 MirServer\DBServer\FDB\ 目录。该文件夹存储了所有角色的等级、装备、技能、地图坐标等详细数据。
- 扩展数据：若需保留行会、沙巴克、GM名单，还需备份 Mir200\GuildBase\、Mir200\Castle\ 及 Mir200\Envir\AdminList.txt。
二、文件迁移实操：覆盖与验证
1. 文件传输与覆盖
• 复制文件：将老服务器 IDDB 和 FDB 两个文件夹整体复制（可通过U盘、FTP或远程桌面文件共享）。
- 覆盖操作：在新服务器上，停止所有服务端程序，将复制过来的 IDDB 和 FDB 文件夹，直接覆盖新服务端对应目录下的空文件或旧文件。
- 权限设置：若新服务器为云服务器或权限较严，覆盖后需检查文件权限，确保 DBServer 等进程有读写权限。
2. 数据库一致性校验（关键）
这是迁移中最易出错的环节，涉及物品编号匹配。
- StdItems.DB 检查：对比新旧服务端 MirServer\mud2\DB\StdItems.DB 文件。若两个文件的物品编号不一致，迁移后玩家的装备可能会“变异”（如屠龙变成木剑）。
- 处理方案：若物品库不同，需使用数据库工具（如 DBC2000、Access）将老数据库中的角色数据导出，再导入新数据库，或直接使用老服务端的完整 DB 目录覆盖新端。
三、特殊引擎与数据库处理
1. SQL数据库版本（如 GOM部分版本）
若服务端使用 MySQL 或 SQL Server 存储数据，而非 Access 文件：
- 备份导出：在老服务器使用数据库管理工具（如 Navicat、MySQL Dump）导出整个数据库为 .sql 文件。
- 导入还原：在新服务器创建同名数据库，将 .sql 文件导入。需确保新服务器的数据库连接字符串（通常在 !Setup.txt 或 Config.ini 中）配置正确。
2. 微端与登录器适配
• IP更新：迁移后，需根据新服务器的内网/公网IP，修改 MirServer\LoginSrv\!addrtable.txt 及各个网关的 Config.ini。
- 登录器列表：为新服务器生成新的登录器，列表文件中的IP需更新为新服务器的地址。玩家需更换登录器才能连接新服务器。
四、迁移后启动与排错
1. 启动顺序：覆盖文件并配置好IP后，通过 GameCenter 启动所有服务。
2. 查看M2报错：观察 M2Server 控制台是否报红字。若提示“加载人物数据失败”，通常是 FDB 文件权限不足或路径错误。
3. 测试账号：使用老账号登录，检查等级、装备、背包物品是否完整。若仅部分数据异常，重点检查 StdItems.DB 的兼容性。
4. 回滚预案：操作前务必备份整个新服务端，若迁移失败，可快速回滚至空白状态。
五、极速操作清单
1. 关进程：关闭老服务器所有引擎进程。
2. 拷文件：复制老端的 IDDB 和 FDB 文件夹。
3. 全覆盖：在新端停止状态下，覆盖对应目录。
4. 对物品库：检查 StdItems.DB 是否一致。
5. 改IP：更新新端的 !addrtable.txt 为当前服务器IP。
6. 启服务：启动新端，测试老账号登录。
按照此流程，绝大多数基于文件数据库（Access）的传奇服务端均可实现账号人物的无缝迁移。
