Help Center/ Distributed Cache Service/ User Guide/ Backing Up or Restoring Instance Data/ DCS Backup and Restoration Overview
Updated on 2024-12-16 GMT+08:00
View PDF
Share

DCS Backup and Restoration Overview

On the DCS console, you can back up and restore DCS instances.

Importance of DCS Instance Backup

There is a small chance that dirty data could exist in a DCS instance owing to service system exceptions or problems in loading data from persistence files. In addition, some systems demand not only high reliability but also data security, data restoration, and even permanent data storage.

Currently, data in DCS instances can be backed up to OBS. If a DCS instance becomes faulty, data in the instance can be restored from backup so that service continuity is not affected.

Backup Modes

DCS instances support the following backup modes:

  • Automated backup

    You can create a scheduled backup policy on the DCS console. Then, data in the chosen DCS instances will be automatically backed up at the scheduled time.

    You can choose the days of the week on which automated backup will run. Backup data will be retained for a maximum of seven days. Backup data older than seven days will be automatically deleted.

    The primary purpose of automated backups is to create complete data replicas of DCS instances so that the instance can be quickly restored if necessary.

  • Manual backup

    Backup requests can be issued manually. Data in the chosen DCS instances will be backed up to OBS.

    Before performing high-risk operations, such as system maintenance or upgrade, back up DCS instance data.

Impact on DCS Instances During Backup

Backup tasks are run on standby cache nodes, without incurring any downtime.

In the event of full synchronization of master and standby nodes or heavy instance load, it takes a few minutes to complete data synchronization. If instance backup starts before data synchronization is complete, the backup data will be slightly behind the data in the master cache node.

New data changes on the master node during an ongoing backup are not included in the backup.

Additional Information About Data Backup

  • Instance type
    • Redis: Only master/standby, read/write splitting, Proxy Cluster, and Redis Cluster instances can be backed up and restored, while single-node instances cannot. You can export data of a single-node instance to an RDB file using redis-cli. For details, see How Do I Export DCS Redis Instance Data?
    • Memcached: Only master/standby instances can be backed up and restored, while single-node instances cannot.
  • Backup mechanisms

    DCS for Redis 3.0 persists data to AOF files. Basic edition DCS for Redis 4.0 and later persist data to RDB or AOF files in manual backup mode, and to RDB files in automatic backup mode.

    To export RDB backup files of DCS Redis 3.0 instances, run the redis-cli -h {redis_address} -p 6379 [-a {password}] --rdb {output.rdb} command in redis-cli.

    • DCS for Redis 3.0 is no longer provided. You can use DCS for Redis 4.0 or later instead.
    • For a single-node DCS Redis 3.0 instance on which the SYNC command can be run, you can run this command to export the RDB file. For a Proxy Cluster DCS Redis 3.0 instance, the SYNC command cannot be run due to the architecture. Therefore, the RDB file cannot be exported.

    Backup tasks are run on standby cache nodes. DCS instance data is backed up by compressing and storing the data persistence files from the standby cache node to OBS.

    DCS checks instance backup policies once an hour. If a backup policy is matched, DCS runs a backup task for the corresponding DCS instance.

  • Backup time

    It is advisable to back up instance data during off-peak periods.

  • Storage of backup files

    Backup files are stored to OBS.

  • Handling exceptions in automated backup

    If an automated backup task is triggered while the DCS instance is restarting or being scaled up, the backup task will be run in the next cycle.

    If backing up a DCS instance fails or the backup is postponed because another task is in progress, DCS will try to back up the instance in the next cycle. A maximum of three retries are allowed within a single day.

  • Retention period of backup data

    Automated backup files are retained for up to seven days. You can configure the retention period. At the end of the retention period, most backup files of the DCS instance will be automatically deleted, but at least the most recent backup record will be retained.

    The latest backup files (up to 24) are always stored unless they are manually deleted.

    • A total of 24 latest backups (automatic and manual) can be stored. To store the 25th backup, the earliest one will be automatically deleted.
    • Deleting an instance removes its backups. To restore them, download and save them in advance.
    • Exercise caution when deleting all backup files.

Restoring Data

  • Data restoration process
    1. You can initiate a data restoration request using the DCS console.
    2. DCS obtains the backup file from OBS.
    3. Read/write to the DCS instance is suspended.
    4. The original data persistence file of the master cache node is replaced by the backup file.
    5. The new data persistence file (that is, the backup file) is reloaded.
    6. Data is restored, and the DCS instance starts to provide read/write service again.
  • Impact on service systems

    Restoration tasks are run on master cache nodes. During restoration, data cannot be written into or read from instances.

  • Handling data restoration exceptions

    If a backup file is corrupted, DCS will try to fix the backup file while restoring instance data. If the backup file is successfully fixed, the restoration proceeds. If the backup file cannot be fixed, the master/standby DCS instance will be changed back to the state in which it was before data restoration.