GCP FileStore Backup for Kubernetes Persistent Volume Data on GKE Clusters

Home BlogGCP FileStore Backup for Kubernetes Persistent Volume Data on GKE Clusters

Google Cloud Provider (GCP) Filestore is a good place to keep lots of rich, unstructured data, such as graphic designs, video editing files, and other media workflows that use files as input and output. Having GCP Filestore backups enables users to protect themselves against the rare case of inaccessibility, accidental changes, ransomware attacks, or other types of disasters. For those using GCP FileStore as Persistent Volumes on GKE (Google Kubernetes Engine) clusters, they can now back up, restore and migrate them using CloudCasa.

In this blog we cover how to backup GCP Filestore and recover Kubernetes Persistent Volume data for pods deployed in GKE clusters.

What is GCP FileStore and why do we need GCP Filestore backups?

The GCP Filestores are fully managed Network File System (NFS) volumes on GCP for use with Google Compute Engine and GKE instances. They provide simple, fast, consistent, scalable, and easy to use network-attached storage.

Filestore meets the needs of the most demanding applications storing mission critical data. That’s why it is important to have these Kubernetes Persistent Volume backups. A few common use cases for GCP filestore backups are:

  • Protection against any accidental changes
  • Migration of the namespaces or data to another cluster because after you create a Filestore instance, you cannot change its location or service tier
  • Development and testing purpose

CloudCasa is an ideal solution to easily manage GCP Filestore backup and disaster recovery policies for your Kubernetes PVs in GKE with these quick and easy steps.

Creating a GCP Filestore Instance

Filestore CSI driver is the primary way to use Filestore instances with GKE because it provides a complete data management experience like use of volume snapshots and volume expansion to allows users to resize a volume’s capacity.

For provisioning you can also use existing Filestore instances by using pre-provisioned Filestore instances in Kubernetes workloads, or you can dynamically create Filestore instances and use them in Kubernetes workloads with a Storage Class or a Deployment.

In this example we have provisioned the filestore using the Filestore CSI driver.

Task to be performed on GKE Cluster

Ensure you have enabled the following on the GKE cluster:

  • Cloud Filestore API
  • Filestore CSI driver

To access a volume using the Filestore CSI driver, the following three steps must be performed on the cluster:

  1. Create StorageClass

Storage Classes are used for provisioning Filestore instances. Ensure the Storage Class uses the Filestore CSI driver by adding “filestore.csi.storage.gke.io” in the provisioner field. The below steps are performed under a namespace “gkefs”.

GCP Filestore backup figure 1
Figure 1: Description of the Storage Class

2. Use a PersistentVolumeClaim to access the volume

Create a PersistentVolumeClaim resource that references the Storage class created in Step1.

Fig 2 Description of PVC
Figure 2: Description of the Persistent Volume Claim
Fig 3 Description of the PV consumed by pod
Figure 3 : Description of the Persistent Volume consumed by pod

3. Create a deployment that consumes the volume

Create a web-server deployment which consumes the PV resource that was created.

Fig 5 Description of the web server deployment
Figure 4: Description of the web server deployment

GCP Filestore Backup on GKE Cluster

Now for configuring a backup of your new Filestore PV. In the CloudCasa UI, we create a backup job selecting the namespace “gkefs” and execute the job. If the user chooses to perform a copy action for the namespace, which will back up the data to external object storage, it can be selected in CloudCasa by choosing the “Snapchat and Copy” option when defining the backup job.

fig 5.1 Backup or Copy Job definition in CC
Figure 5: Backup or Copy Job definition in CloudCasa

On completion of the GCP Filestore backup job, one can view the “Activity tab” for additional details regarding the job.

Fig 6 Job Activity details
Figure 6: Job Activity details

The below screenshot shows the list of the backed-up Persistent volumes after a backup job has been executed.

Fig 7 Backed up PV details
Figure 7: Backed up PV details

Restore of Kubernetes Persistent Volume Backup on GKE cluster

Now that we have a backup that includes the GCP Filestore PV, the next step is to perform a restore. In this blog, we will demonstrate 2 ways of restoring.

Restore Operation 1

The following steps walk you through defining a restore job to restore the backed-up namespace to a new namespace (remember that we backed up the gkefs namespace).

Fig 8 Namesapce is listed on the GKE cluster before restore
Figure 8: Namespace is listed on the GKE cluster before restore

In the CloudCasa UI, choose the Restore option and then select the Recovery Point created from the backup taken earlier.

Fig 9 Restore Job Definition
Figure 9: Restore Job Definition
Fig 10 Restore Job definition selecting the namespace to be restored
Figure 10: Restore Job definition selecting the namespace to be restored

Choose the option to “Rename namespaces” in your restore job. A user can then add a prefix or a suffix to rename the restored namespace.

Fig 11 Restore Job definition to restore to new namespace
Figure 11: Restore Job definition to restore to new namespace

Once the restore job is executed the “Activity log” tab displays the execution logs and status as follows:

Fig 12 Restore Job Activity log
Figure 12: Restore Job Activity log

Users can also see the new restored namespace with the PVC, PV and the Pod in the GKE cluster using the kubectl CLI as shown in Figure 13.

Fig 13 New restored namesapce with the PVC PV and the Pod
Figure 13: New restored namespace with the PVC, PV and the Pod

Restore Operation 2

CloudCasa also supports disaster recovery of a GCP Filestore, when the namespace and its components get deleted. For example, if the namespace “gkefs” is deleted from the cluster as shown in Figure 12, the Restore operation for the deleted namespace can be performed with similar steps as described above.

Fig 14 gkefs deletion namesapce listing before restore
Figure 14: “gkefs” deletion and Namespace listing before restore

Define the restore job, by select the appropriate recovery point and select the namespace(s) to be recovered. In the Destination section do not select “Rename namespace” option. Then save and run the job.

Once the restore is successfully executed, the user can validate the namespace and its components on the GKE cluster. The below screenshot (Figure 15) shows the deleted namespace “gkefs” has been restored with all its components.

Fig 15 Deleted namespace gkefs restored with all its components
Figure 15: Deleted namespace “gkefs” restored with all its components

Note that it might take a while for Filestore instances to complete provisioning. Before that, deployments will not report a READY status. You can check the progress by monitoring your PVC status. You should see the PVC reach a BOUND status when the volume provisioning is complete.

It’s important to note that you can also automatically create a new cluster by performing a restore from a copy backup in either the same or in a different cloud.

And that is how easy it is to use CloudCasa to manage data protection and disaster recovery for GKE and GCP Filestore persistent volumes!

Learn more about the GCP Filestore Backup with CloudCasa by Catalogic.

You can try the free service plan for CloudCasa, no strings attached. We’d be happy to connect with you over a call and talk through your issues in Kubernetes Persistent Volume backup for GCP Filestore. If you want to see a custom demonstration or just have a chat with us, feel free to get in contact via casa@cloudcasa.io.