Backup Principles

Updated on 2023-10-18 GMT+08:00

View PDF

GaussDB(for MySQL) instances support automated and manual backups. You can periodically back up data in your databases, so if a database becomes faulty or data is damaged, you can restore the database from backup.

Automated backup
You can click Configure Some-Region Backup Policy on the management console, and the system will automatically back up your instance data based on the time window and backup cycle you specify in the backup policy and will store the data for as long as you have configured the retention period for.
- Automated backups cannot be manually deleted. To delete them, you adjust the retention period specified in your same-region backup policy. Retained backups (including full and incremental backups) will be automatically deleted at the end of the retention period.
- A full backup means that all data in your database is backed up. In an incremental backup, only data that has changed within a certain period is backed up.
  Incremental backups are created based on the most recent full backup, as shown in Figure 1, so the most recent full backup that exceeds the retention period is still retained. For details, see the following example.
  
  Figure 1 Backup restoration
Manual backup
Manual backups are user-initiated full backups of your database. They are retained until you delete them manually.

Regularly backing up your database is recommended, so if your database becomes faulty or data is corrupted, you can restore it from backup.

Backup Principles

GaussDB(for MySQL) is based on latest-generation DFV storage, which decouples storage from compute. The compute layer provides services for external systems and manages logs, and the storage layer stores the data. The storage layer consists of Common Log nodes and Slice Store nodes.

As shown in Figure 2, the creation of backups involves in the compute layer and storage layer.

The primary node at the compute layer reads the log content of the Common Log node at the storage layer and backs it up to OBS.
The primary node at the compute layer sends a command for backing up data to the Slice Store node at the storage layer. The Slice Store node backs up data to OBS.

During the creation of a backup, the CPU usage and memory usage of the primary node of your instance increase slightly, but you will not notice anything at the storage layer. The final backup is stored in OBS as multiple data files and does not use up any of the disk space of the instance.

Figure 2 Backup principles