If your Google Workspace backups seem slower than expected, or if performance has changed over time, the explanation almost always traces back to how Google controls API access. Google imposes strict quotas and rate limits on every API call that backup solutions make. These limits are not optional, they are not negotiable in real time, and they define the ceiling for how fast any backup product can operate against your domain.
This article explains how Google's quota system works in practice, why initial and incremental backups perform differently, where Shared Drives introduce additional constraints, how large mailboxes and Drive storage affect backup windows, how backup vendors handle throttling, and what to look for when comparing backup performance.
How Google API Quotas Work
Google's rate limiting operates at multiple levels, and understanding the hierarchy is essential for diagnosing backup performance issues.
Per-User Rate Limits
Most Google API calls are rate-limited on a per-user basis. When your backup solution impersonates a user to read their Gmail messages or Drive files, those API calls count against that specific user's quota allocation. The Gmail API, for example, enforces a per-user rate limit that caps how many messages can be read per second for any individual mailbox.
This means that no matter how powerful the backup vendor's infrastructure is, the speed at which a single user's data can be backed up has a hard ceiling set by Google. A user with a 50 GB mailbox is subject to the same per-user rate limit as a user with a 5 GB mailbox. The larger mailbox simply takes longer because there is more data to process at the same capped rate.
Per-Project Quotas
Every backup solution operates through a Google Cloud project, and each project has per-minute and per-day thresholds for each API. The Gmail API, the Drive API, and the Admin SDK each have their own per-project limits. Importantly, the daily per-project limit functions as a billing threshold rather than a hard cap: usage below the threshold incurs no additional charges, while usage above it is billed. The Drive API documentation also notes that, provided per-minute quotas are respected, there is no hard limit on the number of daily requests. These constraints together define the practical throughput ceiling for backup operations across all users in your domain.
For a small organization with 50 users, default per-project quotas are typically sufficient. For larger organizations with hundreds or thousands of users, default quotas can become a bottleneck. This is one reason why initial backups for large tenants can take days rather than hours.
Per-Minute Rate Limits
In addition to project-level quotas, Google enforces per-minute rate limits that prevent sustained high-volume API activity. Both the Gmail API and Drive API enforce per-minute-per-project and per-minute-per-user-per-project quota windows. Exceeding these limits triggers HTTP 429 (Too Many Requests) errors — and in some cases 403 (User Rate Limit Exceeded) for the Drive API — that force the backup solution to pause and retry.
Well-engineered backup solutions manage their request rate to stay just below these per-minute limits, maximizing throughput without triggering errors. Poorly engineered solutions oscillate between high-volume requests and backoffs, wasting time and quota on failed requests.
Why Initial Backups Are Slower Than Incremental
The performance difference between initial and incremental backups is dramatic, and it is entirely expected given how the APIs work.
Initial (Full) Backups
The first time a backup solution protects your Google Workspace environment, it must read every message in every Gmail mailbox, every file in every Drive and Shared Drive, and every calendar event and contact for every user. This is the most API-intensive operation the backup solution will ever perform against your domain.
For a 500-user organization where the average mailbox is 10 GB and the average Drive usage is 15 GB, the initial backup must process roughly 12.5 TB of data. At the throughput rates imposed by Google's quotas, this can take several days. The exact duration depends on your edition of Google Workspace, any custom quota increases you have obtained, and how efficiently the vendor manages API calls.
During the initial backup window, your data is only partially protected. Any data that has not yet been captured is not recoverable from the backup. This is why planning the initial backup window and understanding realistic timeframes matters.
Incremental Backups
After the initial backup completes, subsequent backup runs only need to capture data that has changed. The Gmail API provides a history-based sync mechanism that allows backup solutions to request only messages that have been added, modified, or deleted since the last sync point. The Drive API provides a changes endpoint that serves a similar purpose for file modifications.
Incremental backups are dramatically faster because they process a fraction of the data. A daily incremental backup for the same 500-user organization might process only a few gigabytes of changed data rather than 12.5 TB. API quota consumption drops proportionally.
This is also why backup frequency matters. A solution that runs incremental backups three times per day will have smaller change sets per run than one that runs once per day. Smaller change sets mean faster completion times and less API quota consumed per run.
The Catch-Up Problem
If an incremental backup fails or is delayed (due to quota exhaustion, infrastructure issues, or API errors), the next backup run must catch up on all changes since the last successful sync. This catch-up run behaves more like a partial initial backup than a normal incremental, consuming more quota and taking longer. Repeated failures can create a compounding problem where the backup falls further and further behind.
Monitor your backup solution's sync status regularly. A growing lag between the current time and the last successful backup is an early warning sign of performance issues.
Shared Drive API Limits
Shared Drives introduce additional performance considerations that do not apply to individual user backups.
Different Quota Behavior
API calls to Shared Drive content are counted differently in some contexts. While per-user limits do not apply in the same way (Shared Drives are organizational, not owned by individual users), per-project limits still apply. A domain with many large Shared Drives can consume a significant portion of the project's daily Drive API quota, leaving less capacity for individual user Drive backups.
Membership And Permission Enumeration
Backing up Shared Drives is not just about the files. Shared Drives have membership lists, permission hierarchies, and organizational settings that must also be captured for a meaningful restore. Enumerating these permissions for each Shared Drive requires additional API calls, which count against the same quotas.
Nested Folder Structures
Shared Drives used for departmental file storage often contain deeply nested folder structures with thousands of files. The Drive API handles file listing in paginated responses, requiring multiple API calls to enumerate large directories. Deep nesting can require recursive API calls that consume quota faster than flat file structures.
Large File Handling
Shared Drives frequently contain large files: videos, design assets, database exports, and CAD files. Downloading large files consumes more time and bandwidth, even if each file counts as a single API call. A Shared Drive with a few hundred large files can take longer to back up than a user's Drive with thousands of small documents.
The Impact Of Large Gmail Mailboxes
Gmail mailboxes tend to grow indefinitely since Google Workspace provides generous storage allocations and most users never delete anything. Large mailboxes present specific backup performance challenges.
Mailbox Size Distribution
In most organizations, mailbox sizes follow a long-tail distribution. The majority of users have manageable mailboxes under 10 GB, but a small percentage of power users, executives, and long-tenured employees may have mailboxes exceeding 50 GB. These outlier mailboxes consume a disproportionate share of backup time and API quota.
Attachment-Heavy Mailboxes
Messages with large attachments are more expensive to back up than plain-text messages. When using the Gmail API's messages.get method with format=FULL or format=RAW, attachment data is included in the message response. However, when using format=MINIMAL or format=METADATA, attachments must be retrieved separately via messages.attachments.get, each counting as an additional API call. Regardless of retrieval method, attachment size significantly increases data transfer time. A mailbox with 20 GB of attachments takes substantially longer to back up than a 20 GB mailbox composed primarily of text messages.
Label Complexity
Gmail's label system allows users to apply multiple labels to a single message. Backing up and restoring label assignments requires additional API calls to enumerate label structures and map messages to labels. Users with complex label hierarchies add incremental overhead to backup operations.
How Backup Vendors Handle Throttling
The way a backup vendor handles Google's rate limiting is one of the strongest indicators of their engineering maturity.
Exponential Backoff
The standard approach is exponential backoff: when the backup solution receives a 429 rate limit error, it waits a short period before retrying, doubling the wait time with each subsequent retry. This is the approach Google recommends and well-built backup solutions implement it precisely.
Intelligent Rate Management
More sophisticated vendors implement predictive rate management: they track their API call patterns and proactively throttle their own request rate to stay just below Google's limits. This avoids triggering 429 errors in the first place, which is more efficient than hitting limits and backing off.
Parallel Processing Within Limits
Since per-user limits are independent, a well-designed backup solution can back up many users simultaneously without any single user exceeding their individual quota. The constraint becomes the per-project aggregate limit. Vendors that efficiently parallelize across users while staying within project limits achieve better overall throughput.
Queue Prioritization
Some vendors implement backup queue prioritization: high-priority users or recently modified data are backed up first, ensuring the most important and most volatile data is captured early in the backup window. This does not change total backup time, but it improves the effective recovery point for critical data.
What To Watch For
Quota circumvention. Be cautious of vendors that suggest creating multiple Google Cloud projects to multiply their effective quota. While this may work temporarily, it violates the spirit of Google's quota system and may be subject to enforcement. Vendors that rely on this approach are building on an unstable foundation.
Silent failures. Some backup solutions silently skip items that fail due to quota errors rather than retrying them. This creates invisible gaps in your backup coverage. Ask your vendor how they handle persistent quota errors and whether skipped items are reported.
Lack of transparency. If a vendor cannot explain their rate limiting strategy or provide backup throughput estimates for your organization size, they may not have a mature approach to quota management.
What To Look For In Backup Performance Benchmarks
When comparing backup solutions or evaluating vendor claims, keep these practical considerations in mind.
Initial Backup Time Estimates
Ask vendors to estimate initial backup time for your specific environment: number of users, average mailbox size, average Drive usage, number and size of Shared Drives. Realistic estimates should be measured in days for organizations with hundreds of users, not hours. Any vendor claiming to fully back up a 500-user Google Workspace environment in under 24 hours on first run should be asked to explain how they achieve throughput that exceeds standard API limits.
Incremental Backup Windows
Once the initial backup is complete, incremental backup windows should be measured in hours for large organizations and minutes for small ones. Ask about the typical incremental backup window for an organization of your size and how many times per day incremental backups run.
Recovery Speed
Backup performance is only half the equation. Restore performance matters at least as much. Ask about restore times for common scenarios: single email recovery, single file recovery, full mailbox restore, and Shared Drive restore. Restore operations also use Google's APIs and are subject to the same quotas, particularly write quotas, which can be more restrictive than read quotas.
Quota Increase Assistance
Ask whether the vendor assists with Google API quota increase requests as part of their onboarding process. For large deployments, default quotas are rarely sufficient for a timely initial backup, and the quota increase request process can take several days. A vendor that proactively manages this process demonstrates operational maturity.
Practical Steps For Improving Backup Performance
While Google's API quotas set the fundamental ceiling, there are practical steps you can take to optimize backup performance within those constraints.
Request quota increases early. If you are deploying a new backup solution, request API quota increases through the Google Cloud Console before the initial backup begins. Work with your vendor to determine the appropriate quota levels for your organization size.
Schedule initial backups during low-activity periods. API quotas are shared between your backup solution and normal Google Workspace usage. Running the initial backup during off-hours reduces contention with user activity.
Clean up before backing up. Deprovisioned users, orphaned Shared Drives, and unused data consume backup time and quota. Cleaning up your environment before the initial backup reduces the total volume of data to process.
Monitor backup lag. Track the gap between the current time and the last successful backup for each user and Shared Drive. Growing lag indicates that your backup solution is falling behind, either due to quota limits, infrastructure issues, or growing data volumes.
Right-size your backup frequency. More frequent incremental backups reduce the amount of data processed per run, but they also increase the number of API calls per day. Work with your vendor to find the frequency that balances recovery point objectives with API quota consumption.
Understanding The Constraints
Google Workspace backup performance is fundamentally constrained by Google's API quota system. No vendor can circumvent these limits without risk. The differences between backup solutions come down to how efficiently they operate within those constraints: how they manage rate limiting, how they parallelize across users, how they handle errors, and how transparently they communicate realistic performance expectations.
When your backup is slower than expected, the answer is almost always API quotas. Understanding this helps you set realistic expectations, plan backup windows appropriately, and evaluate vendor claims with the right context.
BackupVerdict tests and reviews Google Workspace backup solutions with hands-on methodology. For our full reviews and comparison guides, visit backupverdict.com.