Automatically clean up expired backups

After a backup succeeds, you can set a cleanup policy for a tenant based on business requirements. For a tenant with a cleanup policy configured, automatic cleanup is triggered once every hour so that expired backups can be cleaned up in a timely manner.

The current version supports only automatic cleanup of expired backups and does not support manual cleanup of expired backups.

Considerations

• Because log archive data cleanup depends on data backup, make sure that data backup files exist before you clean up log archive data. If no data backup files exist, you cannot clean up log archive data.

• Automatic cleanup supports cleaning up data only in the backup destination and archive destination configured in DATA_BACKUP_DEST and LOG_ARCHIVE_DEST. If the backup destination or archive destination has been changed, data under the original backup path or archive path cannot be cleaned up through OceanBase Database.

• Automatic cleanup retains at least one valid backup. If only one valid backup exists, that backup is never cleaned up.

• Automatic cleanup results vary depending on the backup medium:

  • For NFS or S3-compatible object storage (such as OBS and GCS) used as the backup medium, the system directly deletes backup files that meet the cleanup requirements when backup data is cleaned up.

  • For S3/COS used as the backup destination (accessed through s3://), the backup file cleanup method depends on the value of the delete_mode parameter in data_backup_dest and log_archive_dest. For more information about this parameter, see SET LOG_ARCHIVE_DEST and SET DATA_BACKUP_DEST.

• In particular, if enable_worm=true is configured in the path attributes, during automatic cleanup of backup data, the system selects backup sets that meet the conditions based on the time specified by RECOVERY_WINDOW. However, whether cleanup succeeds depends on the cleanup mode of the path (the value of the delete_mode parameter) and the retention policy of the corresponding bucket.

  Notice

  The enable_worm=true parameter applies to scenarios where a compliance retention policy (WORM) is enabled. In OceanBase Database V4.2.5, starting from V4.2.5 BP7, you can use an Alibaba Cloud OSS bucket with a WORM policy configured as a backup or archive path.

  For example, if a backup set is outside the time specified by RECOVERY_WINDOW but is still within the WORM (Write Once Read Many) retention period:

  • If the cleanup mode of the backup set is delete, OceanBase Database fails to clean up the backup set. You must wait until the retention period of the object expires before the backup set can be cleaned up.

  • If the cleanup mode of the backup set is tagging, OceanBase Database tags the backup set. The object storage service eventually deletes it after the lifecycle ends and the WORM retention period expires.

Set a cleanup policy

Set a cleanup policy as a user tenant

1. Log in to the database as a tenant administrator of the user tenant.

2. Set a cleanup policy, which is equivalent to enabling automatic cleanup for the tenant.

   The statement is as follows:

   obclient> ALTER SYSTEM ADD DELETE BACKUP POLICY policy_name RECOVERY_WINDOW recovery_window;
   

   where:

   • The POLICY parameter specifies the cleanup policy name. Currently, only default is supported, which means automatic cleanup applies only to backups in the current data_backup_dest and log_archive_dest settings.

   • The RECOVERY_WINDOW parameter controls the time window during which backup data can be restored. For more information about this parameter, see Introduction to the recovery_window parameter.

   Example:

   obclient> ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d';
   

   Note

   Automatic cleanup tasks are triggered by the background system once every hour. Therefore, after you set a cleanup policy, you may need to wait for a period of time (no more than one hour) before you can query the corresponding cleanup task.

Set a cleanup policy as the sys tenant

1. Log in to the sys tenant of the cluster as the root user.

2. Set a cleanup policy, which is equivalent to enabling automatic cleanup for the tenant.

   The statement is as follows:

   obclient> ALTER SYSTEM ADD DELETE BACKUP POLICY policy_name RECOVERY_WINDOW recovery_window TENANT tenant_name;
   

   where:

   • The POLICY parameter specifies the cleanup policy name. Currently, only default is supported, which means automatic cleanup applies only to backups in the current data_backup_dest and log_archive_dest settings.

   • The RECOVERY_WINDOW parameter controls the time window during which backup data can be restored. For more information about this parameter, see Introduction to the recovery_window parameter.

   • The TENANT parameter specifies the tenant for which the cleanup policy takes effect. You must specify the name of a user tenant. Currently, only one tenant name can be specified.

   Notice

   Currently, only tenant-level cleanup policies are supported. Cluster-level cleanup policies are not supported. Each command can set only one cleanup policy for one tenant.

   The following example shows how the sys tenant specifies a cleanup policy for the MySQL tenant:

   obclient> ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d' TENANT MySQL;
   

   Note

   Automatic cleanup tasks are triggered by the background system once every hour. Therefore, after you set a cleanup policy, you may need to wait for a period of time (no more than one hour) before you can query the corresponding cleanup task.

View configured cleanup policies

Both the sys tenant and user tenants can query views to obtain all configured cleanup policies.

1. Log in to the database as a tenant administrator of the sys tenant or a user tenant.

2. View the cleanup policies configured for tenants.

   • The sys tenant uses the oceanbase.CDB_OB_BACKUP_DELETE_POLICY view to view cleanup policies of all tenants.

     Example:

     obclient> SELECT * FROM oceanbase.CDB_OB_BACKUP_DELETE_POLICY;
     +-----------+-------------+-----------------+
     | TENANT_ID | POLICY_NAME | RECOVERY_WINDOW |
     +-----------+-------------+-----------------+
     |      1002 | default     | 7d              |
     +-----------+-------------+-----------------+
     1 row in set
     

   • The user tenant uses the oceanbase.DBA_OB_BACKUP_DELETE_POLICY view or the sys.DBA_OB_BACKUP_DELETE_POLICY view to view the cleanup policies of the current tenant.

     • MySQL tenant

       obclient [(none)]> SELECT * FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;
       +-------------+-----------------+
       | POLICY_NAME | RECOVERY_WINDOW |
       +-------------+-----------------+
       | default     | 7d              |
       +-------------+-----------------+
       1 row in set
       

     • Oracle tenant

       obclient [SYS]> SELECT * FROM sys.DBA_OB_BACKUP_DELETE_POLICY;
       +-------------+-----------------+
       | POLICY_NAME | RECOVERY_WINDOW |
       +-------------+-----------------+
       | default     | 7d              |
       +-------------+-----------------+
       1 row in set