TWI608358B - Method for data protection in cloud-based service system - Google Patents

Description

Method for data protection in cloud service system

The invention relates to a method for data protection, in particular to a method for data protection in a cloud service system.

Workloads, such as MongoDB, operate on cloud service systems with cluster nodes. The workload can be run on a single node or nodes of the cloud service system, each node specifying at least one disk to store the data for access. In the case of a workload running on a single node, when the specified disk is damaged, the workload cannot be executed until the backed up data is restored. For workloads working on several nodes, when one of the specified disks is damaged, or even an entire node is damaged, the performance of the cloud service system may be degraded because the data needs to be transferred to the new node. The performance of the workload is also affected. Obviously, the health of the disk in the cloud service system and the well-planned archiving of data recovery are important factors for data protection of the workload.

In fact, many of the existing technologies provide the above-mentioned corresponding demand solutions, and most of them are about the prediction of the life of the storage device. For example, one A conventional method for monitoring the life of a storage device may include the steps of: setting a database for recording a plurality of training materials, wherein each training material includes operational habit information and a corresponding operational life value; Obtaining operational habit information; establishing a storage device life prediction model according to the operational habit information and the operational life value of the corresponding training data; and inputting the operational habit information of the storage device to the storage device life prediction model to generate for the individual storage device A predicted lifetime value. The storage device life prediction model can also be established by using the predicted life value. When a first storage device in the storage device is damaged, a real life of the first storage device is recorded to establish the storage device life prediction model.

Although there are many ways to predict the life of a storage device so that data protection can be performed with this prediction, many challenges are still encountered in the application. First, the probability of damage to a storage device (hard disk or solid state drive) increases rapidly as the storage device approaches the end of its useful life. However, the foregoing method relies only on training data for operating life values, and sudden storage device damage before the end of the service life is difficult to predict. Second, the destruction of the storage device is the result of loading the workload. In other words, higher workload usage requirements result in shorter storage device life. The impact of the workload is not considered in the previous method. In addition, data protection should include appropriate plans for data backups stored in storage devices. If data backups occur frequently, the performance of related workloads may be reduced. Conversely, a systemic crash of the workload may occur. This problem can be solved if there is a predicted storage device life.

Therefore, the present invention discloses a method for data protection in a cloud service system, which is a solution to the above problem. Most importantly, the present invention introduces the concept of "proximity to damage", considering the probability of damage when a disk approaches the end of its useful life. Thus, the present invention can provide a more accurate prediction of the point in time at which the disk may be damaged, and is an innovative method of data protection in the cloud service system.

This paragraph of text extracts and compiles certain features of the present invention. Other features will be revealed in subsequent paragraphs. The intention is to cover various modifications and similar arrangements in the spirit and scope of the appended claims.

In order to solve the above problem, the present invention discloses a method for data protection in a cloud service system, the method comprising the steps of: A. collecting historical operation data of a storage device in a cloud service system; B. establishing a collection of operation data from the cloud service system Life expectancy model and a 7-day damage probability model; C. Enter the operational data of the past 24 hours for each storage device into the life expectancy model and the 7-day damage probability model to obtain the range and corresponding life expectancy in each group The probability of damage; and D. Back up the data in the storage devices according to the results of step C.

According to the present invention, the operational data may be performance data, SMART (Self-Monitoring Analysis and Reporting Technology) data, available capacity of the storage devices, total capacity of the storage devices, or device elements. data. The performance data can be delay time, throughput, CPU (Central Processing Unit) load, memory usage, or IOPS (Input/Output Per Second, per Second input/output operation times). The storage device can be a hard disk or a solid state hard disk. The life expectancy model and the 7th damage probability model are continuously updated with the operational data newly collected in the future. The time interval for collecting historical operational data for storage devices can be one hour. The life expectancy model is established by the following steps: B1. distinguishing the storage devices from good and damaged; B2. classifying the damaged storage devices with different life ranges and setting all good storage devices to a specific life span; B3. Binning the operational data of the storage devices to a plurality of groups according to the life ranges; and B4. normalizing the operational data from each storage device for all groups. The life expectancy model is operated by the following steps: B3'. classify the operational data of the storage devices into a plurality of groups according to the life ranges; and B4'. normalize the operational data from each storage device for all groups. The 7-day damage probability model is established by the following steps: B5. Sorting the operational data; B6. Storing the damaged storage device and a plurality of randomly selected good storage devices within 7 days from the time of the recent collection. Information on the operation of the equipment; and B7. Regularization of operational information from each storage device. The ratio of storage devices used to collect operational data damage to good storage devices within 7 days from the date of collection may be 1:1.

According to the present invention, the method may further comprise the steps of: A1. Collecting historical operational data of the storage device, wherein the storage devices are brand new or just joined the cloud service system.

The life expectation model can calculate the past 24 hours of the inputs by an ANN (Artificial Neural Network) algorithm. Operational data and historical operational data to predict the extent of these life expectancy. The 7-day damage probability model can also calculate the corresponding damage probability by using an ANN algorithm to calculate the operational data and historical operational data of the past 24 hours.

Step D may further back up data in a storage device having an expected life of less than a corresponding specified lifetime and/or having a probability of damage exceeding a certain percentage. Step D may further perform backup of the data in the storage device by performing a snapshot job having the calculated snapshot interval. For the latter, the snapshot time interval is calculated by entering the result of step C into a fuzzy system.

The fuzzy system is formed by the following steps: E1. Defining the language values for the bins, the probability of damage, and the snapshot interval; E2. Constructing a membership function to describe all the ratings, the probability of corruption, and the extent of the snapshot interval And E3. Construct fuzzy rules for these grading, damage probability, and snapshot time intervals. The fuzzy system includes operational steps: F1. receiving a grading and a probability of damage; F2. inputting the grading and damage probability to the membership functions of the fuzzy rules to perform fuzzification, fuzzy reasoning, and summarizing the results; and F3. Blurring to get a snapshot interval.

With the life expectancy model and the next 7-day damage probability model, the life expectancy and the probability of damage to any storage device over the next 7 days can be determined. Once these results are obtained, the time course of the data backup (snapshot job) can also be determined, and the aforementioned problems can be solved at one time.

10‧‧‧Cloud Service System

100‧‧‧Server

101‧‧‧Central Processing Unit

102‧‧‧Storage device output input unit

103‧‧‧Database

104‧‧‧Network output input unit

110‧‧‧ Operational Data Collector

200(1)‧‧‧First storage equipment

200(2)‧‧‧Second storage equipment

200(3)‧‧‧ third storage equipment

200(N)‧‧‧Nth storage equipment

200(N+1)‧‧‧N+1 storage device

Figure 1 shows a typical cloud service system that the method can be applied to.

2 is a flow chart of a method for data protection in a cloud service system in accordance with the present invention.

Figure 3 shows the workflow for establishing this life expectancy model.

Figure 4 shows the workflow for establishing the 7-day damage probability model.

Figure 5 is a table showing the input and output of the life expectancy model and the next 7th damage probability model.

Figure 6 is a flow chart of a method of forming a fuzzy system.

Figure 7 shows the language values and fuzzy rules for the grading, damage probability, and snapshot time interval.

Fig. 8, Fig. 9, and Fig. 10 show the membership functions of the fuzzy system.

The invention will be more specifically described by reference to the following embodiments.

The method disclosed by the present invention is applicable to data protection of a cloud service system, which is an architecture for working with workloads such as email services, video streaming, ERP systems, and the like. A typical cloud service system 10 to which the method is applicable is shown in FIG. The cloud service system 10 includes a server (host) 100 and a plurality of storage devices 200. The server 100 basically has a central processing unit 101, a storage device output input unit 102, and a database 103. And a network output input unit 104. The central processing unit 101 manages the operation of the cloud service system 10 and the workloads it operates on. At the same time, the central processing unit 101 can track and record the operational data from the storage device 200 and from the network output input unit 104 via the storage device output input unit 102. The storage device output input unit 102 is hardware conforming to any industry standard applied to the cloud service system 10 for internal data transfer. The industry standard can be PCI Express (Peripheral Component Interconnect Express), IDE (Integrated Device Electronics), SATA (Serial Advanced Technology Attachment), or USB (Universal Serial) Bus, universal sequence 埠). The network output input unit 104 is a hardware for wirelessly or wiredly connecting to an external client device such as a personal computer, a tablet computer, or a smart phone. The network output input unit 104 can be a USB port, an RJ45 port, a fiber optic connector, a Wi-Fi module, or a Bluetooth module. The database 103 refers to a database or a structured data that can be permanently or temporarily established in a DRAM of a hard disk, a solid state hard disk or a server 100, and does not directly access a workload, which is advantageous for the application of the present invention. In this embodiment, there are N storage devices 200 (a first storage device 200 (1), a second storage device 200 (2), a third storage device 200 (3), ... and a Nth Storage device 200 (N)).

The operational data may be performance data, SMART (Self-Monitoring Analysis and Reporting Technology) data, available capacity of the storage device 200, total capacity of the storage device 200, or Device metadata. The performance data is physical information about the operation of the cloud service system 10 that executes the workload. For example, performance data can be latency, throughput, CPU (Central Processing Unit) load, memory usage, or IOPS (Input/Output Per Second). The pipeline may be connected to the storage device output input unit 102 of the storage device 200, the network output input unit 104 connected to the external client device, or the data stream directly from the central processing unit 101. The SAMRT data is used to indicate a possible drive failure with a sequence of words (numbers), which can be obtained by installing monitoring software in each storage device 200. Thus, in accordance with the definition of SMART, storage device 200 can be a hard disk or a solid state hard disk. Information other than the performance data and the SMART material can also be used in the present invention as long as they can be easily obtained when the cloud service system 10 is in operation before all the storage devices are installed.

The above is a standard cloud service system to which the present invention can be applied. In order to implement the method proposed by the present invention, an operational data collector 110 is required. In this embodiment, the operational data collector 110 is a hardware device that is connected to the server 100 and connected to the central processing unit 101 for collecting operational data and storing the collected operational data in the database 103 (usually as data). The library type exists). In practice, a software having the same function as the hardware can also be installed in the server 100 and operated by the central processing unit 101. The operational data collector 110 operates in conjunction with the central processor 101 to perform the steps of the present invention.

Please refer to FIG. 2, which is a flow chart of a method for data protection in the cloud service system 10. The first step of the method is to collect the historical operation data of the storage device 200 in the cloud service system 10 by using the operation data collector 110 (S01). Before the application of the method, the cloud service system 10 may have been in operation for a period of time, and the collected operational data may reflect the load of data access from the workload (the time and frequency of the workload access to the storage device 200). However, if historical operational information is not obtained, such as missing data, or the cloud service system 10 has just been erected, the operational data for the method can be collected by collecting information about the respective storage devices 200 to be used by the cloud service system 10. And achieved.

The second step of the method is to establish a life expectation model and a 7-day damage probability model (S02) from the collected operational data. The life expectancy model and the next 7th damage probability model are stored in the database 103 in a database type, and the data is executed and periodically updated. The steps to establish a life expectancy model and a 7th damage probability model are as follows.

See Figure 3, which is the workflow for establishing this life expectancy model. First, the historical operation data that the cloud service system 10 has acquired by the storage device 200 is acquired (S11). Historical operational data can be obtained in batches. That is to say, it may be that some of the historical operational data of the storage device 200 for establishing the life expectancy model is already in one database, and another batch of historical operational data is newly added. The historical operational data of the newly acquired storage device 200, for example, can be regarded as a new training material from half an hour ago so that the predicted result can be closer to true. real. Operational data is used to build and update the life expectancy model and update it in the future. It may take a while for the "damaged storage device" to appear. The method provided by the present invention requires knowledge of the evolution of the life of the storage device 200 over time. Next, the storage devices 200 are distinguished as being good and damaged (S12). When a storage device 200 is good and can work, the collected historical operation data only reflects the difficult environment that the storage device 200 can tolerate (the application of the workload, the management mode of the cloud service system 10, and the hardware of the cloud service system 10) Physical state...etc.). If the storage device 200 is damaged and cannot function, the historical operational data collected may be regarded as a record of its lifetime. Any identical storage device 200 may fail if the same situation experienced by the damaged storage device 200 is encountered and the same or similar operational data is tracked. For the damaged storage device 200, it is classified into different life ranges (S13). Here, the life span is a continuous number of days. For example, from 0 days (DOA, Dead on Arrival) to 90 days, from 91 days to 180 days, from 181 days to 270 days... and so on. Each storage device 200 can be classified into a range of lifetimes based on the number of working days before the damage. For a good storage device 200, since they are still healthy, all of the good storage devices 200 are set to a specific life span (S14). There is no upper limit to this particular life span. For example, more than 1081 days. "1081 days" may refer to the time when the cloud services system 10 has been running or the good storage devices 200 have been in operation. That is to say, the good storage device 200 has been operating normally for at least 1081 days. It is emphasized that the lower limit of the specific life range is not limited to 1081 days, which is only a reference example.

Next, the operational data of the storage devices 200 are binned into a plurality of groups according to the lifetime range (S15). Data grading is a data pre-execution technique used to reduce secondary observational error effects. The raw data value falling within a given cell, ie, a hierarchy, is replaced by a value representing the interval, which is usually an intermediate value, in a quantized form. The operational data of the storage device 200, whether good or damaged, is ranked according to the life span defined in step S15. When a storage device 200 is grouped into a group, such as bin #4 (from 271 to 360 days), all operational data is also ranked into the group. For simplification, the grading values (representative values of the intervals) are in the order of the first one (from 0 to 90 days). Finally, the operational data from each storage device 200 is normalized for all groups (S16). Since the storage devices 200 in each group (classification) may not be of the same type (solid state hard disk or hard disk) or a consistent model (the same specific or manufactured model of the same manufacturer), it is important to establish The predicted life expectancy model needs to be in the "Apple vs. Apple" approach. Forecasts should identify specific models and not all models (applicable to solid state drives may not work on hard drives; 512G solid state drives may not be suitable for 1G solid state drives; 1G solid state drives for Toshiba may not be applicable to Samsung) 1G solid state hard drive). After the end of the above steps, the life expectancy model is ready to provide a life prediction for each storage device 200 by displaying the results of the group (hierarchy). It is important to emphasize that this forecasting step can be performed once a day, although there may be 24 operational data collections for training.

It is to be noted that the above description for establishing the life expectancy model is referred to as the learning phase, meaning that the data for the above steps is used repeatedly before the expected workload goes online or even before the cloud service system 10 operates. The life expectancy model can then be applied to an operational phase in which the life expectancy model operation considers the impact of the online workload. The steps of the operational life expectation model may be simplified to obtain the historical operational data 200 that the cloud service system 10 has acquired from the storage device 200 (S11); and the operational data of the storage devices 200 are classified into a plurality of groups according to the lifetime range (S15); The operation data from each storage device 200 is normalized for all groups (S16). At this stage, it is only necessary to repeat steps S11, S15 and S16, and the expected classification can be found by the reference life expectancy model.

As for the establishment of the 7-day damage probability model, please refer to Figure 4, which is the workflow for establishing the 7th damage probability model. First, the history operation data 200 that the cloud service system 10 has acquired by the storage device 200 is acquired (S21). Similarly, historical operational data can be obtained in batches. It may be that some of the historical operational data of the storage device 200 used to establish the 7-day damage probability model has been in one database, and another batch of historical operational data has just been added. The historical operational data of the newly acquired storage device 200 can be viewed as a new material for training to predict that the results will be closer to reality. However, not all historical operational data can be used. Then, the 7-day damage probability model needs to sort the operational data (S22), and it is necessary to know that the operational data comes from good storage devices, and the operational data comes from damaged storage devices. Then, for the damaged storage The storage device 200 obtains the operation data of the storage device 200 within 7 days from the point of the recent collection (S23) and the logarithm of the randomly selected good storage devices 200 to obtain the operation data of the storage device 200 within 7 days from the point of the latest collection ( S24). If the last collection time is one hour ago, the operation data of the storage device 200 should be collected one hour ago and ended after 168 hours. Very importantly, according to the present invention, the ratio of the storage device 200 for collecting the damage of the operational data to the good storage device 200 within 7 days from the point of the recent collection is 1:1, so that the storage device can be predicted in a balanced manner. 200 damage probability. Since the number of good storage devices 200 must be greater than the number of damaged storage devices 200, this is why step S24 requires several randomly selected good storage devices 200, rather than all good storage devices 200. Finally, the operational data from each storage device 200 is normalized (S25). Similarly, conventionalization makes the prediction of damage probability more accurate for each model of storage device 200. In accordance with the present invention, the life expectancy model and the next 7 day damage probability model camp are continuously updated with operational data newly collected in the future. The time interval for collecting historical operational data of the storage device 200 is preferably one hour.

Similar to the scenario of the life expectancy model, the above description of the damage probability model for the next 7 days is called the learning phase, meaning that the data used for the above steps is repeatedly used before the expected workload goes online or even before the cloud service system 10 operates. use. The 7-day damage probability model can then be applied to an operational phase in which the next 7-day damage probability model operation considers the impact of the online workload. The 7th day damage probability model is obtained by acquiring the cloud service system 10 It is operated by the historical operation data 200 that has been obtained. The probability of damage can be obtained by referring to the 7th damage probability model.

The third step of the method for data protection in the cloud service system 10 is to input the operation data of the past 24 hours for each storage device 200 into the life expectancy model and the next 7 day damage probability model to obtain each The range of life expectancy in the group and the corresponding probability of damage (S03). See Figure 5, which is a table showing the input and output of the life expectancy model and the 7th damage probability model. After the life expectancy model and the next 7th damage probability model are ready to provide forecasts, enter the operational data. There should be N operating data but only 3 for illustration. The first storage device 200(1) has a life expectancy ranging from bin #18 (expected life from 3061 hours to 3240 hours) and the damage probability is 35%. The second storage device 200(2) has a life expectancy ranging from bin #21 (expected life from 3601 hours to 3780 hours) in a group with a damage probability of 21%. The third storage device 200(3) has a life expectancy ranging from bin #2 (expected life from 181 hours to 360 hours), and the damage probability is 95%. It appears that the third storage device 200(3) has a shorter life expectancy and a higher chance of damage within the next 7 days. Thus, the data stored in the third storage device 200(3) should be scored in order to avoid loss. This is the final step of the method of the present invention: the data in the storage devices is backed up according to the result of step S03 (S04).

According to the present invention, the life expectancy model calculates the past of the inputs by an ANN (Artificial Neural Network) algorithm. 24-hour operational data and historical operational data to predict the range of life expectancy. Similarly, the 7th damage probability model also calculates an operation probability and historical operation data of the past 24 hours of the input to predict the corresponding damage probability by an ANN algorithm. The ANN algorithm applied to the life expectancy model and the ANN algorithm applied to the 7th day damage probability model may be the same or different. There are many ANN algorithms available today, as long as they can calculate the parameters between the input operational data and the historical operational data obtained. The life expectancy model indicates a group (hierarchical number), and the next 7 day damage probability model provides a probability value for each storage device 200.

If a new form of storage device new storage device, such as an N+1th storage device 200 (N+1) is to be used for the cloud service system 10 but the cloud service system 10 does not have any of its records, in accordance with the present invention, in step S01 One more step should be followed: collecting historical operational data of the storage device 200, wherein the storage devices 200 are brand new or just joined the cloud service system 10. (S01'). As described above, before the N+1th storage device 200(N+1) goes online, the remaining storage devices 200(1) to 200(N) have collected a lot of operational data in the past time, and there is already an existing one. The life expectancy model and an existing 7-day damage probability model. The historical operation data of the (N+1)th storage device 200 (N+1) can be obtained from other data centers or test sites and distributed to the cloud service system 10. After steps S01 to S02 are completed, a new life expectancy model and a new 7-day damage probability model can be created. For the N+1th storage device 200(N+1), it must be decided which set of models (existing or new) can accurately predict its performance. This determination can be manually processed by the server 100 manager or by the operational data collector 110. The operational data collector 110 acts like an arbiter and makes decisions based on the performance of the N+1th storage device 200 (N+1) in the future. It may take a long time to make a decision. The existing model or the new model can be used as a preset model to be executed in the cloud service system 10 before the decision is issued. If the operational data collector 110 finds that the predictions of the two sets of models for the (N+1)th storage device 200 (N+1) deviate from the actual situation, the operational data collector 110 may decide to create a more fresh one according to the steps of the method. A set of models until the predictions presented by a set of models fall within an acceptable range.

For data protection, it is very important to back up the data in the storage device 200 with a higher probability of damage or a shorter life expectancy. The only thing to note is the frequency of backups (in this case, whether to back up the next day). A simple implementation to implement step S04 may be to back up data within the storage device 200 having an expected life of less than a corresponding specified lifetime and/or having a probability of damage exceeding a certain percentage. For example, for the first storage device 200(1), since it is a solid state hard disk, it can be set to perform data backup once it falls within the bin#18 range and the damage probability is predicted to exceed 90%. Because the damage probability in Figure 5 is only 35%, the data in the first storage device 200(1) will not be backed up between 13:45, 2016/5/12 to 13:45, 2016/5/13. . The time interval is not limited to one day (24 hours), which will be determined and explained below.

Of course, the backup can be a snapshot of the storage device 200. In another embodiment, the present invention provides another step enhancement description step S04: by execution The snapshot job having the calculated snapshot time interval is backed up for the data in the storage device 200 (S04'). The snapshot time interval is calculated by inputting the result of step S03 into a fuzzy system. The applied fuzzy system is established by the following steps (see Figure 6): defining the language values for the grading, the probability of damage, and the snapshot interval (S31); constructing a membership function to describe all grading, probability of damage, and The degree of the snapshot interval (S32); and the fuzzy rules are constructed for the grading, the probability of damage, and the snapshot interval (S33). For a better understanding, see Figure 7.

Figure 7 shows the language values and fuzzy rules for these grading, damage probability, and snapshot time intervals. The language values used for grading (expected life) are very long, long, neutral, short, and very short. The language value used to damage the probability is possible, neutral, and impossible. The language values used for snapshot intervals are very long, long, neutral, short, and very short. The fuzzy rules are stated in each of the hierarchical columns with the expected field for each damage. For example, if the life expectancy is "long" and the probability of damage is "likely", the snapshot interval is "short". The definition of the fuzzy rules is established based on the policy of the workload executed on the cloud service system 10. Fuzzy rules can vary depending on the workload's needs (SLAs). The membership functions for the classification, the probability of damage, and the degree of description of the snapshot interval are shown in Figures 8, 9, and 10, respectively.

The operation steps of the fuzzy system are explained below. First, receiving a grading and a probability of damage (S41), the grading and damage probability is a result of performing the step (S03). Then, by inputting the grading and damage probability to the fuzzy rules The membership function performs blurring, fuzzy reasoning, and summary of results (S42). Many prior art techniques can achieve gelatinization, fuzzy reasoning, and summary of results, and the invention is not limited thereto. Like other fuzzy systems, the final blurring is performed to obtain a snapshot time interval (S43). Similarly, the manner of defuzzification may vary according to the manner in which the fuzzification is performed, which is not limited by the invention. The calculated snapshot time interval can be immediately applied to one storage device 200. Of course, the snapshot interval of each storage device 200 can be determined to be once a day, or even the snapshot interval is 0 (data protection is not currently required).

Although the above embodiment collects data from a cloud service system for training and updating the life expectancy model and the next 7-day damage probability model, it is not necessary to apply only these models to the cloud service system. In a wider range of applications, the life expectancy model and the 7th damage probability model can be trained in a data center or cloud service system and then applied to other cloud service systems with the same or similar configuration of storage devices. The advantages of the method are achieved with limited resources.

Although the present invention has been disclosed in the above embodiments, it is not intended to limit the invention, and those skilled in the art can make some modifications and refinements without departing from the spirit and scope of the invention. The scope of the invention is defined by the scope of the appended claims.

Claims (15)

A method for data protection in a cloud service system, comprising the steps of: A. collecting historical operation data of a plurality of storage devices in the cloud service system; B. establishing a life expectation model and using the collected historical operation data 7th damage probability model, in which the storage devices are classified as good and damaged, the damaged storage devices in the storage devices are classified into different life ranges, and the good storage devices in the storage devices are set For a specific life range, the historical operation data in the storage devices are binned according to the life ranges, and are divided into a plurality of groups, each group representing a different life range, and all of the plurality of The operational data from each storage device in the group is normalized to establish the life expectancy model; C. The operational data of each storage device in the past 24 hours is stored in the life expectancy model and the 7th damage probability model. To obtain the expected life range and corresponding damage probability in each group; and D. Back up the data in the storage devices according to the result of step C The 7-day damage probability model is established by the following steps: sorting the historical operation data; from the damaged storage device and a plurality of randomly selected good storage devices, the data is obtained within 7 days from the time of the recent collection. Information on the operation of storage equipment; and The operational data from each storage device is normalized. The method of claim 1, wherein the operational data is performance data, SMART (Self-Monitoring Analysis and Reporting Technology) data, available capacity of the storage devices, and the storage The total capacity of the device, or device metadata. The method of claim 2, wherein the performance data is delay time, throughput, CPU (Central Processing Unit) load, memory usage, or IOPS (Input/Output Per Second, each Second input/output operation times). The method of claim 1, wherein the storage device is a hard disk or a solid state hard disk. The method of claim 1, wherein the life expectancy model and the seventh-day damage probability model are continuously updated with operational data newly collected in the future. The method of claim 1, wherein the historical operation data of the storage device is collected at an interval of one hour. The method of claim 1, wherein the ratio of the storage device used to collect the damage of the operational data to the good storage device within 7 days from the point of recent collection is 1:1. The method of claim 1, further comprising the step of: A1. Collecting historical operation data of the storage device, wherein the storage devices are brand new or just joined the cloud service system. The method of claim 1, wherein the life expectancy model uses an ANN (Artificial Neural Network) algorithm to calculate the input of the past 24 hours of operational data and historical operational data to predict the The range of life expectancy. The method of claim 1, wherein the 7-day damage probability model calculates the input operation data and historical operation data of the past 24 hours by an ANN algorithm to predict a corresponding damage probability. The method of claim 1, wherein the step D further backs up data in a storage device having an expected life of less than a corresponding specific lifetime and/or having a probability of damage exceeding a certain percentage. The method of claim 1, wherein the step D further performs backup of the data in the storage device by performing a snapshot job having the calculated snapshot interval. The method of claim 12, wherein the snapshot time interval is calculated by inputting the result of step C into a fuzzy system. The method of claim 13, wherein the fuzzy system is formed by the following steps: E1. defining language values for the bins, damage probability, and snapshot time interval; E2. Construct a membership function to describe all the grading, damage probability, and the extent of the snapshot interval; and E3. Construct fuzzy rules for the grading, damage probability, and snapshot interval. The method of claim 14, wherein the fuzzy system comprises an operation step: F1. receiving a classification and a probability of damage; F2. performing a fuzzy by inputting the classification and damage probability to a membership function of the fuzzy rules to perform blurring , fuzzy reasoning, and summary of results; and F3. Defuzzification to get a snapshot time interval.