The best practice to transfer the ArcGIS Server data from one machine to another,
In case of failure, what might be the best practice to transfer the ArcGIS Server data (published services including the cached) from one machine to another? I’m aware that the ArcGIS Server is housed in arcgisserver by default in the C:\ drive. Is all what I need is to install the ArcGIS Server in the destination machine and just replacing the new arcgisserver with the old one? Does the ArcGIS Server recognize the published services of old machines in the new one right away?
The ArcGIS preserves a copy of the mxd in the folder below
C:\arcgisserver\directories\arcgissystem\arcgisinput\XXXX\extracted\v101
Thank you
Best
Jamal
Jamal,
Other than normal IT/network best practices for backup and restore of servers, I don't know that you would want to backup the caches, data, etc with any tools that are available with server....the backups could potentially be so big they are not practical. It think some of that should be done, again, as a server admin task, not as an ArcGIS Server task.
With that said, there is a topic about backing up the config etc.
As JQuinn-esristaff mentioned, you might run into other problems if trying to restore on a machine with a different name or a different configuration. However, I think with a combination of the config backup, a IT/server backup and possibly the tools of transferring from another machine (assuming there is one running that is working), you could probably get things to run.
I don't think you will find a simple, one-button solution to what you are asking. But if you have a backup of the cache, it is not hard to restore that and get it to work. We create all our cahes on a EDN licensed development machine. We create (or I might now use the transfer service tool) the service on production, and I can just copy the cache over and turn the "cache" option on. Works just find. Not a simple backup and restore, but a simple copy and turn-on. For what it's worth.
Jamal, it is definitely possible to take a backup of a machine using the exportSite resource within the Server Admin API or the tool Rebecca Strauch, GISP mentioned and then restore the backup using the importSite resource within the Server Admin API or again, the tool described. This will restore the site to it's original state when the backup was taken. Take note of what's not included when backing up a site, (cache, your own data, etc), which means those items won't be restored by Server, so it's up to you to make sure those things are in order. The backup/restore utilities were not designed for "cloning" or "migration", meaning moving from one machine to another. Many organizations use a combination of ArcGIS Server tools, (backup/restore methods discussed above), file system backup tools, database backup tools, and VM backup tools, (ex snapshots), to guard against data loss and downtime.
Thank you so much Jonathan Quinn, your suggestion is very helpful, but unfortunately, I observed the following:
2. Most of the services are stopped, and if we restart them manually, we will get the error attached. (overwrite publish will resolve the issue)(attached)
Best,
Majdoleen
Did you restore the backup to the same machine that you took the backup from? I assume the version is the same between the source and the target as well? Can you publish a new image service with the same data?
Hi Jonathan Quinn,
I tried to restore the backup to different machine.
Yes, we can publish a new image service with the same data, and as I mentioned before, the overwrite publish resolved my issue.
What do you think?
Thank you
Best,
Majdoleen
Backup/restore is not meant to move data, services, or configurations between machines. If you need to move services from one machine to another, you can go through the following:
1) Move the config-store and directories to a shared location using the Admin API
2) Install Server on the new machine
3) Join the new Server to the existing site
4) Remove the old machine from the site.
5) Set the config-store and directories back to a local drive on the machine or wherever they were initially.
Thank you Jonathan Quinn ,
In case of formatting my server, do you suggest that we need to use (export/ import Site), and set the config-store and directories to the network folder for example? And in case of caching folder, for sure we need to copy the cache.
But despite the fact the we didn’t move the config-store and directories when using import site on the second server, most of the services are returned to work.
What do you think?
Best,
Majdoleen
Jonathan -
Since using ArcGIS Server Manager or the Admin API can take hours (I just recently had it take a full weekend over the 4th holiday to move my config store and server directories), I am wondering is Esri is working on a better approach? Think about it, there are technologies, that if Server worked with them better, could speed up this process. Robocopy can be used in Windows for example, and then a direct way to edit the underlying configuration files would be a huge time saver for the user community. I have been recommending this since 10.1 but it doesn't seem to ever get any traction. I am not suggesting ArcGIS Server admins do something unsupported by Esri, instead I am just asking Esri to think outside the box as it were. I know because I have done this in a development environment that there are unsupported ways to do this faster.
Joe
Just dawned on me why the Manger and API have to do this work for the users, there are too many underlying files underneath the Services that that have the path in them in the configure-store and ArcGIS server directories. All the json and xml files need to be updated.
Still a utility to make this work go faster would be great.
Majdoleen Awadallah, the problem with export/import is that it was never designed to work as a migration tool. You can give it a try and it may work for you, but take note that it's not something we test internally so there may be unforeseen side effects. The workflow I outlined is using processes already well in use for an ArcGIS Server site, (moving directories, joining, unjoining).
Joe Weyl, migration is something we're focusing on for future releases. We realize there are a lot of times things that are currently hard coded within the software can change, (machine names, URLs, etc), so we are discussing designs for what the user experience will be like for those workflows.