Backups stored on Google Shared Drive not pruned.

[bitboss-ca]

Describe the bug
Backups stored on Google Shared Drive not pruned.

To Reproduce
Steps to reproduce the behavior:

  backup:
    container_name: container-backup
    image: offen/docker-volume-backup:latest
    restart: always
    env_file: ./backup.env
    volumes:
      - db_data:/backup/my-app-backup:ro
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./gdrive-credentials.json:/creds/google-credentials.json
    networks:
      - backend
    security_opt:
      - no-new-privileges:true

BACKUP_CRON_EXPRESSION="25 04 * * *"
BACKUP_FILENAME="backup-vol-container-db-%Y%m%d-%H%M%S.{{ .Extension }}"
GOOGLE_DRIVE_CREDENTIALS_JSON_FILE=/creds/google-credentials.json
GOOGLE_DRIVE_FOLDER_ID="[...SNIP...]"
GOOGLE_DRIVE_IMPERSONATE_SUBJECT="[...SNIP...]"
BACKUP_RETENTION_DAYS="14"
BACKUP_PRUNING_PREFIX="backup-vol-container-db-"
BACKUP_STOP_DURING_BACKUP_LABEL="container"
NOTIFICATION_URLS="s[...SNIP...]"

Expected behavior
Backups pruned after 14 days

Actual Behaviour
Note: there are definitely more than 0 backups in Google Drive and many are older than 14 days.

time=2026-05-02T17:40:31.177-07:00 level=WARN msg="Deprecated timezone bind mounts detected: /etc/timezone, /etc/localtime. Support for these will be removed in a future version."
time=2026-05-02T17:40:31.177-07:00 level=WARN msg="Set the container timezone using the `TZ` environment variable instead."
time=2026-05-02T17:40:31.177-07:00 level=WARN msg="Refer to the documentation for migration details."
time=2026-05-02T17:40:31.211-07:00 level=INFO msg="Stopping 1 out of 65 running container(s) as they were labeled docker-volume-backup.stop-during-backup=container or docker-volume-backup.stop-during-backup-no-restart=true."
time=2026-05-02T17:40:32.313-07:00 level=INFO msg="Created backup of `/backup` at `/tmp/backup-vol-container-db-20260502-174031.tar.gz`."
time=2026-05-02T17:40:32.508-07:00 level=INFO msg="Restarted 1 out of 1 stopped container(s)."
time=2026-05-02T17:40:32.514-07:00 level=INFO msg="Starting upload for backup 'backup-vol-container-db-20260502-174031.tar.gz'." storage=GoogleDrive
time=2026-05-02T17:40:35.179-07:00 level=INFO msg="Finished upload for backup-vol-container-db-20260502-174031.tar.gz. File ID: [...SNIP...]]" storage=GoogleDrive
time=2026-05-02T17:40:35.267-07:00 level=INFO msg="None of 0 existing backups were pruned." storage=GoogleDrive
time=2026-05-02T17:40:35.276-07:00 level=INFO msg="Removed tar file `/tmp/backup-vol-container-db-20260502-174031.tar.gz`."

Version (please complete the following information):

• Image Version: latest - i.e. 2.48.0
• Docker Version: 29.1.3
• Docker Compose Version (if applicable): 2.40.3

Additional context

[m90]

Do you happen to know if this behavior was introduced in a recent version, i.e. does it start working when you downgrade or does this happen with all versions?

[bitboss-ca]

As far as I know, just this version because I'm a fairly new user, but I just tested v2.47.2, v2.46.1 and v2.44.1 - same result.

[m90]

The issue must be that this portion of code

docker-volume-backup/internal/storage/googledrive/googledrive.go

Lines 133 to 163 in c6fa7fc

	var allFiles []*drive.File
	pageToken := ""
	for {
	req := b.client.Files.List().Q(query).SupportsAllDrives(true).Fields("files(id, name, createdTime, parents)").PageToken(pageToken)
	res, err := req.Do()
	if err != nil {
	return nil, errwrap.Wrap(err, "listing files")
	}
	allFiles = append(allFiles, res.Files...)
	pageToken = res.NextPageToken
	if pageToken == "" {
	break
	}
	}
	var matches []*drive.File
	var lenCandidates int
	for _, f := range allFiles {
	if !strings.HasPrefix(f.Name, pruningPrefix) {
	continue
	}
	lenCandidates++
	created, err := time.Parse(time.RFC3339, f.CreatedTime)
	if err != nil {
	b.Log(storage.LogLevelWarning, b.Name(), "Could not parse time for backup %s: %v", f.Name, err)
	continue
	}
	if created.Before(deadline) {
	matches = append(matches, f)
	}
	}

returns 0 candidates in your case and the following procedure thinks there is nothing to do.

For debugging, could you try not using the BACKUP_PRUNING_PREFIX setting (in case that's possible for you) and see if it makes a difference?

[bitboss-ca]

Not using a prefix produces the same result:

env

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=[...SNIP...]
TERM=xterm
BACKUP_FILENAME=backup-vol-container-db-%Y%m%d-%H%M%S.{{ .Extension }}
GOOGLE_DRIVE_CREDENTIALS_JSON_FILE=[...SNIP...]
GOOGLE_DRIVE_FOLDER_ID=[...snip...]
GOOGLE_DRIVE_IMPERSONATE_SUBJECT=[...SNIP...]
BACKUP_STOP_DURING_BACKUP_LABEL=[...SNIP...]
NOTIFICATION_URLS=[...SNIP...]
BACKUP_CRON_EXPRESSION=25 04 * * *
HOME=/root

output

level=INFO msg="None of 0 existing backups were pruned." storage=GoogleDrive

[m90]

Thanks for all the info. Unfortunately, I just recently deleted my Google Account, so I cannot really test this easily, but I'll see if I can make any sense of what's happening in your scenario.

[m90]

If anyone else using Google Drive storage could chime in and confirm they are seeing the same behavior or not, that'd be very helpful.

[m90]

@bitboss-ca potentially awkward question, but you are sure there are backup archives uploaded to your Drive? Asking because of this recent comment #741 (comment)

[bitboss-ca]

100%. As a matter of fact, the backups filled up one of my Shared Drives and Google stopped me from upload to that drive due to maximum files number exceeded. I had to delete that Shared Drive and start backing up to a separate Shared Drive.

$ rclone ls GoogleDrive-Backups-DB: | head | sed -E 's/vol-(.*)-db-(.*)/vol-[container_name]-db-\2/'
 20572039 backup-vol-[container_name]-db-20260512-052000.tar.gz
 22830640 backup-vol-[container_name]-db-20260512-051500.tar.gz
267310027 backup-vol-[container_name]-db-20260512-050500.tar.gz
 14738886 backup-vol-[container_name]-db-20260512-045500.tar.gz
126482035 backup-vol-[container_name]-db-20260512-045000.tar.gz
 38866215 backup-vol-[container_name]-db-20260512-044500.tar.gz
 27707046 backup-vol-[container_name]-db-20260512-044000.tar.gz
189259274 backup-vol-[container_name]-db-20260512-043500.tar.gz
 49693930 backup-vol-[container_name]-db-20260512-043000.tar.gz
 19696326 backup-vol-[container_name]-db-20260512-042500.tar.gz

$rclone ls GoogleDrive-Backups-DB: | wc -l
216

[m90]

@bitboss-ca Thanks for checking that. I did some more digging and compared the code in this repo with what rclone is doing. It seems in rclone a IncludeItemsFromAllDrives flag is set in addition:

IncludeItemsFromAllDrives sets the optional parameter "includeItemsFromAllDrives": Whether both My Drive and shared drive items should be included in results.

I have zero idea about the concepts in Google Drive, but could this description apply to your setup? Is the drive you're uploading to a shared one?

[bitboss-ca]

I see... Yes, that certainly sounds like it could apply. Yes, I am uploading backups to a Shared Drive.

But... (Long explanation):

In Google Drive, you have "My Drive" which is personal storage space owned by you, and "Shared Drives" (used to be called "Team Drives") which are shared between a group, owned by the Shared Drive itself. If you delete a user, their My Drive goes with them, Shared Drives remain.

An rclone remote config is different for a Shared Drive than a regular Google Drive remote. Notice the team_drive ID below, and that root_folder_id is blank - i.e. the root folder is the top of the Shared Drive.

[GoogleDrive-Backups-DB]
type = drive
scope = drive
token = {"access_token":"[...BLAH BLAH BLAH...]"}
team_drive = J524LHJKK52LHJK245LJKH
root_folder_id =

So to my mind, the most complete solution would be to include a flag for Shared Drive (or not) and an optional config var for the Shared Drive (team_drive) ID.

[m90]

Ok, then let me try changing it like this over the weekend, and I'll push a prerelease version which you can test your setup against afterwards.