To help make your data accessible to the server, ArcGIS Server can automatically place a copy of a service's source data on the server at the time you publish the service. This ensures that the item you published (for example, a map document) will have no trouble seeing and accessing its source dataset.
Copying data to the server can be useful when publishing to a server in which you do not have login rights or you are behind a firewall. It can also help you keep your internally edited datasets separate from the ones you place on the server. Before copying your data to the server, examine the following scenarios and consider how your workflows relate.
If the data you want to copy to the server does not require an enterprise geodatabase
If the data you want to copy to the server does not require an enterprise geodatabase, ignore the data source is not registered with the server and data will be copied to the server warning 
in the Prepare window (or mark it as an exception) and then publish the service. Your data is automatically copied to the server. No further action is required on your part. Note that all of the contents of a folder registered with the server will be copied except sub-folders within the registered folder.
When to use automatic data copying when working with a cloud-based server
Copying data to the server can be convenient when your ArcGIS Server site is running in a cloud environment like ArcGIS Server on Amazon Web Services and you cannot or do not want to log on to the cloud machine. In the cloud, the server needs its own copy of the data because it would be inefficient and in some cases impossible for it to retrieve the data from your machines on premises. This method of copying the data is convenient; however, if you publish many services that use the same datasets, it can cause duplicate data to accumulate on the server.
When to use automatic data copying when working with an on-premises server
If you don't have login rights to your on-premises ArcGIS Server, automatic data copying can allow you to still be successful at publishing services.
You also might decide to copy the data in this manner if you want to publish a snapshot of your dataset. For example, suppose that you have a working geodatabase that is constantly being modified by dozens of editors. Every month, this data goes through a quality assurance process to make sure that it meets your organization's data integrity standards. You want to publish the data only if you know it has met the standards.
After quality checking your data, you can publish and have the data copied to the server. This ensures that your web users see the quality-checked data while allowing your editors to continue making changes to your working geodatabase each day. Every month, following the quality assurance process, you can republish the copy of the geodatabase on the server by overwriting the service.
Copying data to the server also allows you to use separate scaling architectures for your working geodatabase and your web geodatabase. For example, you can add more servers or backup servers to your web deployment without affecting your working geodatabase.
If the service type you want to publish requires an enterprise geodatabase
If the service type you want to publish requires an enterprise geodatabase, you must first create an enterprise geodatabase and register it as ArcGIS Server's Managed Database. When you publish, the data referenced by your GIS resource will be copied into this enterprise geodatabase.
When to use this scenario
You'll use this scenario to publish feature services or transaction-enabled WFS (WFS-T) services. When you publish, ArcGIS Server automatically places a copy of your data in ArcGIS Server's Managed Database, since these service types explicitly require an enterprise geodatabase. ArcGIS Server's Managed Database can only be used with feature or WFS-T services, along with any capabilities concurrently published with these service types. For example, you can publish a feature service with the KML capability enabled, but you cannot solely publish a KML service to ArcGIS Server's Managed Database. Only one geodatabase can be registered to fill this role and you cannot synchronize changes between ArcGIS Server's Managed Database and your on-premises data.
This scenario can also be used when your ArcGIS Server site is running in a cloud environment like ArcGIS Server on Amazon Web Services. For example, the cloud server needs its own copy of the data because it would be inefficient and in some cases impossible for the feature or WFS-T service to retrieve the data from your machine on premises. In this case, you avoid having to log in to the cloud machine, since the data is automatically copied to ArcGIS Server's Managed Database when publishing.
Once published, you and your users should only work with the data exposed by the feature or WFS-T service. If you want to update the data in ArcGIS Server's Managed Database, you can add the feature or WFS-T service in ArcMap and use the local editing commands to upload the new data. Additionally, you'll need to overwrite your service before clients can see the changes on the web.
Each service that you publish contains its own private copy of the data in ArcGIS Server's Managed Database. If you publish another service that uses the same datasets on premises, you will have two copies of the same dataset in your database.
The lifetime of the data in ArcGIS Server's Managed Database is directly controlled by the lifetime of the service. For example, if you delete the service, the data it references in ArcGIS Server's Managed Database will be deleted. If you want to save your data before deleting the service, you can use the tools in ArcGIS for Desktop to export the enterprise geodatabase data into a file geodatabase that you can transfer to your local machine.
When using this scenario, keep in mind the following:
- You must explicitly create ArcGIS Server's Managed Database before registering it with the server.
- ArcGIS Server's Managed Database must be an enterprise geodatabase (file and personal geodatabases are not permitted).
- The database must exist on the server or a machine visible to the server.
- Registering an empty geodatabase is permitted.
- The data in the feature service or WFS-T service you want to publish can originate from anywhere (a shapefile, a file geodatabase, and so on).
- Deleting the service deletes the service's data.
- Whenever you update your data on premises, you must do an overwrite of the dataset in ArcGIS Server's Managed Database in order for the server to reflect the changes.
Do not use this scenario
- If you want to publish a service type other than a feature or WFS-T service.
- If your data already resides in an enterprise geodatabase.
- If you want to publish database tables accessed through an OLE DB connection file (.odc)
- If you want to synchronize changes between the publisher's machine and ArcGIS Server's Managed Database.
Best practices for data copying
Large copy jobs may take several hours or longer to complete. Clients can continue to use other services on your server while copying occurs.
To avoid copying an excessive amount of data, a best practice is to keep the full extent of your data frame no larger than necessary. For example, if you have a dataset that covers the world, but your map service only needs to be used in a single country, set a custom full extent on your data frame to enclose just the country of interest. For full instructions, see Setting a custom full extent for your Data Frame.
Similarly, examine whether there are any nonessential layers in your map service that could be removed before you copy. For services with an enormous amount of source data, you might choose to manually move the data to the server to avoid duplicating data.
Whenever copying data to the server, ensure that the server machine has enough available disk space to receive the copy. This space may be larger than you anticipate if you fail to account for the size of all the layers in the service at the full extent of the service.
Copying OLE DB data sources
OLE DB connections provide uniform access to data from a variety of sources, but are nonspatial connections. If your data originates from database tables accessed through an OLE DB connection file (.odc), the OLE DB data sources are copied to the server and converted to file geodatabase tables.
Datasets that cannot be copied
Some types of data cannot be copied to the server as part of the publishing process. These include selection layers, custom layers, video layers, and tool layers.
Disabling data copying
If you're an ArcGIS Server administrator and you want to prevent publishers from automatically copying data to the server when they publish, you can disable data copying using the ArcGIS Server Administrator Directory. For full instuctions, see Disabling automatic data copying when publishing to the server.