Platform-as-a-Service (PaaS) databases allow users to quickly deploy an environment on-demand without worrying about managing the underlying OS and database platform. The environment is preconfigured, letting the user focus on managing the instances and databases while Google handles the underlying infrastructure.
Google has many different offerings ranging from highly distributed and scalable containerized database platforms to monolithic instances which run popular relational database platforms such as Cloud SQL. Cloud SQL lets you deploy PostgreSQL, MySQL and Microsoft SQL Server instances.
When deploying Cloud SQL, you can choose between Enterprise or Enterprise Plus which affects SLA and recovery point history. You can select a version of the selected database platform and choose an edition preset which uses pre-defined size and performance characteristics depending on the use case. Finally, the user can select which region/zone(s) it should be deployed as well as more advanced tuning options such as storage and security.
Networking and Permissions are two of the more complicated things to configure securely for any cloud workload, and Cloud SQL is no different. By default, Cloud SQL is deployed with a public IP on a Google managed network and not connected to a user-created VPC. The user can specify what IP ranges are allowed to connect. Cloud SQL also has an Auth Proxy to broker SQL connections from a client’s VPC or even outside Google Cloud. Cloud SQL also allows you to connect it to an internal VPC through Private Services Access. This feature in Google Cloud is to allow users to connect their VPC’s private IP space to third-party services and Google services such as managed database instances. This is similar to Private Google Access which is used to communicate to global APIs such as storages.googleapis.com over private IP subnets. If multiple VPC’s need to connect to the same Cloud SQL instance, VPC Peering can be used to allow communication between private networks. It is also common for companies to setup their organization to leverage Shared VPC’s from a central project, allowing other projects in the organization to connect to the same network, making communication between projects simpler.
Veeam Backup for Google Cloud (VBG) supports Cloud SQL MySQL and PostgreSQL options. It can orchestrate instance snapshots and take database backups on a defined schedule. The backup policy works by using Google APIs to trigger the Cloud SQL instance or a staging server to send a native database dump to object storage temporarily which is then protected by a worker and stored in a Veeam format which adds compression and a Veeam managed retention. Restores can leverage the snapshots or backups to bring back an instance or database.
Two of the most common challenges people have when configuring protection of Cloud SQL instances in VBG are configuring the proper permissions and errors talking to the production instance over the network. PostgreSQL and MySQL have a few differences when it comes to authentication. MySQL has an option to leverage IAM in addition to using an OS/Database user account. With that option, the service account used must have cloudsql.instances.login assigned. For PostgreSQL and MySQL, you can also create user accounts via the cloud console, gcloud commands, or through automation tools to be leveraged for backups. Those accounts can then be added into VBG’s SQL Accounts to be used by the protection policy.
When configuring the policy, you can either specify a single SQL Account for all machines in the policy or you can toggle on the custom credentials option to specify an account per instance.
Veeam Backup for Google Cloud deploys workers that will attempt to communicate to the production Cloud SQL instances to export some information not captured as part of the database dump. The workers are not deployed with a public IP and Google VPC Subnets do not have a route to the public Internet unless Cloud NAT is configured which can cause problems for Cloud SQL instances that are only have a public IP. If the VPC Subnet that the worker is assigned to isn’t able to connect an internal IP for the Cloud SQL instance either through private services access in the same VPC or VPC peering to the VPC where Cloud SQL is available, backups will fail. There are a few options to address this configuration. In the backup policy settings, you can enable the option to use a Staging server. This will deploy a new temporary Cloud SQL instance from the snapshot created by the backup policy and setup private service access on the same VPC as the worker is deployed.
Using a staging server has the added benefit of offloading the database backup operation to a temporary copy of the server instead of taking up resources on the production server, with the tradeoff being the extra cost of running the staging server during backups. The staging server is also the only option available if Cloud SQL is configured to work over SSL instead of standard database ports.
Another option to address this problem is to login to the VBG appliance via SSH or a cloud console terminal to modify a configuration XML file on the server enabling public IPs for Cloud SQL Workers. Details about this can be found in the Appendix section of the user guide: Appendix A. Configuring Deployment Mode - Veeam Backup for Google Cloud User Guide. VBG will configure the firewall policy for Cloud SQL to allow connectivity from the VBG worker IP. If there is a policy that prevents VMs from being assigned a public IP, this will cause the workers nodes to fail to be deployed correctly.
Instead of comparing native backup and restore capabilities with Veeam’s capabilities, it is better to consider how they can complement each other. The native protection allows for log replay within a certain window which can be helpful for more granular recovery in the event that something happens to the dataset, and it needs restored to a specific time. Veeam’s backups offer the ability to keep GFS style retention allowing a customer to keep daily/weekly/monthly and yearly points in a compressed state, saving space. Veeam has the option to recover a specific database or the whole instance which can be beneficial if you have multiple databases on the server and only one needs recovered.