Oracle RMAN Backups to Google Cloud Storage Using GCS FUSE #JoelKallmanDay

So as my entry for #JoelKallmanDay 2026, I thought I’d post about GCSFuse. This started as I was exploring options to write RMAN backups directly to a Google Cloud Storage (GCS) bucket.

Unlike OCI, AWS, and Azure, Oracle does not currently offer a dedicated Cloud Backup Module for GCS (at the time of writing this blog). Oracle provides RMAN-integrated backup modules for these other cloud platforms, although licensing and associated costs are also something to consider.

So, that leaves us with limited options for backing up an Oracle database using RMAN directly to a GCS bucket. Ofcourse, you once can setup a local disk based backup and then use an external utility like gcloud storage (Formerly gsutil) to then copy over the backup pieces, but that leaves us with 2 issues

1. You would need to script the process to automate it.
2. Additional steps to manage and keep the RMAN Catalog santized

Cloud Storage FUSE

Cloud Storage FUSE is an open-source tool from Google that allows us to mount a GCS bucket as a local filesystem using FUSE (Filesystem in Userspace) vis gcsfuse. It translates filesystem operations into Cloud Storage API requests. So, while the database server sees a mounted directory, the data is actually stored as objects in the GCS bucket.

Once mounted, RMAN can use it as a regular disk backup destination.

The setup is fairly straightforward, but there are a few things to watch out for, particularly how gcsfuse handles writes and the local disk space it can consume during backups.

Let’s look at the configuration and some of the things to consider when using it for RMAN backups. First for our RMAN backups, the setup looks something like this:

Oracle Database 
       |
       | RMAN DISK Channel
       v
/mnt/gcs_remote_backups
       |
       | Cloud Storage FUSE
       v
Google Cloud Storage Bucket

RMAN does not need any special configuration to understand GCS. We simply point the backup destination to the mounted GCS directory.

BACKUP DATABASE FORMAT '/mnt/gcs_remote_backups/%d_%T_%U.bkp';

However, the thing to remember here is that Cloud Storage FUSE is not a fully POSIX-compliant filesystem. Although it allows us to access the bucket using standard filesystem operations, it does not behave exactly like a local disk or an NFS filesystem and so there are a few things to be mindful about.

Mount GCS Bucket

For this example, we will use an existing GCS bucket and mount it on the GCE instance hosting the Oracle database.

Verify the GCS FUSE Installation

To install gcsfuse, follow Google’s Cloud Storage FUSE installation documentation for your Linux distribution, and verify the installation.

gcsfuse --version

Create the Mount Point

Create a directory where we will mount the GCS bucket. Since RMAN runs as the Oracle software owner, we need to ensure the user can access the mount, so check the UID & GUID for the user. We will use these values while mounting the bucket.

mkdir -p /mnt/gcs_remote_backups ; id oracle

## Assuming
uid=54321(oracle) gid=54321(oinstall)

Configure Authentication

GCSFuse requires credentials with the necessary permissions on the GCS bucket. To authenticate you can use a JSON key, associated with the account. We can specify the JSON key using the GOOGLE_APPLICATION_CREDENTIALS environment variable when executing gcsfuse.

Also, the account needs the necessary permissions on the bucket. Google documents roles/storage.objectUser as a predefined role containing the permissions required for read/write access through a FUSE mount.

Step 4: Mount the GCS Bucket

Let’s mount the bucket.

GOOGLE_APPLICATION_CREDENTIALS=/home/oracle/scripts/rman/config/rman-backups.json gcsfuse --temp-dir /u01/software/test --dir-mode 750 --file-mode 640 --uid 54321 --gid 54321 -o rw -o noexec -o nodev -o nosuid -o allow_other --log-file /home/oracle/scripts/rman/config/gcsfuse_bucket.log oracle-rman-backups /mnt/gcs_remote_backups

There are a few parameters worth explaining.

Make sure the temporary directory and log directory already exist and that the mounting process has the required permissions.

A small thing to remember: Unlike gcloud storage or gsutil, gcsfuse expects the bucket name without the gs:// prefix.

Verify the Mount

Once mounted, we can verify the filesystem.Depending on the gcsfuse version, the output may look something like this:

df -h /mnt/gcs_remote_backups

Filesystem           Size  Used Avail Use% Mounted on
oracle-rman-backups   1.0P     0  1.0P   0% /mnt/gcs_remote_backups

Now, don’t mistake the reported 1.0P capacity for available local disk space. This is a FUSE representation of object storage, and it tells us nothing about the available space in the temporary filesystem. Before configuring RMAN, let’s also check whether the Oracle user can write to the mount.

sudo -u oracle touch /mnt/gcs_remote_backups/gcsfuse_test.txt

Verify that the object exists in the bucket.

gcloud storage ls gs://oracle-rman-backups/gcsfuse_test.txt

This should confirm that the Oracle user can create and remove files through the FUSE mount.

Configuring RMAN Backups

With the mount available, we can now configure RMAN to write backup pieces directly to the mounted directory. I would start by backing up the SPFILE or controlfile before attempting a full database backup.

BACKUP SPFILE FORMAT '/mnt/gcs_remote_backups/spfile_%d_%T_%U.bkp';

Once these complete, verify that the backup pieces are available in the bucket. We can then proceed with setting our database backups.

BACKUP AS BACKUPSET DATABASE FORMAT '/mnt/gcs_remote_backups/db_%d_%T_%U.bkp' TAG 'GCS_DATABASE_BACKUP';

GCS FUSE and Local Disk Space Consumption

Now, there is one thing about gcsfuse that needs special attention when we start writing larger backup pieces.

Even though RMAN writes to a GCS bucket, the backup operation may still consume local filesystem space.

This depends on how gcsfuse handles writes. With traditional staged writes, gcsfuse writes data to a temporary file on the local filesystem “Temp_Dir” before uploading the completed object to Cloud Storage. The process looks something like this:

RMAN Backup Piece
       |
       v
GCS FUSE Mount
       |
       v
Local Temporary File
       |
       v
GCS Bucket

Remember the following parameter from our mount command?

--temp-dir /u01/software/test

This tells gcsfuse where to create temporary files when local staging is required. Let’s assume that the /u01 filesystem has 30 GB of free space and RMAN starts writing a backup piece of 50 GB. If gcsfuse needs to stage the entire backup piece locally, the filesystem will run out of space before the upload can complete.

Meanwhile, the GCS mount may still report plenty of available space.

For example:

Filesystem                  Size    Used    Avail
/mnt/gcs_remote_backups     1.0P       0     1.0P
/u01                        100G    100G        0

So, although our backup destination is GCS, the failure occurs because the local temporary filesystem does not have sufficient space.

The other thing to factor in are the

RMAN Channels & Backup piece Size

You should also test with the number of channels, as that determines the concurrent temporary staging space required. Suppose we have four RMAN channels configured.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

Now, let’s assume each channel creates a backup piece of 50 GB. If gcsfuse is staging complete backup pieces locally, we could potentially have around 200 GB of temporary data being written concurrently. The actual space requirement depends on the number of active channels, the backup piece sizes, and the write behavior.

One way to control the maximum size of individual backup pieces is by configuring MAXPIECESIZE.

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 32G;

With this configuration, RMAN will limit individual backup pieces to 32 GB. Therefore, I would consider the number of RMAN channels and the maximum backup piece size together when sizing the temporary filesystem.

GCSFuse Streaming Writes

The newer gcsfuse releases support streaming writes. Starting with Cloud Storage FUSE 3.0, streaming writes are enabled by default. Instead of waiting for the entire file to be written locally, gcsfuse can upload data to Cloud Storage as the application writes it. So, the difference is:

Staged Writes:

RMAN -> Local Temporary File -> GCS


Streaming Writes:

RMAN -> GCS FUSE -> GCS

This is particularly useful when dealing with large files that are written sequentially, as is generally the case with RMAN backup pieces.

On a supported version, we can explicitly enable streaming writes.

gcsfuse --enable-streaming-writes=true --temp-dir /u01/software/test --uid 54321 --gid 54321 -o allow_other oracle-rman-backups /mnt/gcs_remote_backups

However, there is a limitation. Streaming writes are designed for sequential writes to new file which should apply to RMAN backup piece. If an application modifies an existing file or performs out-of-order writes, gcsfuse may fall back to local staging.

So, even with streaming writes enabled, I would still monitor temporary filesystem utilization during backup testing. Also, the version and platform matter. Do not assume that all gcsfuse releases support the same options or behave identically.

Unmounting the GCS Bucket

If we need to unmount the bucket, first verify that no processes are using the filesystem. Then unmount it. Verify that the mount has been removed.

fuser -vm /mnt/gcs_remote_backups

fusermount -u /mnt/gcs_remote_backups

mount | grep gcs_remote_backups

Conclusion

Cloud Storage FUSE provides a relatively simple way to write RMAN backups directly to a GCS bucket without requiring a separate process to copy the backup pieces. I would also make sure the backup scripts verify the mount before starting RMAN and that the GCS lifecycle rules are aligned with the RMAN retention policy.

And finally, test the restore. Having the backup pieces available in a GCS bucket is useful, but we still need to make sure we can recover the database when required.