===
声明：以下内容本是自己写给单位内部同事的参考手册，但是被传到百度文库中。陆续有用户就这方面的问题，通过电话，邮件等方式联系我。首先，感到荣幸。其次是，由于本人当时测试和编写的时候，由于仓促，可能有存在着缺陷的地方。如果大家在实际的工作中，按照这个方式出现问题或者想和我交流的话，请在该文章下面留言，尽量回复大家。最后，个人不代表单位，也不代表官方。
该文章百度文库的连接如下：
下面的内容与文库有点不一样，修改了诸如图片序列，错别字等低级错误。
===
在实际的工作环境中，服务的备份与恢复是日常基础的维护与管理操作。但是直到10.2 的版本，ArcGIS for Server才推出站点的恢复与备份功能。这就导致10.2之前的10.1和10.1sp1的Server，在需要迁移或者重新安装的时候，无法重用已有服务。官方的迁移和回复答案是对site中的所有的服务都需要重新发布。那么问题就来了，当site中的服务特别的多，更甚发布服务的mxd文档找不到的时候，重新发布服务变得比较困难。这个时候就迫切的需要在不需要重新发布服务的情况下，能批量对已有site中服务进行迁移且在新的site中能够正常的运行。
在日常的技术支持工作中，经常遇到用户反馈上述需求。基于上面的目的，为了测试在不重新发布服务的情况下，平稳的迁移site。特做了多组测试。最后总结服务迁移的操作方式。
1单台服务器
测试环境：Windows Server 2008, ArcGIS for Server 10.1, Oracle 11gR2
1.1 情形一：数据源相同
由于服务的能否正常使用，一个关键点是服务能够找到对应的数据源，为了避免数据源带来的影像，在情形一的所有测试中，假设发布服务的数据源的绝对位置没有发生变化和连接数据源的连接方式没有发生变化。
A． Config-store 和directories 存放路径相同
测试说明：
假设迁移前的ArcGIS for Server的服务目录为C:arcgisserver, config-store和directories 位于该目录下。且迁移后，新的site的服务目录不变。
测试步骤：
STEP 1： 拷贝迁移前服务目录中的 config-store里面的services目录和整个directories（更为方便的方式是拷贝整个arcgisserver目录）
STEP2: 删除site
STEP 3：重新创建site，根据前提条件，目录和原先site保存不变
STEP4：如果STEP1拷贝的只是services和directories 转到步骤5，拷贝了整个arcgisserver目录转到步骤6
STEP5：将步骤1备份的Services目录和directories 目录拷贝到新创建的site对应的目录下，覆盖对应目录。由于data store的存储信息没有带过来，故重新注册data store（注意，data store和迁移前的一模一样，包括，data store的名字，连接字符串等，否则不能称为数据源不变）。
STEP6: 拷贝过来的arcgisserver目录，由于拷贝丢失了相关的权限信息。故在文件夹属性的安全中，赋予ArcGIS for Server的完全控制选项。
STEP7： 重新启动服务
结果：
测试的地图服务，要素服务，gp服务，切片服务都能正常运行。则证明通过这种方式，完全可以在不用重新发布服务的情况下，对站点中的服务进行迁移。测试中发现，STEP5中即使不注册数据源也能成功，证明在msd中记录了数据源的连接信息。
B. config-store 和directories 存放路径不同
假设迁移前的confg-store和directories在C:arcigsserver,而新安装的ArcGIS for Server的目录在D:arcigsserver 目录下。则按照上面1中的测试步骤测试。重启服务的时候，出现了如图1-1的错误。
图 1‑1重启服务出现错误
这错误也有力说明了，服务的发布是通过msd的形式。既然是msd的路径没有改过来，就需要找到Server的配置文档，并修改相对应的位置，在该过程中，分别尝试修改了两个出现上面路径的地方
路径1：在arcgisinput的目录下的相对应服务目录下的manifest.json和manifest.xml文件（如arcgisinputsiteRSMyMapServiceRS.MapServerextracted），通过这种方式重启服务，任然出现图1错误。说明msd的路径的映射不在该位置。
路径2：在config-store的services目录中找到对应的服务目录，修改了服务名对应的json文件中的相对应路径（如：config-storeservicessiteRSMyMapServiceRS.MapServerMyMapServiceRS.MapServer.json）如图1-2所示：
图 1‑2服务配置文件
将以上路径，修改新site中的对应的位置，重新启动服务。所有服务都能正常启动。
C. ArcGIS for Server的账户不同
上面1和2的测试情况，易出现在Server正常而site的不能正常的情况，在可以不重新安装Server的情况下，修复site中的服务。
除了上面的情况，还有一种较为常见的情况，就是Server服务不能正常启动。这个时候就手动需要修复Server。通常推荐的方式，就是通过卸载已有的ArcGIS for Server，然后重新安装。
测试说明：
备份的ArcGIS for Server的账户Administrator 密码：Administrator，而重新安装的ArcGIS for Server的账户：ArcGIS 密码：ArcGIS；且arcigsserver目录保持不变。
测试步骤：
STEP1：卸载前，对config-store中的services和directories或者整个arcgisserver目录进行备份。
STEP2：删除Program Files目录中的全部Server目录，删除arcgisserver目录（也可以不手动删除，但是建议全部删除）
STEP3: 重新安装Server，创建站点
STEP4：将STEP1中的备份文件拷贝到对应的目录下
STEP5：重启服务，但是出现如图1-3所示的错误：
图 1‑3启动错误
通过查看日志文件，出现如下创建实例失败。如图1-4所示:
图 1‑4日志文件
通常出现该问题就是Server的账户没有权限访问到arcgisserver目录。为了验证是账户权限导致该问题，作了如下两种验证：
方式1：通过Configure ArcGIS Server Account 更改Server的账户，操作如图1-5所示，更改到备份前Server账户。重启Server服务，服务能正常启动和使用。
图 1‑5修改server账户
方式2：在不修改server账户的前提下，修改arccgisserver文件夹属性，更改其安全，如图1-6所示，赋予新的ArcGIS Server账户对arccgisserver目录的控制权限。重启备份的服务，服务能正常启动和使用。
图 1‑6更改文件权限
PS：请注意ArcGIS for Server的账户与ArcGIS for Server的管理账户的区别。
1.2 情形二：数据源不同
上面的情形一中，都是默认数据源是相同的。但是在实际的情况下，有可能出现如下情况诸如：
更改了Server中的服务的数据源的连接字符串，如数据库的用户名，密码或者ip发生了变化，导致通过注册到Server的旧的sde连接字符串没有办法访问新的数据库。还又如发布服务的时候数据存储在filegeodatabase中，现在数据存储转存到sde中等等。不管怎么样，就是现在的Server访问不到发布服务的数据源。
测试说明：
为了单纯的测试数据源的不同，该测试中，默认迁移的时候，Server的账户和site的存储位置不变。只改变了连接sde的密码。
测试步骤：
和上面步骤大致一样。启动服务，服务能够正常启动，如图1-7所示：
图 1‑7 服务界面
但是通过rest页面访问的时候，出现如下1-8的错误：
图 1‑8 错误信息
由于Server端服务的正常与否是由msd决定的。为了探究能否直接修改msd中的数据源连接，来修复服务。尝试更改了msd的后缀，将其更改为zip，而后解压，可以看到msd包括的内容如图1-9所示：
图 1‑9 msd的文件结构
其中layers里面包含了服务的图层的配置和渲染信息，也记录了连接数据库的信息。由于数据库的密码已经被加密了，没有办法直接去更改xml文档中的密码。既然msd是由mxd生成，故选择修复服务器端的mxd文档，根据修改后的文档去重新生成msd。
Mxd和msd都位于该arcgisinput目录的对应的服务里，如：
C:arcgisserverdirectoriesArcGISsystemarcgisinputSiteRSMyMapServiceRS.MapServerextractedv101
结果：
使用arcmap或者arcpy修复mxd，然后通过arcpy生成msd，覆盖现当前的msd，重新启动服务。服务能够正常启动和使用。同理可推，如果是将数据从file迁移到filegeodatabase或者到sde，或者三种互相迁移，同样可以先通过修复服务器端的mxd，然后再生成msd文件，来修复服务。
1.3 情形三：未注册data store的情形
上面测试的情形，都是注册了data store的情况。在实际的情况中，还有未注册data store的情况。由于不注册data-store，服务中使用的数据，已经存在在服务目录的arcgisinput的目录中以文件（shapefile或者影像）或者filegeodatabase的形式存在。
由于服务的发布是通过msd的形式，只要恢复的Server能够访问到对应的msd文件即可。具体的更改和设置参考情形一中的多种情况。
2 多台服务器
在实际的工作中，服务迁移，除了刚才的在同台服务器中迁移外，还有一种情形，就是在多台服务器中之间迁移。
2.1 测试环境
服务器A：ArcGIS for Server10.1+Windows Server2008+Oracle11gR2
服务器B和服务器A的环境一致。
2.2 测试说明
服务器A上安装了ArcGIS for Server，且具有地图服务，切片服务，要素服务，gp服务等。需要将这些服务前移到服务器B上，在不需要重新发布服务的情况下，能够正常使用。
2.3测试步骤
按照单台服务器迁移的多种情况，分别进行了测试。大体如下：
首先在服务器B上，安装与服务器A中的相同版本的Server，构建站点。将服务器A中备份的文件拷贝到服务B arcgisserver相对应的目录下。
在多台服务器上的迁移，根据测试的情形不同，出现的现象和单台服务器测试情形完全一样。
不同的是，如果将服务器A中整个arcgisserver的目录拷贝到B中，覆盖B的全部ArcGIS Server目录的话，B中的站点将会丢失。访问manager将出现创建站点的页面，出现这个问题的原因是，arcgisserver中的config-store记录了机器是否属于某个site。为了避免去逐个修改config-store中的machine中的机器名，建议只覆盖config-store中的services和directories目录。
3 结论
根据上面的测试，可以完全在不用重新发布服务的情况下，对已有站点中的服务进行迁移。在迁移的过程中，需要至少对services和directories目录进行备份。根据迁移前后的情况配置情况，分别进行不同的设置。
最为简单的迁移模式，迁移前后的Server的用户名和密码保持一致，arcgsiserver的物理位置一致，数据的存储不变，将备份的services目录和directories目录覆盖到对应的目录下，重新启动服务即可。
如迁移前后arcgisserver的物理位置发生变化，在上面的基础上，去config-store的services目录下，找到服务的配置文件，修改msd的路径，指向新的路径。
如数据源发生变化，则需要通过ArcMap或者Arcpy修复服务器端的MXD文档，然后使用arcpy生成msd，覆盖旧的msd文件，重启服务即可。