记武汉疫情期间的一次数据库和翻译记忆库的数据恢复（一）

本文目的为未来自己或他人进行翻译记忆库数据恢复做参考，会保留技术细节，但其中涉及到很多客户的具体信息以免信息泄露尽量都已隐去, 截图部分都是在自己环境模拟的截图，不是客户真实情况截图

因为众所周知的原因，武汉地区从十二月底左右进入全面封锁状态，企业也同时停工停产，终于在全国医生护士的努力和全国人民的支持，五一前武汉各个企事业单位逐步恢复了生产，然而得知了一个不幸的消息，武汉的某单位由于疫情放假，服务器完全处于无人看管状态，复工时经检测翻译服务器Groupshare无法连接和开启，客户IT检查由于疫情期间无人看管服务器机房，发生多次空调断电，服务器过热，死机关机情况，现在服务器上的SQL Server也已经无法启动，不知道具体损坏到什么程度，向我寻求帮助。

再这样一个全民动员的大环境下我当然不能拒绝，本来我其实可以不需要管这件事情的，但是考虑到客户和企业的难处，再加上是国难的原因，我实在是不能推脱，尽我所能帮助恢复吧。

首先这个Groupshare架构由两台服务器组成IIS， Application Server在一台A机器上，SQL Server在B机器上，目前错误发生在了SQLServer上，IT进行了检查发现部分数据库索引和一部分内容损坏，SQL Server无法启动，IT的计划是放弃原服务器，希望在能恢复数据的情况下迁移到新服务器。

远程连接到客户IT平台，客户IT人员恢复了数据到临时机器，当然现在Groupshare系统是完全瘫痪状态，进数据库查看，TradosServer_SDLSystem，TradosServer_TMService都在，TradosServer_MTMaster也在，但是IT说恢复过程中存在一些问题，数据库在了，但是不知道里面的具体情况如何，总而言之先挂载上去，远程到了A机器，重新运行配制，将数据库环境指向临时C机器，打开Web端测试

OK可以登录了，以客户提供的账密登录正常，然而系统中只有项目，用户信息，术语库部分经测试正常，看不到任何翻译记忆库。

经过客户协助查找得知客户之前有三个翻译记忆库并且知道客记忆库的名字和语言方向信息，这时和IT尝试远程连接到B的数据库，看到有一个近3G的数据库没有恢复出来，TradosServer_TMContainer，告知IT这是关键数据库，并提供了DataNumenSQLRecovery
https://www.datanumen.com/ 用于数据库恢复

和SQL DXP for SQL Server
https://sqldelta.com/ 用于数据库比较

之后就是N个小时的等待，终于客户IT告知恢复完成了可以远程了。

将恢复的TradosServer_TMContainer挂在到C机器的SQL上之后

打开数据库TradosServer_TMService的[TranslationMemory]表
可以看到之前系统中的翻译记忆库
DatabaseServer
Container
都有了数据，
TranslationMemory表中查看到翻译记忆库信息
和LanguageDirection表中可以查到库里的具体语言信息

此处我怀疑这几个小时IT重新恢复了全部数据之前这几个表尤其是DatabaseServer和Container都是空的，并且SDL_System库的

SELECT TOP (1000) [resourceId],[resourceGuid],[Resource].[resourceTypeId],[resourceName],[resourceDescription]FROM [BEIGROUPSHARE02_SDLSystem].[sts].[Resource] join [BEIGROUPSHARE02_SDLSystem].[sts].[ResourceType]on [Resource].[resourceTypeId] = [ResourceType].[resourceTypeId] where [ResourceType].[resourceTypeName] = 'TM'

之前的是空，现在有了数据
因此应该可以显示出翻译记忆库了

再连接A机器的Web端新建DataServer (System Configuration>Servers>New Server)

然后挂载TM Container (System Configuration>Containers>New Container)

重启服务后登陆A机Web端，果然可以见到之前的翻译记忆库了，名字和语言方向都显示出来了，但是客户端连接上无法使用翻译记忆库，Web端的导入导出也不能正常工作。查询了后台运行日志也没有找到办法。

（目前为止就是公司官方给出的数据恢复方案，经过尝试并不能完全恢复客户数据）

我决定接下来的工作分成两个步骤来做

既然客户准备了迁移，IT提供新机器包括IIS和Application的E机器和SQLServer的F机器，我在E和F上部署，数据库现在阶段直接放到F
由于我配置E和F也需要大量时间，我在配置E和F前，指导客户IT从SQL 数据库表中将可用数据导出按照指定格式给到我，接下来我再进行更进一步的数据恢复

首先通过人员准备的远程连接登入服务器D，IT 人员同时在配置服务器E的SQL并传递数据。
服务器D是Server 2012，因此需要Server 2012的系统盘以便安装.NET 3.5，IT人员提供了一个70MB的sxs包而不是系统盘。因此
dism.exe /online /enable-feature /featurename:netfx3 /Source:C:\sxs
然后等待配置IIS和Application服务，其中包括ASP.NET, WebDAV, 诊断工具， WebSocket等

然后准备.NET Framework 4.7.2 遇到一个问题缺失补丁KB2919355，好在这个问题之前也遇到过
这个补丁比较特殊
https://www.microsoft.com/zh-CN/download/details.aspx?id=42334
有非常强的依赖性KB2919355安装之前要有KB2919442，并且要先运行clearcompressionflag.exe 之后还有几个更新，正确顺序如下：

KB2919442
clearcompressionflag.exe
KB2919355
KB2932046
KB2959977
KB2937592
KB2938439
KB2934018
而且补丁巨大，接近900MB的补丁文件上传到服务器再安装，时间又过去一些
准备好之后服务器进行机器重命名，重启
开始准备
我的计划是因为指导客户用的版本比较低，没有跟上重大更新，可以在这次更新上最新的版本，以免后续失去支持
先安装ErLang，再安装rabbitmq
rabbitmq-plugins enable rabbitmq_management
期间vcredist自动配置，又是不少的时间
正是开始Groupshare EnterpriseEditionSetup.exe
前面进一步的环境和信息采集配置好选择E服务器作为数据库，突然显示无法连接，又卡住了，上载一个DatabaseNet4同样无法建立数据库连接
邀请客户IT来检查防火墙端口账密都没问题，服务器E中完全正常
没办法在服务器D安装SSMS SQL Server Management Studio
https://docs.microsoft.com/zh-cn/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15
安装后重启，数据库连接正常了
重启安装继续，又是一个惊喜，直接报错，SDL_System库中用户名SDLGSA已存在
既然已存在那就只能删除，Security>Users 删除指定的用户
重新启动安装，有一个惊喜
SDL MultiTerm Matrix Cache Service 异常终端
忽略错误后安装完成，
然后SDL Application Service无法启动
这也是个常见问题，我就不去事件查看器查看了，直接更新证书重启
SDL Application Service正常了
但是无法打开Configuration Console，连续的安装和惊喜不断导致时间已接近晚上十一点，几乎是一整天然后到晚上实在坚持不住，先睡觉了第二天继续。

第二天登录服务器D，找到SDL MultiTerm Matrix Cache Service 的日志，知识库中完全没有相关的信息，只能自己解决，从Log看是一个注册表没有记录的错误， regedit 进入注册表
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SDL\MTServer15\
注册表信息正常

检查 SDL MultiTerm Matrix Cache Service的程序
C:\Program Files (x86)\SDL\SDL Server\SDL Multiterm\Multiterm15\Sdl.MultiTerm.MatrixCacheSrvc.exe
手动启动后报XML配置文件错误
所在目录
C:\Program Files (x86)\SDL\SDL Server\SDL Multiterm\Multiterm15\
下的
MigrationWizard.exe.config
这里没有错误
然后进一步个人设置
C:\ProgramData\SDL\SDL MultiTerm\MultiTerm15
发现
Settings.xml大小为0KB 测试不可访问
重启后方可删除
重建文件

<?xml version="1.0"?>
<settings>
<key name="MultiTerm">
<value name="MaxLoginTime">480</value>
<value name="Server">1</value>
</key>
<key name="MultiTerm\ServerDatabaseInfo">
<value name="(default)">Sql</value>
<value name="Location">▇▇▇▇▇▇▇▇</value>
<value name="MasterDB">▇▇▇▇▇▇▇▇_MTMaster</value>
<value name="UserID">▇▇▇</value>
<value name="Password">▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇</value>
</key>
<key name="MultiTerm\MTJobsSettings">
<value name="JobsFolderLocation">C:\Windows\TEMP\Transfer</value><value name="MaximalJobInactivity">1800</value>
</key>
<key name="MultiTerm\Timeouts">
<value name="GetTermbases">2</value
></key>
</settings>

再次运行安装，果然 SDL MultiTerm Matrix Cache Service正常了，但是又一个惊喜文件存储不可访问，这个之前昨天的安装是没有问题的，稳住心态，重启服务器后安装正常，Web页面打开，账密登录正常，挂载上之前数据库的DataServer和Container，翻译记忆库可见。
至此目前完成了迁移，服务器D和E具备替代A和B的条件，并且达到了A和C组合的状态并且版本比AC组合高，当然性能也要高C是临时Server性能一般。

接下来联系客户IT将DNS绑定从A服务器切换至D服务器，之后完成了许可证的切换。

另一方面，虽然这边的框架搭好了，数据还没有完全恢复。
之前和客户IT做了交代：
TradosServer_TMContainer数据库下面的
translation_units_1表数据导出为CSV
关键是这样个字段
[source_segment]，[target_segment]
里面是XML数据结构大概是这样：

<Text><Value>单击〖</Value></Text><Tag><Type>Standalone</Type><Anchor>1</Anchor><AlignmentAnchor>1</AlignmentAnchor><TagID>1626</TagID><CanHide>false</CanHide></Tag><Text><Value>〗按钮，鼠标指针变为长度测量状态，在地图视图区依次单击折线段的起点和拐点，在终点处双击鼠标左键结束，系统显示出测量结果，如</Value></Text><Tag><Type>Standalone</Type><Anchor>2</Anchor><AlignmentAnchor>2</AlignmentAnchor><TagID>1640</TagID><CanHide>false</CanHide></Tag><Text><Value>所示：</Value></Text>

其中TradosServer_TMContainer库translation_units_后面的数字对应的是
TMService库LanguageDirection表的[PhysicalTmId]这个字段
然后连接上TMService的[TranslationMemory]和TMContainer].[translation_memories]的name字段并截取

/****** Script for SelectTopNRows command from SSMS  ******/
SELECT TOP (1000) [LanguageDirectionId],[LanguageDirection].[LastRecomputeDate],[LanguageDirection].[LastRecomputeSize],[PhysicalTmId],[SourceCultureName],[TargetCultureName],[LanguageDirection].[TranslationMemoryId],SUBSTRING([BEIGROUPSHARE02_TMContainer].[dbo].[translation_memories].[name],38, Len([BEIGROUPSHARE02_TMContainer].[dbo].[translation_memories].[name])-38),[TuCount],[LastReIndexDate],[LastReIndexSize]FROM [BEIGROUPSHARE02_TMService].[dbo].[LanguageDirection]join [BEIGROUPSHARE02_TMService].[dbo].[TranslationMemory] on [BEIGROUPSHARE02_TMService].[dbo].[LanguageDirection].[TranslationMemoryId] =[BEIGROUPSHARE02_TMService].[dbo].[TranslationMemory].[TranslationMemoryId]join [BEIGROUPSHARE02_TMContainer].[dbo].[translation_memories] on [BEIGROUPSHARE02_TMService].[dbo].[LanguageDirection].[TranslationMemoryId] =LEFT([BEIGROUPSHARE02_TMContainer].[dbo].[translation_memories].[name],36)

这样就搞清楚了数据库和翻译记忆库名字对照关系

接下来真正的数据恢复分下一篇吧