Skip to main content

Google Drive Backup Job Shows Higher Data Count than Actual Usage in Live Activity

Google Drive Backup Job Shows Higher Data Count than Actual Usage in Live Activity

Problem Description

In some cases, the Live Activity or a running backup job for Google Drive displays an unusually large Data to be backed up value (sometimes in TBs). This number often far exceeds the actual storage used in the user's Google Drive.

This behavior is commonly observed when:

  • The user has millions of files or events shared with them.

  • The Backup shared data owned by other users setting is disabled in the backup profile, yet the job still shows a massive data size and runs for an extended period.

Administrators may interpret this as "data bloating" or an integrity issue, fearing that Druva is backing up more data than intended.


Cause

This is an expected behavior caused by how the Google Drive API communicates with Druva inSync.

1. Data Calculation Logic

When a backup starts, inSync requests a list of all changed files from Google. Google returns a raw list that includes:

  • Files owned by the user.

  • All files shared with the user, regardless of Druva profile settings.

inSync calculates the initial Total data for this job by summing the size of every file in this raw list before any filters are applied. If a user has access to TBs of shared corporate data, that full amount appears in the Live Activity stats.

2. Profile Filtering

After the initial calculation, inSync processes the list. If Backup shared data owned by other users is disabled, inSync evaluates each file and skips it if the user is not the owner.

3. Processing Overhead

Even though shared files are skipped and not stored, inSync must still examine every file metadata event returned by Google to determine ownership. For users with millions of shared items, this metadata iteration causes:

  • Prolonged job runtimes (job may stay "Ongoing" for days).

  • High files_not_owned_count in backend logs.


Traceback / Logs

Look for the following message in logs to confirm skipping is active:

msg=Skipping backup of shared file. User is not the owner of superparent folder ... files_not_owned_count=...


Resolution

This behavior is by design. The large TB figure in Live Activity is a pre-filter estimate and does not represent the final data stored in Druva.

Did this answer your question?