In this article, we will explore the world of cloud-based server backup and recovery. Whether you are using a Linux server with PostgreSQL or any other supported database, the information shared here will be applicable to your needs.
Set the scene
Before going into details, let’s first understand the steps involved in setting up the backup and recovery process. You will need to install the Backup and DR (Disaster Recovery) service, which will provide you with a management console running as a service. Additionally, a backup and recovery appliance must be deployed in one of your projects as a Compute Engine instance. This device will be responsible for creating backups.
To store your backups, you will have a snapshot pool based on a persistent disk. Several options are available to choose the type of disk to use. Additionally, an OnVault pool will be created in Google Cloud Storage to securely store your backups for the long term.
To start the backup process, you will need to deploy the Backup and Disaster Recovery Agent on your Linux servers. This can be done either on a Compute Engine instance or on a VMware VM, depending on your configuration. The agent will ensure that your supported databases or file systems are backed up efficiently.
Installing the Backup Agent
Once the backup and disaster recovery agent is installed, there are three key considerations:
-
Validating the database configuration: You may need to perform specific configurations to ensure that the database can work with the backup and disaster recovery service.
-
Discovery process: This involves adding the databases to the service and making them eligible for protection.
-
Application of the backup plan: The backup plan is applied to the databases and the backup process begins.
The backup process
The backup process consists of six steps:
-
Login to the app: The backup and recovery appliance communicates with the backup and disaster recovery agent on the Linux server, establishing a connection on port 5106.
-
Creating a virtual disk: A virtual disk is presented from the backup and recovery appliance snap pool. This disk is considered a real disk by the Linux server.
-
Database preparation: The Backup and Disaster Recovery agent works with the database to instruct LVM (Logical Volume Manager) to create a snapshot of the logical volume where the database resides. This process requires that the volume group has sufficient space.
-
Copying the logical volume snapshot: A copy of the logical volume snapshot is made to the backup disk. The first backup is a full copy, while subsequent backups are incremental.
-
Track changes: Between each snapshot, the backup process tracks changed blocks using a changed block tracking driver. These changes are then merged into the backup, creating a full backup every time.
-
Off-site storage: Optionally, the backup process can store change blocks in an OnVault pool in Google Cloud Storage. This provides an off-site storage location for added security. Multiple OnVault pools and retention policies can be configured as needed.
Log backups
Besides database backups, you also have the option to backup logs. Log backup jobs can be run separately from database backup jobs and as often as every 15 minutes. The log backup process is similar to traditional backups, where logs are copied to the staging disk and then stored externally, possibly in the OnVault pool.
Restoration and mounting options
When it comes to restoring your backups, you have two main options:
-
To go up: A virtual copy of the backup can be mounted on any server, either the source server or another. This allows you to start the database as a running instance.
-
Traditional catering: For a traditional restore, you connect to the source host and copy the backup to the corrupted or non-functional database to restore it to its original state.
Additional Considerations
The processes explained above are generally applicable, but there are some specific considerations for certain database systems:
-
SAP HANA: For SAP HANA, you can choose between backint, which represents a traditional backup, or savepoint, which saves a copy of the database in the internal LVM of the SAP HANA server. Both options offer the possibility of offloading the backup to the intermediate disk.
-
Oracle: Oracle backup uses RMAN image copy instead of logical volume snapshots. RMAN image copy can be done via iSCSI or NFS and follows a similar process to create full copies with each backup. Backups can also be transferred to Cloud Storage.
Configuration and use
To get started with cloud-based server backup, you need to enable the Backup and Disaster Recovery service, create a Google Cloud Storage bucket for your OnVault backups, and validate your firewall rules. Once setup is complete, you can add the Cloud Storage bucket as an OnVault pool, create backup plans and templates, integrate your applications, and configure backups. Once the backups are complete, you can use them for mounts or restores as needed.
For more detailed information on each step, refer to our playlist series where we cover everything you need to know about cloud-based server backup and recovery.
Now that you have the knowledge to protect your valuable data in the cloud, you can confidently ensure the security and reliability of your server backups.
Conclusion
Backing up cloud-based servers is a crucial aspect of maintaining data integrity and ensuring business continuity. By taking advantage of available backup and recovery services, you can rest assured that your databases and file systems are protected against any potential loss or interruption. With the step-by-step guide provided in this article, you can easily implement a robust backup strategy for your Linux servers and supported databases.
Remember, regular backups are essential for any business, and with the convenience and reliability of cloud-based solutions, you can focus on your core operations knowing your data is safe.
