Globus is a research data management service, best known for its file transfer capability, that lets researchers and institutions move large datasets reliably between computers, storage systems, and high-performance computing (HPC) facilities without babysitting the transfer or writing custom scripts. It grew out of grid-computing research at Argonne National Laboratory in the late 1990s, led by Ian Foster and collaborators, and is now operated as a nonprofit service by the University of Chicago, with continued support from the U.S. Department of Energy, the National Science Foundation, and Argonne. It is one of the most widely used pieces of shared research-computing infrastructure in the United States, deployed at national laboratories, supercomputing centers, and hundreds of universities.
What Globus data transfer actually does
At its core, Globus solves a problem that plain file-copy tools handle badly at scale: moving datasets that run to hundreds of gigabytes, terabytes, or petabytes, often between institutions with different storage systems, network paths, and security policies. Rather than a single client-to-server copy, Globus coordinates a “third-party transfer” between two endpoints – named, registered storage locations – while the transfer itself runs on managed data-transfer nodes rather than the user’s own machine. A researcher can start a transfer from a laptop browser tab, close the laptop, and the transfer keeps running on the infrastructure at both ends.
The underlying transport is built on GridFTP, a high-performance, parallel data-transfer protocol also developed at Argonne, which uses multiple simultaneous data streams per file and multiple concurrent file transfers to make full use of high-bandwidth research and education networks (such as Internet2 and ESnet) in a way a single-stream protocol like plain FTP, SCP, or HTTP typically cannot.
How a transfer works, step by step
- Endpoints are registered. A storage system – a lab server, an HPC cluster’s parallel file system, an institutional repository, or a cloud bucket – is made addressable to Globus via Globus Connect Server (for shared, managed systems run by IT staff) or Globus Connect Personal (a lightweight client individual researchers install on a laptop or desktop).
- The user authenticates to both the source and destination endpoint, typically through their home institution’s identity provider via federated login (Globus supports InCommon/eduGAIN-style federated authentication as well as its own accounts), rather than juggling separate credentials per system.
- The transfer is submitted through the Globus web app, a command-line interface, or the Globus SDK/API, specifying source path, destination path, and any transfer options.
- Globus manages the transfer on managed infrastructure: it splits large files, parallelizes across multiple streams, retries automatically on network interruption, and verifies data integrity with checksums after the transfer completes – flagging or re-transferring anything that doesn’t match rather than silently delivering a corrupted copy.
- The user gets notified by email or in the activity dashboard once the transfer finishes, succeeds, or needs attention, without needing to keep a terminal session open for the duration.
Why research institutions rely on it rather than plain copy tools
For research administrators and data stewards, the appeal isn’t raw speed alone – it’s reliability and auditability at the scale genomics, imaging, climate, and physics datasets now routinely reach. A multi-day transfer of a large imaging or sequencing dataset over a plain scp or rsync session that drops halfway through often has to restart from scratch, or requires a researcher to script around resumability themselves. Globus is designed to survive exactly that failure mode: transfers automatically resume after a dropped connection, network hiccup, or endpoint restart, and Globus itself monitors progress and retries rather than requiring the user to notice a stalled job.
This matters directly for compliance with funder data management plans (DMPs): a DMP that commits to depositing data in a named repository or institutional repository within a given timeframe is only as credible as the mechanism actually used to move the data there. Institutions frequently list Globus as the supported route for moving data from an HPC allocation or lab instrument into a certified repository, precisely because it produces a reliable, checksummed, loggable transfer rather than an ad hoc copy a researcher may or may not complete correctly.
Key features relevant to research data management
- Fault tolerance and automatic retry – transfers resume after network failures without manual intervention, up to a bounded retry window (inactive transfers eventually expire and must be resubmitted).
- Checksum verification – data integrity is verified after transfer, not assumed, which matters for datasets going into a repository that will itself be checked against fixity requirements (see CoreTrustSeal-certified repository criteria).
- High-performance parallel transfer – multiple concurrent streams make effective use of high-bandwidth research networks, which is the practical reason Globus routinely outperforms single-stream tools for very large datasets.
- Sharing without a full account for the recipient – a Globus endpoint owner can share a specific folder with an external collaborator, who can access or pull data without needing local storage credentials at the source institution.
- Automation and workflows – Globus Flows and the Globus CLI/SDK let institutions script recurring transfers (e.g., moving instrument output from an HPC scratch filesystem into long-term storage on a schedule) rather than relying on a person to run each transfer manually.
- Federated identity – login via a home institution’s existing credentials, avoiding a separate password for every storage system a researcher needs to reach.
Access and cost model
Individual researchers can install Globus Connect Personal and use the core transfer service, including access to endpoints at non-profit institutions, at no cost. Institutions that want to run a managed, shared endpoint – so an entire lab, department, or HPC facility can be reached without each researcher installing Personal on individual machines – typically do so through Globus Connect Server under a subscription, which also unlocks features like managing group access, higher transfer concurrency, and integration with institutional identity systems. Pricing and subscription tiers are set directly by Globus (operated by the University of Chicago) and should be checked on globus.org rather than assumed, since terms change; what’s stable is the underlying split – free for individual/non-profit use of the core service, paid subscription for institutional endpoint hosting and advanced management features.
Where Globus fits in the research data lifecycle
Globus is a transport layer, not a repository or a preservation system in itself – it moves data, it doesn’t provide long-term custody, versioning, or the organizational commitments a certified repository makes (see re3data for how repositories are catalogued and compared, or CoreTrustSeal for what certification actually verifies). In practice it sits at several points in the data management plan lifecycle: moving raw instrument or simulation output from an HPC allocation into working storage during a project, transferring processed datasets between collaborating institutions, and finally moving a finished dataset into a repository at project close-out to satisfy sharing and preservation commitments. Because it logs transfers and verifies integrity, it also produces a practical audit trail an institution can point to when demonstrating that a DMP’s sharing timeline was actually met.
Globus compared to simpler transfer methods
For a handful of small files, plain scp, cloud-provider upload tools, or emailing an attachment remain perfectly adequate, and Globus is unnecessary overhead for that scale. The gap opens as size and reliability requirements grow: single-stream protocols (FTP, SCP, HTTP upload) don’t parallelize well over long-haul, high-bandwidth research network paths, don’t automatically resume after failure, and put integrity verification entirely on the user. Institutions that regularly move datasets in the tens of gigabytes and up – genomics cores, imaging facilities, climate and physics simulation groups – generally standardize on Globus (or an equivalent GridFTP-based service) specifically to avoid failed, un-verified, or silently corrupted large transfers becoming a recurring support burden.
Frequently asked questions
Is Globus free to use for research data transfer?
The core transfer service is free for individual researchers via Globus Connect Personal, including transfers between non-profit institutions’ endpoints. Institutions hosting a shared, managed endpoint (Globus Connect Server) for a lab, department, or facility typically do so under a paid subscription that adds group-management and higher-concurrency features. Current pricing should be confirmed directly on globus.org.
What is a Globus endpoint?
An endpoint is a registered, addressable storage location – a server, HPC file system, institutional repository, or cloud storage bucket – that Globus can transfer data to or from. Endpoints are set up via Globus Connect Server (managed, shared systems) or Globus Connect Personal (an individual researcher’s own machine).
Does Globus support transfers to and from cloud storage and HPC systems?
Yes. Globus endpoints can be configured for on-premises HPC file systems, institutional storage, and major cloud storage providers, which is part of why it’s commonly used as the connective layer between a national lab’s compute allocation, a university’s storage, and a public data repository.
How is Globus different from plain FTP or SCP?
Globus transfers run on managed infrastructure rather than the user’s own session, use GridFTP’s parallel-stream transport for higher throughput on research networks, automatically retry after failures, and verify integrity with checksums after completion – none of which plain FTP, SCP, or a manual cloud upload does by default.
Do I need to keep my computer on for a Globus transfer to complete?
No. Once a transfer is submitted, it runs on the data-transfer nodes at the source and destination endpoints rather than on the user’s own machine, so it continues even if the initiating laptop or desktop is closed or disconnected.
