Consider the following situation: the database of a WordPress application deployed from a store to a GCP-hosted Kubernetes cluster becomes corrupted. Causes for database corruption may vary. Often the cause may be a faulty custom plugin, but it may also happen during common administrative tasks such as data import/export. The effect is however almost always the same - your web-page is not operational until the database and data are restored.
WordPress uses a relational database to store blog articles, their related objects and metadata, and the local file system to store assets, such as pictures in a blog post. On the Kubernetes platform the container's file system is not suitable to store data due to its ephemeral nature, as a result WordPress requires Persistent Volumes to store data.
By default, WordPress requires two pods, one for the application server (wordpress-b68f79995-t7sjh) and one for the MySQL server (wordpress-mysql-5788678cf7-wvr4v). The following figure shows Persistent Volume Claims, Persistent Volumes, and Pods which are using those volumes.
We can easily identify the MySQL and WordPress Persistent Volumes by their claims. To backup this application data, we need to backup both Persistent Volumes.
In following example, we identify Nodes (VMs) that are running our application pods, using the kubectl command:
On GCP, we see the VM instance hosting the two pods is named "gke-cluster1-default-pool-4846a3a4-1r39".
In HYCU Backup and Recovery service on GCP, the instance from the example is represented as following:
Protecting the Kubernetes persistent volumes
Applications hosted on Kubernetes have a myriad of options how to store their data. For persistent volumes which reside on worker nodes, you can simply enable data protection through backup of their instances on GCP.
In HYCU Backup and Recovery service all your Kubernetes cluster workers will be visible in the Instances panel.
Make sure you are on the right Google Cloud Platform project.
- Select the worker node instances that you want to back up.
- Click Policies. The Policies dialog box appears.
- From the list of policies, select the desired backup policy.
- Click Assign to assign the backup policy to the selected instances.
For more information on choosing the right backup policy for your needs, prerequisites and details on backing up instances see "Chapter 4 - Defining your backup strategy" and "Chapter 5 - Protecting instances" in the HYCU Backup and Recovery as a Service for GCP User Guide. (https://docs.gcp.hycu.com/HYCU-Backup-and-Recovery-as-a-Service-for-GCP-User-Guide.pdf)
Restoring the application
Depending on what was corrupted and your Kubernetes configuration, you may need to restore all one or multiple persistent volumes.
The following procedure shows how to recovery MySQL server data by recovering the related Kubernetes persistent volumes claims (PVC):
- Stop workloads using the volumes that need to be recovered
- Delete the related GCE persistent disk that needs to be recovered
- Restore GCE persistent disks from HYCU for Google Cloud Service user interface
- Sign into HYCU for GCP service and navigate to the Instances panel.
- In the Instances panel, find the Kubernetes worker nodes where application is running
- Select the worker node which contains the backup of the GCE persistent disks that needs to be recovered
- In the Details section select the restore point from which the GCE persistent disks will be recovered.
- Click Restore Instance.
- Select Export Disk and click Next.
- Select the disk to be restored and then click Next.
- Leave default values for the Export Disk operation and click Restore.
- Start workloads using the volumes that were recovered