As a huawei cloud information giant, Reading Knowledge Cloud is good at presenting complex information in a diversified way. There is always a picture (cloud map), profound and simple blog (cloud class) or short video (cloud vision hall) that can make you quickly start huawei cloud. Click here for more highlights.

Abstract: When setting an alarm for a backup system, you sometimes encounter a situation where the alarm does not perform as expected. This document describes how to automatically back up resources in huawei Cloud backup service

This article is shared by Huawei cloud community “[Cloud small lesson] basic service lesson 87 Want to achieve automatic backup of resources?

Huawei Cloud Backup and Recovery (CBR) can manually or automatically Backup ECS and BMS on Cloud servers, EVS on Cloud disks, SFS Turbo on file systems, and file sets and databases in IDC data centers.

When using cloud backup, a friend sets an alarm clock for the backup system to automatically back up resources at the specified time and delete expired backup files. In practice, however, the system sometimes doesn’t seem to work the way we expect it to.

This “alarm clock” does not listen to the command, good banana green ~ how to do? How to solve it?

Today, I will take you into a small class on backup strategy, a lesson package will go from beginner to master

Set the appropriate repository capacity

Although this lesson is about setting up policies, proper repository capacity is also critical if you want the policies to work.

Sometimes the policy Settings are fine, but the policy does not perform as expected because the repository is too small to hold the backups that are generated.

So how do we set our repository capacity according to our policy?

At this time, take out the small book on the memory capacity calculation formula:

Repository capacity (GB) = (Disk capacity (GB) + Backup retention period (days)/Backup period (days) x Amount of daily disk change data (GB) x 120%

Description:

If the retention policy is based on the number of copies, you can also calculate the value by converting it to the retention period. For example, if an enterprise backs up data once a day and the number of backup files is set to seven, the retention period can be converted to seven days.

For example, financial company A has an 800GB cloud server and 200GB cloud server is in use. The disk capacity is set to 800GB instead of usage. The amount of data that changes every day is about 10GB. The company plans to back up data twice at 02:00 a.m. and 20:00 p.m. every day, and the backup duration is one month. The size of the cloud server backup repository purchased by the company can be estimated by the formula:

Repository capacity =(800+30/(1/2) x 10) x 120%=1680GB

What if you have already bought a repository and look at the formula and find that there is not enough capacity? It doesn’t matter, expand the repository, one click done! If you really want to reduce the size of the repository, you can buy a new smaller repository and migrate the backup resources to the past

The appropriate repository capacity is required to hold all backups generated by policy execution. If the repository size is not appropriate, backups may fail, backups may not be deleted according to retention rules, and so on.

Setting the right repository capacity is one of the first conditions for a policy to work properly

Set the strategy

Setting a policy is like setting an alarm clock. Refer to the policy parameter table to complete the Settings.

Backup rules

Backup period: Specifies the backup day. You can back up data every day of a week or every other day. The backup rule is set to one backup every Monday, Thursday, and Sunday at 11pm, so three backups will be generated in a week.

Backup time: backup time on the day of the backup, here small editor set at 23:00 backup, currently can only set at the hour oh ~

The more frequent the backups are, the more backups are made, and the more repository capacity is required.

Retention rules

Retention type: By quantity, by time, or permanent.

Rule details: Because the above set backup rules, only three backups a week, xiaobian also only want to retain the backup generated in a week, so only three retention rules are set.

Advanced options: You can set daily backup rules. In this section, the weekly backup rule is set to ensure that the latest backup generated every week is retained. Since the advanced options and reserved type sections do not conflict, you can set both at the same time.

If today is the 30th, this strategy would look like this:

  • The date of the marked time, which is the date when the backup was generated.

  • The gray-time backup has been deleted.

  • The green time backup is retained.

If you do not set the weekly backup rule, only the 25th, 26th, and 29th backups will be retained.

However, the following points need to be noted:

  • You are advised to set the backup time loosely. Otherwise, the backup may be skipped.

Description:

The backup time points of a disk backup policy are 00:00, 01:00, and 02:00. At 00:00, disk backup starts. Because the incremental data to be backed up is large or many backup jobs are executed at the same time, the backup job takes 90 minutes and is completed at 01:30. The backup point at 01:00 will be skipped and the backup will be performed at 02:00. Only two backups will be generated.

  • When setting the backup time and replication backup time, ensure that the backup policy is executed after the backup task is completed. Otherwise, the replication and backup may fail.

  • Backup does not affect the performance of backup resources. However, to ensure the integrity of backup data, you are advised to back up data at dawn when no data is written to the disk.

After setting the policy, don’t forget to bind it to the repository that you want to back up automatically.

conclusion

In most cases, when the appropriate repository capacity and policy are set, the alarm will automatically operate without manual intervention.

Of course, there are occasional surprises. Such as:

  • If the retention rule is modified during policy execution, the backup may not be automatically deleted. For details, see cloud Backup FAQ why Does a Modified Retention Policy Not Take Effect?

  • Forgot to bind the policy to the repository, forgot to open the policy…

  • New resources are bound to the repository. If automatic binding is enabled, you forget to expand the repository.

…

Don’t worry, we find the root cause, see move move!

  • Automatic backup fails due to insufficient repository capacity. We can expand the repository or adjust the frequency of policies to reduce the number of resources bound to the repository……

  • Check whether the policy is enabled and bound before automatic backup……

  • You can manually delete the backup generated by the old policy instead of automatically deleting the backup caused by the modification of the retention rule……

…

If you have any other unexpected problems, please feel free to make fun of them in the comments section

For more information about cloud backup, please click here

Click to follow, the first time to learn about Huawei cloud fresh technology ~