This document summarizes the differences between Transfer service for on-premises data and Storage Transfer Service.
|Feature||Storage Transfer Service||Transfer for on-premises||Notes|
|Scheduling frequency||Daily||Every N hours, days, or weeks||For more frequent Transfer for on-premises transfers, you can schedule several daily jobs at your desired frequency interval. For example, for 24 daily transfers, you'd schedule 24 different daily transfers that each start on the hour. That is, midnight, 1AM, 2AM and so forth.|
|Sync||Options to overwrite objects that exist in Cloud Storage||No overwrite option||
Storage Transfer Service uses checksum metadata, when possible, to detect changes between objects in the source storage system and Cloud Storage. Transfer service for on-premises data uses the source object's last modified time and source object's size and compares those to the last modified time and size when the object was last copied to Cloud Storage.
When Storage Transfer Service detects a new or changed object on the source storage system, it copies the complete object to Cloud Storage. You can change this behavior, so that Storage Transfer Service overwrites objects with the same name that exist in Cloud Storage regardless of changed state. For more information, see TransferOptions.
When Transfer service for on-premises data detects a new or changed object on the on-premises machine, it copies the complete object to Cloud Storage. This behavior isn't changeable. To copy files that exist in Cloud Storage, either delete the corresponding objects in the destination Cloud Storage bucket, or choose a new prefix for the destination objects.
|Bandwidth control||Not supported||Supported—can set limits across all transfers in the project in MB/s increments|
|Google Cloud's operations suite monitoring||Not supported||Supported for agents only||For Cloud-to-Google Cloud, you can poll the API to get the status, speed, and so forth of your transfer jobs. For more information, see TransferJobs API description.|
|Run now||Not supported||Supported||In Cloud-to-Google Cloud transfers, to run an existing transfer now, you start by creating a new transfer job that uses identical settings as the existing transfer job, and starting it now.|
|Destination object prefix||Not supported||Supported—a fixed prefix can be prepended to all transferred destination objects in Cloud Storage.|
|Transfer logs||Not supported||Supported—you can view a record of all files copied and any errors.||For errors in Cloud-to-Google Cloud transfers you can view the error samples in Google Cloud Console.|
|Name-based source data filtering||Supported—include and exclude prefixes for source objects||Not supported||To specify a subset of files for an on-premises transfer, you create a separate staging directory with only the files you intend to transfer, and then start a transfer job with that directory as the source.|
|Modified-time source-data filtering||Supported—include source files based on last modified time||Not supported||To specify a subset of files for an on-premises transfer, you create a separate staging directory with only the files you intend to transfer, and then start a transfer job with that directory as the source.|
||Storage Transfer Admin and Storage Transfer User roles||The Cloud Console for Storage Transfer Service will not work properly if the custom role is missing required permissions. For example, some parts of the Cloud Console assume the role has read access to display an item before editing it, so a role with only write permissions will experience Cloud Console screens that don't work.|
|Delete on transfer||
||Can delete destination files no longer in source.|
|API support||Supported||Not supported — can access through GUI only.|
|Customer-defined job IDs||Supported — API users can specify their own job ID||Not supported|