DB FILE BACKUP METHOD AND APPARATUS, AND ELECTRONIC DEVICE

A database (DB) file backup method and apparatus, and an electronic device are provided. The method includes: an electronic device segments a DB file, to obtain local subfiles of the DB file, obtains a first local subfile from the local subfiles, and uploads the first local subfile to a server, where the first local subfile is a local subfile that does not have a corresponding server side subfile in the server; and/or obtains a second local subfile from the local subfiles, and uploads the second local subfile to the server, where the second local subfile is a local subfile that has a corresponding server side subfile in the server and that corresponds to a content comparison result indicating that the second local subfile and the corresponding server side subfile are inconsistent. In this case, a local subfile whose content does not change is not uploaded each time.

TECHNICAL FIELD

This application relates to the field of intelligent terminal technologies, and in particular, to a database (DB) file backup method and apparatus, and an electronic device.

BACKGROUND

To make an overall cloud backup, system data and application data on an electronic device of a user need to be backed up in the cloud, so that after the user replaces the device or the device is restored to a factory setting, the user can restore, on the electronic device to a maximum extent, data previously generated when the electronic device is used. Backup performance is a very important point in a cloud backup solution.

A file type in the application data includes a txt file, a photo file, a music file, a video file, a DB file, or the like. For a file that does not change frequently, for example, a photo file, a music file, or a video file, in a cloud backup method in the conventional technology, an amount of data that is subsequently backed up again can be effectively reduced. However, for a DB file that stores data in a database, there is almost no performance gain in the cloud backup method in the conventional technology, and each time a backup is made again, the DB file needs to be backed up, and a long backup time period is required.

SUMMARY

This application provides a DB file backup method and apparatus, and an electronic device, to optimize DB file backup performance.

According to a first aspect, an embodiment of this application provides a DB file backup method, including:

An electronic device segments a DB file, to obtain a local subfile of the DB file, where the DB file includes a plurality of file blocks, each local subfile includes at least one file block, and the file block is a storage unit of the DB file;the electronic device obtains a first local subfile from the local subfile, and uploads the first local subfile to a server, where the first local subfile is a local subfile that does not have a corresponding server side subfile in the server; and/orthe electronic device obtains a second local subfile from the local subfile, and uploads the second local subfile to the server, where the second local subfile is a local subfile that has a corresponding server side subfile in the server and that corresponds to a content comparison result indicating that the second local subfile and the corresponding server side subfile are inconsistent.

The local subfile and a corresponding server side subfile occupy a same file block.

The electronic device may include a device such as a mobile terminal (mobile phone), a computer, a PAD, a wearable device, a smart screen, a drone, an intelligent connected vehicle (ICV), an intelligent vehicle (car) (smart/intelligent car), or a vehicle-mounted device.

In the method, only the first local subfile that does not have a corresponding server side subfile in the server and/or the second local subfile whose content changes are/is uploaded each time, and a local subfile whose content does not change is not uploaded. Compared with the conventional technology in which the entire DB file is uploaded, in the method, an amount of data that is uploaded from the DB file is reduced, and DB file backup performance is optimized.

Before the electronic device obtains the first local subfile and/or the second local subfile from the local subfile, the method further includes:

The electronic device generates a local file list based on the local subfile, and obtains a server side file list of the DB file.

That the electronic device obtains a first local subfile and/or a second local subfile from the local subfile includes:

The electronic device obtains the first local subfile and/or the second local subfile from the local subfile based on the local file list and the server side file list.

In the method, the first local subfile and the second local subfile are obtained based on the local file list and the server side file list.

The local file list includes a file ID of the local subfile, and the server side file list includes a file ID of the server side subfile.

That the electronic device obtains the first local subfile from the local subfile based on the local file list and the server side file list includes:

The electronic device obtains, from the local subfile, a local subfile whose file ID exists only in the local file list, and uses the local subfile as the first local subfile.

Therefore, the first local subfile is obtained from the local subfile.

The local file list includes a file ID and a file fingerprint of the local subfile, and the server side file list includes a file ID and a file fingerprint of the server side subfile.

That the electronic device obtains the second local subfile from the local subfile based on the local file list and the server side file list includes:

The electronic device obtains a local subfile whose file ID exists in both the local file list and the server side file list and whose file fingerprints corresponding to the file ID are inconsistent, and uses the local subfile as the second local subfile.

Therefore, the second local subfile is obtained from the local subfile.

The server side file list is stored in the electronic device, and after the electronic device uploads the first local subfile and/or the second local subfile to the server, the method further includes:

The electronic device updates, based on the local file list, the server side file list stored in the electronic device.

The server side file list is stored in the electronic device, to reduce data exchange between the electronic device and the server, and improve DB file backup efficiency.

Before the electronic device segments the DB file, to obtain the local subfile of the DB file, the method further includes:

The electronic device obtains the server side file list of the DB file, where the server side file list includes a file block ID of a file block occupied by a server side subfile of the DB file.

That an electronic device segments a DB file, to obtain a local subfile of the DB file includes:

The electronic device determines whether a file block other than a first file block exists in the DB file, where the first file block is a file block corresponding to the file block ID included in the server side file list; andif a file block other than the first file block exists, the electronic device classifies the file block other than the first file block according to a preset rule, and classifies the first file block based on the server side file list; orif no file block other than the first file block exists, the electronic device segments the DB file based on the server side file list.

Therefore, classification of a file block whose file block ID is recorded in the server side file list of the DB file based on the server side file list.

According to a second aspect, an embodiment of this application provides an electronic device, including:one or more processors, a memory, and one or more computer programs, where the one or more computer programs are stored in the memory, the one or more computer programs include instructions, and when the instructions are executed by the device, the device is enabled to perform the following steps:segmenting a DB file, to obtain a local subfile of the DB file, where the DB file includes a plurality of file blocks, each local subfile includes at least one file block, and the file block is a storage unit of the DB file;obtaining a first local subfile from the local subfile, and uploading the first local subfile to a server, where the first local subfile is a local subfile that does not have a corresponding server side subfile in the server; and/orobtaining a second local subfile from the local subfile, and uploading the second local subfile to the server, where the second local subfile is a local subfile that has a corresponding server side subfile in the server and that corresponds to a content comparison result indicating that the second local subfile and the corresponding server side subfile are inconsistent.

The local subfile and a corresponding server side subfile occupy a same file block.

When the instructions are executed by the device, before the device is enabled to obtain the first local subfile and/or the second local subfile from the local subfile, the device further performs the following step:

generating a local file list based on the local subfile, and obtaining a server side file list of the DB file.

That the device is enabled to perform the step of obtaining a first local subfile and/or a second local subfile from the local subfile includes:

obtaining the first local subfile and/or the second local subfile from the local subfile based on the local file list and the server side file list.

The local file list includes a file ID of the local subfile, and the server side file list includes a file ID of the server side subfile.

When the instructions are executed by the device, that the device is enabled to perform the step of obtaining the first local subfile from the local subfile based on the local file list and the server side file list includes:

obtaining, from the local subfile, a local subfile whose file ID exists only in the local file list, and using the local subfile as the first local subfile.

The local file list includes a file ID and a file fingerprint of the local subfile, and the server side file list includes a file ID and a file fingerprint of the server side subfile.

When the instructions are executed by the device, that the device is enabled to perform the step of obtaining the second local subfile from the local subfile based on the local file list and the server side file list includes:obtaining a local subfile whose file ID exists in both the local file list and the server side file list and whose file fingerprints corresponding to the file ID are inconsistent, and using the local subfile as the second local subfile.

The server side file list is stored in the electronic device, and when the instructions are executed by the device, after the electronic device is enabled to perform the step of uploading the first local subfile and/or the second local subfile to the server, the device further performs the following step:updating, based on the local file list, the server side file list stored in the electronic device.

When the instructions are executed by the device, before the device is enabled to perform the step of segmenting a DB file, to obtain a local subfile of the DB file, the device further performs the following step:obtaining the server side file list of the DB file, where the server side file list includes a file block ID of a file block occupied by a server side subfile of the DB file.

Correspondingly, that the device is enabled to perform the step of segmenting a DB file, to obtain a local subfile of the DB file includes:determining whether a file block other than a first file block exists in the DB file, where the first file block is a file block corresponding to the file block ID included in the server side file list; andif a file block other than the first file block exists, classifying the file block other than the first file block according to a preset rule, and classifying the first file block based on the server side file list; orif no file block other than the first file block exists, segmenting the DB file based on the server side file list.

According to a third aspect, an embodiment of this application provides a database DB file backup system, including an electronic device and a server.

The electronic device is configured to perform the method in the first aspect.

The server is configured to store a server side subfile of a DB file.

According to a fourth aspect, an embodiment of this application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is run on a computer, the computer is enabled to perform the method in the first aspect.

According to a fifth aspect, this application provides a computer program. When the computer program is executed by a computer, the computer is configured to perform the method in the first aspect.

In a possible design, the program in the fifth aspect may be all or partially stored in a storage medium that is packaged with a processor, or may be partially or all stored in a memory that is not packaged with a processor.

DETAILED DESCRIPTION

Terms used in embodiments of this application are only used to explain exemplary embodiments of this application, but are not intended to limit this application.

In the conventional technology, a file type in application data includes a txt file, a photo file, a music file, a video file, a DB file, or the like. The DB file is a special type of file. Special features of the DB file are mainly represented as follows:

First, there is high utilization. Data of almost all applications needs to be stored. The DB file is first selected to store structured data. In other words, DB files of almost all the applications need to be backed up during a backup.

Second, the DB file frequently changes. Different from a file such as a photo or a video that is not modified once generated, a DB file of an application changes provided that data of the application is added, deleted, or modified. An application WeChat is used as an example. The DB file is used to store a chatting record and a trend in Moments of WeChat. The DB file changes provided that a new message is received or sent or there is a trend in Moments. In other words, the DB file usually needs to be re-uploaded during a backup of application data.

Third, DB files of some super applications have a large size. The application WeChat is used as an example. The DB file is usually more than 1G. Consequently, a long time period needs to be taken when the DB file is uploaded.

In the conventional technology, uploading is performed in a unit of file. After being successfully uploaded for a first time, a file such as a photo or a video that does not frequently change does not need to be re-uploaded during a subsequent backup. Therefore, a backup method in the conventional technology is effective for the file such as the photo or the video that does not frequently change. However, after a DB file that frequently changes is successfully uploaded for a first time, the DB file still needs to be re-uploaded if the DB file changes during a subsequent backup. Therefore, in the conventional technology, there is almost no performance gain for a backup of the DB file that frequently changes. The application WeChat is used as an example. During the backup of the application data, information such as the chatting record of WeChat is stored in the DB file. The DB file usually changes. In addition, the DB file becomes larger as a user uses the application for a longer time period. Therefore, each time a backup is made again, the DB file needs to be backed up, and a long backup time period is required.

Therefore, the DB file that frequently changes is usually a key problem limiting backup performance.

Therefore, embodiments of this application provide a DB file backup method and apparatus, and an electronic device, to optimize DB file backup performance.

It should be noted that, the DB file backup method in embodiments of this application is applicable to a backup of a DB file, for example, a cloud backup of the DB file, or a cloud backup of the DB file in an overall cloud backup.

To better understand the technical solutions in embodiments of this application, terms appearing in embodiments of this application are first explained by way of illustration but not limitation.

A DB file is a file used by an application on an electronic device to store data in a database, and is usually used to store structured data, to implement efficient data management, retrieval, or the like.

SQLite is a lightweight database system, is currently applied to many embedded products, is also widely applied to an Android platform, and is a mainstream database used by the application on the electronic device.

Cloud backup: The cloud backup is to store backup data of an electronic device of a user by using a cloud storage capability, to avoid a case in which backup data of a local backup of the electronic device may be damaged or lost due to damage to a disk or a loss of the device.

A file fingerprint is a feature value that is strongly related to file content and that is generated for a file based on an algorithm. The file fingerprint correspondingly changes when the file content changes. The file and another file may be distinguished based on the file fingerprint. The algorithm may include but is not limited to hash-based message authentication code (HMAC), message-digest algorithm (MD5), a hash algorithm, or the like. For example, the file fingerprint that is of a file and that is obtained through calculation for the file based on a hash algorithm may be referred to as a hash value of the file, and the file and another file may be distinguished based on the hash value.

The following describes a storage principle of a DB file.

From a perspective of an upper layer, a database manages data in a dimension such as a table or a record. For an application that uses the database, a database manipulation language such as structured query language (SQL) may be used to quickly and conveniently search for and operate a specified record.

However, from a perspective of a bottom-layer implementation of the database, data in the database is still stored in a file, and the file that stores the data in the database is referred to as a DB file. The DB file includes a file block. A record in the database is stored in the file block. The file block is a basic unit of storage in the database. Usually, one file block may store many records. Specifically, the DB file may include several file blocks. When a storage capacity of the file block included in the DB file is insufficient, a file block may be newly added to the DB file at the end of the file block included in the DB file. An operation such as deletion or modification performed on the record in the database is an operation performed on the record in the file block, and does not cause deletion of the file block.

A database system usually establishes an index of the file block in a form of a B+ tree that is convenient for a quick query, to quickly locate, based on a specific condition, a file block in which a record is located, and then perform a specific read/write operation on data in the file block. For example, the B+ tree is shown inFIG.1. For a DB file whose file name is yy.db, and a record or a table that is of the database and that is stored in the file block is recorded under an ID of each file block.

A database system SQLite is used as an example. SQLite is a mainstream database used by an application on an electronic device. Data stored in SQLite is also stored in a DB file. For example, for a super application such as WeChat or Weibo, structured data of the application is stored by using SQLite. A bottom-layer storage structure of SQLite is analyzed, and it is found that SQLite is the same as most relational databases, and at a bottom layer, a record is stored by using a file block, and is managed by using the B+ tree. The DB file that stores the data in SQLite is used as an example below, to describe a storage principle of the DB file.

The file block in SQLite is referred to as a page. In SQLite, two bytes starting from an offset location 16 of a DB file header are used to mark a page size of a current DB file. Table 1 shows a DB file format on an SQLite official website. After the database is successfully initialized, records are organized and stored based on the page size. The page size may be set by an application using SQLite, and the page size is 2 to the power of n between 512 and 65536.

TABLE 1OffsetSizeDescription016Header string: “SQLite format 3\000”162A page size of a database is in a unit of a byte. The size is 2 to the power of n between 512 and 65536.

FIG.2is a schematic diagram of storage of a DB file in SQLite. Herein, n pages are allocated to the DB file, n is a natural number, and one grid represents one page. A page filled with oblique lines indicates that the page is filled with a value, in other words, the page stores data. A page filled with no oblique line indicates that the page is filled with no value, in other words, the page stores no data. In SQLite, the page filled with no value is referred to as a free page. The free page may not be filled with a value once after being allocated to the DB file, or the free page may be originally filled with a value, and the filled value is deleted in a change process of the DB file.

FIG.3is a schematic diagram of a storage change process of a DB file in SQLite.

In an initial state, an electronic device allocates several pages to the DB file, and manages, by using a free page linked list, all pages filled with no value. A quantity of pages initially allocated by the electronic device to each DB file is not fixed. In other words, the quantity of pages specifically and initially allocated to the DB file may be set based on an actual application situation. This is not limited in this embodiment of this application. As shown inFIG.3, that eight pages are initially allocated to the DB file is used as an example. All pages initially allocated to the DB file are filled with no value, and the free page linked list is 1-2-3-4-5-6-7-8.

After the DB file starts to be used, a quantity of pages included in the DB file may be the same as or more than the quantity of initially allocated pages. To be specific, when a database starts to be created, the electronic device allocates a specified quantity of pages to the DB file, for example, eight pages shown inFIG.3. After the database starts to be used, if a storage capacity of the DB file meets a storage requirement of the database, the electronic device may not allocate a new page to the DB file, and only the initially allocated page is used for the DB file. In this case, the quantity of pages included in the DB file is the same as the quantity of initially allocated pages. Alternatively, as the database is used, more data needs to be stored in the DB file, the initially allocated page cannot meet a storage requirement of the DB file, and the electronic device may continue to allocate a new page to the DB file, so that the quantity of pages included in the DB file increases. For example, as shown inFIG.3, the quantity of pages included in the DB file gradually increases from 8 to 32. When the electronic device allocates a new page to the DB file, a new page is usually added at the end of the page included in the DB file. For example, as shown inFIG.3, the DB file initially includes eight pages, and the eight pages are respectively a page 1 to a page 8. Then, if a new page is allocated to the DB file, for example, if four new pages are allocated, four new pages, namely, a page 9 to a page 12 shown inFIG.3are added after a last page, namely, the page 8. Subsequently, if another new page is allocated to the DB file, for example, 10 new pages are allocated, 10 new pages, namely, a page 13 to a page 22 shown inFIG.3are added after a last page, namely, the page 12, and so on. Details are not described again.

In a use process of the database, when data needs to fill the DB file, one page is selected from the free page linked list, and a record fills the page. If a page is released subsequently when a record is deleted, the page is added to the free page linked list again. For example, as shown inFIG.3, after the database is used for a period of time, the free page linked list may change to 3-7-8-9-10-25-26-27-31-32.

In conclusion, when the storage capacity of the DB file is sufficient and the electronic device does not need to allocate a new page to the DB file, each time an operation such as addition, deletion, or modification is performed on a record in the database, so that content in the DB file changes, only content stored in one or more pages included in the DB file changes actually, and the quantity of pages included in the DB file does not change.

The foregoing describes the storage principle of the DB file.

The following describes embodiments of this application.

FIG.4is an example diagram of a system architecture to which a DB file backup method is applicable according to an embodiment of this application. The system architecture includes an electronic device41and a server42.

The electronic device41may include a device such as a mobile terminal (mobile phone), a computer, a personal access device (PAD), a wearable device, a smart screen, a drone, an intelligent connected vehicle (ICV), an intelligent vehicle (car) (smart/intelligent car), or a vehicle-mounted device.

The server42may be one server, or a server cluster including a plurality of servers. This is not limited in this application. Preferably, the server42may be a cloud server.

The electronic device41and the server42may be connected through a network, and the network may be a wired network or a wireless network.

The following provides an example description of the DB file backup method in this embodiment of this application by using a cloud backup of the electronic device as an example. In this case, the server in the following description may be a cloud server.

Usually, the electronic device41starts a cloud backup of a DB file. Specifically, an occasion on which the electronic device starts the cloud backup of the DB file may include but is not limited to the following two cases:Case 1: The electronic device41starts an overall cloud backup, and correspondingly, the electronic device41starts the cloud backup of the DB file.Case 2: The electronic device41receives a cloud backup instruction for the DB file, and correspondingly, the electronic device41starts the cloud backup of the DB file. A user may send the instruction by performing an operation, and the operation may include but is not limited to clicking a button of starting the cloud backup of the DB file, setting timing of starting the cloud backup of the DB file, or the like. Alternatively, an application to which the DB file belongs may send, according to a preset rule in the application, an instruction for the cloud backup of the DB file, or the like. This is not limited in this application.

In this embodiment of this application, when making a cloud backup of the DB file for a first time, the electronic device41segments the DB file into subfiles. The subfile is referred to as a local subfile in this embodiment of this application. The local subfile is uploaded to the server42. The server42stores a received local subfile. The local subfile stored in the server42becomes a cloud subfile of the DB file. Then, when making cloud backup of the DB file again, the electronic device41still segments the DB file into local subfiles. For a local subfile that does not have a corresponding cloud subfile, the electronic device41directly uploads the local subfile to the server42. For a local subfile that has a corresponding cloud subfile, the electronic device41makes a content comparison between the local subfile and the corresponding cloud subfile in the server42. If a comparison result is that the local subfile and the corresponding cloud subfile are consistent, it indicates that content of the local subfile does not change, and the electronic device41does not upload the local subfile. If a comparison result is that the local subfile and the corresponding cloud subfile are inconsistent, it indicates that content of the local subfile changes, and the electronic device41uploads the local subfile to the server42, and updates the corresponding cloud subfile in the server42.

Through the foregoing processing, the electronic device41implements the cloud backup of the DB file. In addition, the electronic device41uploads only a local subfile that does not have a corresponding cloud subfile and/or a local subfile whose content changes, and does not need to upload a local subfile whose content does not change. Compared with the conventional technology in which the entire DB file is uploaded, in this embodiment, an amount of data that is uploaded when the cloud backup of the DB file is made is reduced, a cloud backup time period of the DB file is further reduced, and cloud backup performance of the DB file is improved.

The electronic device41segments the DB file based on a file block occupied by a DB file in a storage principle of the DB file. The file block is a basic unit of storage in the DB file.

Each local subfile includes at least one file block, and a quantity of file blocks included in each local subfile is not limited in this application.

The following describes a possible implementation in which the electronic device segments the DB file.

Different local subfiles may have a same size or different sizes, which is related to a segmentation rule of the DB file. Details are as follows.

In a possible implementation, the DB file may be equally segmented into several local subfiles based on an integer multiple of a quantity of file blocks. For example, it is assumed that the electronic device41presets that each local subfile includes n file blocks, where n is a natural number. Correspondingly, the DB file may be segmented into several local subfiles whose sizes each are n file blocks. As shown inFIG.5a, if a value of n is 4, and the DB file includes 16 file blocks, the DB file may be segmented into four local subfiles of an equal size. It should be noted that, in this embodiment of this application, equal segmentation may be approximately equal segmentation. For example, if a total quantity of file blocks included in the DB file cannot be exactly divided by n, a quantity of file blocks included in a last local subfile may be less than n. For example, as shown inFIG.5b, if n is 3, in other words, the DB file is segmented into local subfiles whose sizes each are three file blocks, and the DB file includes eight file blocks, the DB file is finally segmented into three local subfiles, a 1stlocal subfile and a 2ndlocal subfile each include three file blocks, and a 3rdlocal subfile includes two file blocks.

In another possible implementation, the DB file may be segmented into several local subfiles whose sizes are not the same or are not completely the same. This segmentation rule may indicate definite regularity or may indicate disorder. For example, it is assumed that the DB file includes 16 file blocks. Referring toFIG.5c, the DB file may be segmented into four local subfiles. A 1stlocal subfile includes three file blocks, a 2ndlocal subfile includes five file blocks, a 3rdlocal subfile includes three file blocks, and a 4thlocal subfile includes five file blocks. It can be learned that in this segmentation rule, regularity is that 3 and 5 sequentially and cyclically occur, and this segmentation rule is a segmentation rule indicating definite regularity. Referring toFIG.5d, the DB file may be segmented into five local subfiles. A 1stlocal subfile includes one file block, a 2ndlocal subfile includes two file blocks, a 3rdlocal subfile includes five file blocks, a 4thlocal subfile includes four file blocks, and a 5thlocal subfile includes four file blocks. This is a segmentation rule indicating no regularity.

It should be noted that it is easier to implement equal segmentation of the DB file. However, even if the DB file is not segmented based on an equal segmentation principle, a requirement in this embodiment of this application is met, and file backup performance is optimized in this embodiment of this application. In an actual application, a specific segmentation rule for segmenting the DB file is not limited in this application, provided that a same file block is obtained by segmenting the DB file based on a same segmentation rule each time a cloud backup of a same DB file is made, to ensure that a same file block still belongs to a same subfile. For example, file blocks 1 to 16 of the DB file are classified in a manner shown inFIG.5dfor a first time, and then the file blocks 1 to 16 of the DB file are still classified in the manner shown inFIG.5deach time, to ensure that the file block 1 is always in one local subfile, file blocks 2 to 3 are always in one local subfile, and so on, so that a content comparison between a local subfile and a corresponding cloud subfile can be made.

It should be noted that, a newly added file block of the DB file may be classified according to a segmentation rule the same as that of an original file block of the DB file, or may be classified according to a segmentation rule different from that of an original file block of the DB file, and a newly added file block also needs to be classified according to a same segmentation rule each time a cloud backup is made. For example, it is assumed that the DB file initially includes eight file blocks, namely, file blocks 1 to 8, and the eight file blocks are classified into two subfiles based on a case in which each subfile includes four file blocks. Then, 24 file blocks, namely, file blocks 9 to 32 are newly added to the DB file, and the file blocks 9 to 32 may be classified into six subfiles according to a segmentation rule in which each subfile includes 4 file blocks and that is the same as that of the file blocks 1 to 8, or may be classified according to another segmentation rule, for example, may be classified into four subfiles according to a segmentation rule in which each subfile includes six file blocks. However, for the file blocks 9 to 32, a same segmentation rule is preferably used each time a cloud backup of the file blocks 9 to 32 is made, to ensure that a same file block belongs to a same subfile each time a cloud backup is made. For example, it is assumed that when the file blocks 9 to 32 are classified for a first time, the file blocks 9 to 32 are classified according to the segmentation rule in which each subfile includes six file blocks. Therefore, when a cloud backup is made subsequently, and the file blocks 9 to 32 are classified again, the file blocks 9 to 32 are preferably still classified according to the segmentation rule in which each subfile includes six file blocks.

In this embodiment of this application, when segmenting the DB file, the electronic device41segments the DB file based on the file block included in the DB file in the storage principle of the DB file. Specifically, each local subfile obtained by segmenting the DB file includes an integral quantity of file blocks. Through segmentation, each local subfile includes an integer multiple of a plurality of complete file blocks without damage to a data structure and coherence of the file block in the DB file.

Because of a characteristic that the DB file stores a record and a table in the database based on a file block, an operation such as addition, deletion, or modification performed on a record in the DB file is an operation performed on data in a file block storing the record. Data in a file block in the DB file does not change due to modification performed on another file block. In other words, modification performed on one file block does not affect adaptive modification performed on another file block. Therefore, a change in the record in the database is usually represented as a change in content of the file block storing the record in the DB file. Content of another file block remains unchanged. Based on the foregoing principle, the DB file is segmented into subfiles, and when a cloud backup is made based on the subfiles, only a subfile including a newly added file block and/or a subfile including a file block whose content changes is backed up. Compared with the conventional technology in which the entire DB file is uploaded, in this embodiment, an amount of data that is uploaded when a cloud backup of the DB file is made can be effectively reduced, a cloud backup time period of the DB file is further reduced, and cloud backup performance of the DB file is improved.

In addition, because of the characteristic that the DB file stores the record and the table in the database based on the file block, when the DB file is segmented into subfiles, and a cloud backup is made based on only the subfile, a problem that data of the subfile and data of adjacent subfiles are inconsecutive due to a backup of a subfile is not caused. When the electronic device re-obtains the cloud subfile of the DB file from the server, the electronic device may directly and sequentially concatenate cloud subfiles, to obtain the complete DB file.

FIG.6is a possible diagram of a structure of an electronic device according to an embodiment of this application. An electronic device600includes a processor610, an internal memory621, an antenna1, an antenna2, a mobile communications module650, and a wireless communications module660. Optionally, the electronic device600may further include an external memory interface620, a universal serial bus (USB) port630, a charging management module640, a power management unit641, a battery642, an audio module670, a speaker670A, a receiver670B, a microphone670C, a headset jack670D, a sensor module680, a button690, a motor691, an indicator692, a camera693, a display694, a subscriber identity module (SIM) card interface695, or the like. The sensor module680may include a pressure sensor680A, a gyro sensor680B, a barometric pressure sensor680C, a magnetic sensor680D, an acceleration sensor680E, a distance sensor680F, an optical proximity sensor680G, a fingerprint sensor680H, a temperature sensor680J, a touch sensor680K, an ambient light sensor680L, a bone conduction sensor680M, or the like.

The controller may generate operation control signal based on instruction operation code and a time sequence signal, to complete control of instruction reading and instruction execution.

A memory may be further disposed in the processor610, and is configured to store instructions and data. In some embodiments, the memory in the processor610is a cache memory. The memory may store an instruction or data that has just been used or cyclically used by the processor610. If the processor610needs to use the instruction or the data again, the processor may directly invoke the instruction or the data from the memory. This avoids repeated access, reduces waiting time of the processor610, and improves system efficiency.

The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDL) and a serial clock line (SCL). In some embodiments, the processor610may include a plurality of groups of I2C buses. The processor610may be separately coupled to the touch sensor680K, a charger, a flash, the camera693, and the like through different I2C bus interfaces. For example, the processor610may be coupled to the touch sensor680K through the I2C interface, so that the processor610communicates with the touch sensor680K through the I2C bus interface, to implement a touch function of the electronic device600.

The I2S interface may be configured to perform audio communication. In some embodiments, the processor610may include a plurality of groups of I2S buses. The processor610may be coupled to the audio module670through the I2S bus, to implement communication between the processor610and the audio module670. In some embodiments, the audio module670may transmit an audio signal to the wireless communications module660through the I2S interface, to implement a function of answering a call through a Bluetooth headset.

The PCM interface may also be configured to perform audio communication, to sample, quantize, and encode an analog signal. In some embodiments, the audio module670may be coupled to the wireless communications module660through a PCM bus interface. In some embodiments, the audio module670may alternatively transmit an audio signal to the wireless communications module660through the PCM interface, to implement a function of answering a call through a Bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus, and is configured to perform asynchronous communication. The bus may be a two-way communications bus. The bus converts to-be-transmitted data between serial communication and parallel communication. In some embodiments, the UART interface is usually configured to connect the processor610and the wireless communications module660. For example, the processor610communicates with a Bluetooth module in the wireless communications module660through the UART interface, to implement a Bluetooth function. In some embodiments, the audio module670may transmit an audio signal to the wireless communications module660through the UART interface, to implement a function of playing music through a Bluetooth headset.

The MIPI interface may be configured to connect the processor610and a peripheral component such as the display694and the camera693. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), or the like. In some embodiments, the processor610communicates with the camera693through the CSI interface, to implement an imaging shooting function of the electronic device600. The processor610communicates with the display694through the DSI interface, to implement a display function of the electronic device600.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or a data signal. In some embodiments, the GPIO interface may be configured to connect the processor610and the camera693, the display694, the wireless communications module660, the audio module670, the sensor module680, or the like. The GPIO interface may alternatively be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, or the like.

The USB port630is a port that conforms to a USB standard specification, and may be specifically a mini USB port, a micro USB port, a USB type-C port, or the like. The USB port630may be configured to be connected to a charger to charge the electronic device600, or may be configured to transmit data between the electronic device600and a peripheral device, or may be configured to connect to a headset for playing audio through the headset. The port may be further configured to connect to another electronic device such as an augmented reality (AR) device.

It may be understood that an interface connection relationship between the modules that is shown in embodiments of the present disclosure is merely an example for descriptions, and does not constitute a limitation on the structure of the electronic device600. In some other embodiments of this application, different interface connection manners in the foregoing embodiments or a combination of a plurality of interface connection manners may alternatively be used for the electronic device600.

A wireless communications function of the electronic device600may be implemented by using the antenna1, the antenna2, the mobile communications module650, the wireless communications module660, the modem processor, the baseband processor, or the like.

The mobile communications module650may provide a solution to wireless communication including 2G/3G/4G/5G applied to the electronic device600. The mobile communications module650may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), and the like. The mobile communications module650may receive an electromagnetic wave through the antenna1, perform processing such as filtering or amplification on the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communications module650may further amplify a signal modulated by the modem processor, and convert the signal into an electromagnetic wave for radiation through the antenna1. In some embodiments, at least some functional modules in the mobile communications module650may be disposed in the processor610. In some embodiments, the at least some functional modules in the mobile communications module650and at least some functional modules in the processor610may be disposed in a same device.

The modem processor may include a modulator and a demodulator. The modulator is configured to modulate a to-be-sent low frequency baseband signal into a medium/high frequency signal. The demodulator is configured to demodulate a received electromagnetic wave signal into a low-frequency baseband signal. Then, the demodulator transmits the low-frequency baseband signal obtained through demodulation to the baseband processor for processing. The low-frequency baseband signal is processed by the baseband processor and then transmitted to the application processor. The application processor outputs a sound signal by an audio device (which is not limited to the speaker670A, the receiver670B, or the like), or displays an image or a video by the display694. In some embodiments, the modem processor may be an independent component. In some other embodiments, the modem processor may be independent of the processor610, and is disposed in a same device as the mobile communications module650or another functional module.

The wireless communications module660may provide a wireless communications solution that is applied to the electronic device600and that includes wireless local area networks (WLAN) (for example, a wireless fidelity (Wi-Fi) network), Bluetooth (BT), a global navigation satellite system (GNSS), frequency modulation (FM), a near field communication (NFC) technology, an infrared (IR) technology, and the like. The wireless communications module660may be one or more devices that integrate at least one communication processing module. The wireless communications module660receives an electromagnetic wave through the antenna2, performs frequency modulation and filtering processing on an electromagnetic wave signal, and sends a processed signal to the processor610. The wireless communications module660may further receive a to-be-sent signal from the processor610, perform frequency modulation and amplification on the signal, and convert a processed signal into an electromagnetic wave for radiation through the antenna2.

The internal memory621may be configured to store computer-executable program code. The executable program code includes instructions. The internal memory621may include a program storage area and a data storage area. The program storage area may store an operating system, an application required by at least one function (for example, a voice playing function or an image playing function), and the like. The data storage area may store data (for example, audio data and an address book) created in a process of using the electronic device600, and the like. In addition, the internal memory621may include a high-speed random access memory, or may include a nonvolatile memory, for example, at least one magnetic disk storage device, a flash memory, or a universal flash storage (UFS). The processor610executes various function applications and data processing of the electronic device600by running the instructions stored in the internal memory621and/or the instructions stored in the memory disposed in the processor.

The data storage area of the internal memory621may store a DB file in embodiments of this application.

In a possible implementation, a computer program for implementing a DB file backup method in embodiments of this application may be stored in the program storage area of the internal memory621, and the processor610invokes the computer program from the internal memory621for running. In a running process, the DB file is invoked from the internal memory621for processing, and the communication module such as the mobile communications module650or the wireless communications module660communicates with a server side, to implement a cloud backup of the DB file.

It should be understood that the electronic device600shown inFIG.6can implement processes of a DB file backup method provided in embodiments of this application. For details, refer to descriptions in the method embodiments shown inFIG.7toFIG.9ain this application. To avoid repetition, detailed descriptions are properly omitted herein.

Based on the foregoing system architecture and the structure of the electronic device, a flowchart in an embodiment of the DB file backup method in this application is shown inFIG.7. The method may include the following steps.

Step701: An electronic device segments a DB file, to obtain a local subfile of the DB file, where the DB file includes a plurality of file blocks, and each local subfile includes at least one file block.

For an implementation of this step, refer to the foregoing related descriptions of segmenting the DB file. Details are not described herein again.

Step702: The electronic device obtains a first local subfile from the local subfile, and uploads the first local subfile to a server, where the first local subfile is a local subfile that does not have a corresponding cloud subfile in the server; and/or the electronic device obtains a second local subfile from the local subfile, and uploads the second local subfile to the server, where the second local subfile is a local subfile that has a corresponding cloud subfile in the server and that corresponds to a content comparison result indicating that the second local subfile and the corresponding cloud subfile are inconsistent, where the local subfile and a corresponding cloud subfile occupy a same file block.

That the local subfile and the corresponding cloud subfile occupy a same file block is used to indicate an ownership relationship of a file block, and is unrelated to whether the file block stores data. For example, the local subfile occupies a file block 1, and it indicates that the file block 1 belongs to the local subfile. In other words, the local subfile includes the file block 1, and is unrelated to whether the file block 1 stores data.

That the local subfile and the corresponding cloud subfile occupy a same file block means that a file block included in the local subfile and a file block included in the corresponding cloud subfile are a same file block, and that the file block included in the local subfile and the file block included in the corresponding cloud subfile are a same file block herein is unrelated to whether data is stored in the file blocks and whether the file blocks store same data, and is only related to the file blocks. For example, it is assumed that a local subfile 1 includes only the file block 1 in the DB file and a cloud subfile 1 also includes only the file block 1 in the DB file. Therefore, the local subfile 1 and the cloud subfile 1 occupy a same file block. This is unrelated to whether data is stored in the file block 1 of the local subfile 1, whether data is stored in the file block 1 of the cloud subfile 1, and whether the file block 1 of the local subfile 1 and the file block 1 of the cloud subfile 1 store same data.

A content comparison made by the electronic device between the local subfile and the corresponding cloud subfile may be implemented by comparing file fingerprints of the two subfiles. Specifically, the two subfiles have same content if the file fingerprints are the same, and the two subfiles have different content if the file fingerprints are different.

In the method shown inFIG.7, the DB file is segmented into subfiles. Only a local subfile that does not have a corresponding cloud subfile in the server and/or a local subfile whose content changes are/is uploaded each time, and a local subfile whose content does not change is not uploaded. Compared with the conventional technology in which the entire DB file is uploaded, in the method, an amount of data that is uploaded from the DB file is reduced, and cloud backup performance of the DB file is optimized.

It can be learned from the descriptions of a segmentation rule of a DB file that the segmentation rule may indicate regularity, including the foregoing equal segmentation rule and the unequal segmentation rule indicating definite regularity. The following describes, by using an embodiment shown inFIG.8a, a possible implementation in embodiments of this application in an implementation in which the segmentation rule indicates regularity. Referring to a flowchart in the embodiment shown inFIG.8a, the method may include the following steps.

Step801: An electronic device starts a cloud backup of a DB file, determines whether a cloud backup of the DB file is made for a first time, and performs step802if the cloud backup of the DB file is made for the first time, or perform step804if the cloud backup of the DB file is not made for the first time.

In a possible implementation, to determine whether the cloud backup of the DB file is made for the first time, the electronic device may query whether a cloud file list of the DB file exists on a server side. The cloud file list of the DB file may be independently stored in the server, or may be used as a part of the cloud file list of the electronic device. If an occasion on which the electronic device starts the cloud backup of the DB file each time is usually that a cloud backup instruction for the DB file is received, the cloud file list of the DB file is usually independently stored in the server; or if an occasion on which the electronic device starts the cloud backup of the DB file each time is usually an overall cloud backup, the cloud file list of the DB file may be stored in the cloud file list of the electronic device, and is a part of the cloud file list of the electronic device.

In another possible implementation, a recent file list that is of the cloud backup of the DB file and that is uploaded to the cloud may be recorded in the electronic device. To determine whether the cloud backup of the DB file is made for the first time, the electronic device may query whether the electronic device stores the recent file list of the cloud backup of the DB file. Similarly, the file list may be independently stored, or may be used as a part of a file list that is of a recent overall cloud backup and that is uploaded to the cloud, which may be specifically related to an occasion on which the electronic device starts the cloud backup of the DB file.

In still another possible implementation, information about whether the cloud backup of the DB file is made may be recorded in the electronic device. To determine whether the cloud backup of the DB file is made for the first time, the electronic device may query the information. Similarly, the information may be independently stored, or may be indirectly implemented based on information that is about whether the overall cloud backup is made and that is recorded in the electronic device, which may be specifically related to an occasion on which the electronic device starts the cloud backup of the DB file.

Step802: The electronic device segments the DB file, to obtain a local subfile of the DB file, allocates a file identifier (ID, Identity) to each local subfile, calculates a file fingerprint of each local subfile, generates a local file list of the DB file based on the file ID and the file fingerprint, and sends the local subfile (namely, a first local subfile obtained by the electronic device) and the local file list to the server.

For an implementation in which the electronic device segments the DB file, to obtain the local subfile of the DB file, refer to corresponding descriptions in the foregoing embodiments. Details are not described herein again.

When allocating the file ID to the local subfile, the electronic device may allocate the file ID to the local subfile based on a ranking of a file block occupied by the local subfile. For example,FIG.5ais used as an example. It is assumed that the DB file is f4. Therefore, a file ID f41 may be allocated to a local subfile that occupies file blocks 1 to 4, a file ID f42 may be allocated to a local subfile that occupies file blocks 5 to 8, and so on. An arrangement ranking of the local subfile may be learned of based on the file ID of the local subfile, and further, an arrangement ranking of a file block in the local subfile may be learned of. The foregoing is merely an example. In an actual application, a specific rule for allocating the file ID to the local subfile is not limited in this application.

It should be noted that, for a same file block of a same DB file, a same segmentation rule and a same file ID allocation rule need to be followed each time a backup is made, so that each time the DB file is segmented, a same file ID is allocated to local subfiles occupying a same file block. Therefore, a cloud subfile that has a same file ID as the local subfile and that matches the local subfile in a subsequent step is a cloud subfile that correspondingly occupies a same file block as the local subfile, so that a subsequent content comparison is a comparison of whether data stored in the same file block is still the same. This content comparison is more meaningful. For example, referring toFIG.5a, it is assumed that the DB file is f4 and includes 16 file blocks. When the cloud backup is made for the first time, every four file blocks are classified into one local subfile, to obtain a local subfile f41 occupying file blocks 1 to 4, a local subfile f42 occupying file blocks 5 to 8, a local subfile f43 occupying file blocks 9 to 12, and a local subfile f44 occupying file blocks 13 to 16. Then, the local subfiles f41 to f44 are uploaded to the cloud. Therefore, when the DB file is segmented each time a cloud backup is made subsequently, a same segmentation rule and a same file ID allocation rule are preferably followed, so as to obtain the local subfiles f41 to f44 through segmentation. In a subsequent step, there are cloud subfiles that occupy a same file block, that have same file IDs as the local subfiles f41 to f44, and that respectively correspond to the local subfiles f41 to f44, and then a content comparison is made.

The local file list of the DB file may include a file ID and a file fingerprint of the local subfile. In a possible implementation, the local file list may be implemented in a form of a B+ tree. As shown inFIG.8b, the DB file has a name of f4, and is segmented into four local subfiles, the four local subfiles are respectively f41, f42, f43, and f44, and each local subfile corresponds to a respective file fingerprint.

In an actual application, the cloud backup of the DB file may be a part of the overall cloud backup. Therefore, the local file list of the DB file may be stored in a B+ tree of an electronic device, and is used as a part of the B+ tree of the electronic device, as shown inFIG.8c.

Step803: The server receives and stores the local subfile and the local file list. This process ends.

Step804: The electronic device obtains the cloud file list of the DB file from the server.

The cloud file list of the DB file may be a part of the cloud file list of the electronic device. If the occasion of starting the cloud backup of the DB file in step801is the overall cloud backup, in this step, the electronic device may obtain the cloud file list of the electronic device from the cloud, and further obtain the cloud file list of the DB file from the cloud file list of the electronic device. Alternatively, if the occasion of starting the cloud backup of the DB file in step701is that the cloud backup instruction for the DB file is received, and the cloud backup of the DB file is independently made, in this step, the electronic device may directly obtain the cloud file list of the DB file from the cloud.

Step805: Compare the local file list of the DB file and the cloud file list; for a file ID that exists only in the local file list and that does not exist in the cloud file list, upload, to the server, a local subfile (namely, the first local subfile obtained by the electronic device) identified by the file ID; for a file ID included in both the local file list and the cloud file list, determine, through comparison, whether file fingerprints of the file ID in the two file lists are the same; if file fingerprints of the file ID in the two file lists are not the same, upload, to the server, the local subfile (namely, a second local subfile obtained by the electronic device) identified by the file ID; upload the local file list to the server; and perform step806.

If the file ID exists only in the local file list and does not exist in the cloud file list, it indicates that a file block occupied by the local subfile corresponding to the file ID is a file block newly allocated by the electronic device to the DB file after a previous cloud backup. Therefore, the local subfile is directly uploaded. Otherwise, if the file ID exists in both the local file list and the cloud file list, it indicates that the local subfile and the cloud subfile that correspond to the file ID occupy a same file block. Therefore, a content comparison is made based on the file fingerprint, and whether to upload the local subfile is determined based on a comparison result.

Step806: The server receives the local subfile and the local file list, and updates the cloud subfile and the cloud file list.

In the method shown inFIG.8a, a same segmentation rule and a same file ID allocation rule are followed for a same file block in the DB file each time a cloud backup is performed, and a content comparison is made between a local subfile and a cloud subfile that have a same file ID, if the local subfile and the cloud subfile have same content, it indicates that content does not change, and the local subfile is not uploaded; and if the local subfile and the cloud subfile have different content, it indicates that content changes, and the local subfile is uploaded. In this way, the local subfile is selectively uploaded instead of uploading the entire DB file, to reduce an amount of data of the cloud backup of the DB file, and improve cloud backup performance of the DB file.

It can be learned from the descriptions of the segmentation rule of the DB file that the segmentation rule may indicate disorder. The following describes, by using an embodiment shown inFIG.9a, a possible implementation in embodiments of this application in an implementation in which the segmentation rule indicates disorder. Referring to a flowchart in the embodiment shown inFIG.9a, the method may include the following steps.

For an implementation of step901to step903, refer to step801to step803. A difference mainly lies in that an electronic device segments a DB file in a randomly disordered manner in step902. For example, for a quantity of file blocks included in each local subfile, a value is randomly selected from 1 to n, or the like, provided that the DB file is segmented into local subfiles.FIG.5dis still used as an example. The DB file may be segmented into the local subfiles in a completely disordered manner similar to the segmentation rule inFIG.5d.

Correspondingly, a local file list generated in step902may further include a file block ID of a file block occupied by a local subfile.FIG.5dis still used as an example. It is assumed that the local file list of the DB file is still implemented in a form of a B+ tree. Therefore, the local file list of the DB file may be shown inFIG.9b.

The following describes steps904to908that are performed when a determining result in step901is no, to be specific, is that a cloud backup of the DB file is not performed for a first time.

Step904: The electronic device obtains a cloud file list of the DB file from a server, determines whether a file block ID of a file block occupied by the DB file includes a file block ID that is not recorded in the cloud file list; and performs step905if the file block ID of the file block occupied by the DB file includes a file block ID that is not recorded in the cloud file list; or performs step906if the file block ID of the file block occupied by the DB file does not include a file block ID that is not recorded in the cloud file list.

Step905: For a file block whose file block ID is recorded in the cloud file list of the DB file, the electronic device segments the DB file based on the cloud file list, to obtain a local subfile and a file ID of each local subfile, and calculates a file fingerprint of each local subfile; for a file block whose file block ID is not recorded in the cloud file list of the DB file, the electronic device segments the DB file, to obtain a local subfile, allocates a file ID to the obtained local subfile, and calculates a file fingerprint of each local subfile; and the electronic device generates the local file list of the DB file, and performs step907.

An example is used to describe this step. It is assumed that the cloud file list of the DB file is shown inFIG.9b, and the DB file includes file blocks 17 to 32 in addition to file blocks 1 to 16. Therefore, the file blocks 1 to 16 in the DB file are classified into local subfiles of a structure shown inFIG.9c. However, the file blocks 17 to 32 may be classified into local subfiles, and a specific classification manner may be the same as or different from that of the file blocks 1 to 16, for example, may still be similar to disordered segmentation in step902. As shown inFIG.9c, it is assumed that the DB file is finally segmented into eight local subfiles shown inFIG.9c. Therefore, a created local file list is shown inFIG.9d.

Step906: The electronic device segments the DB file based on a file ID recorded in the cloud file list and a file block ID corresponding to the file ID, to obtain the local subfile and the file ID of each local subfile, generates the local file list of the DB file, and performs step907.

The examples in steps902to905are still used. The local file list generated in this step is still a structure shown inFIG.9b, and a difference lies in that the file fingerprints of the local subfiles may be different.

Step907: The electronic device compares the local file list of the DB file and the cloud file list; for a file ID that exists only in the local file list and that does not exist in the cloud file list, uploads, to the server, a local subfile (namely, the first local subfile obtained by the electronic device) identified by the file ID; for a file ID included in both the local file list and the cloud file list, determines, through comparison, whether file fingerprints of the file ID in the two file lists are the same; if file fingerprints of the file ID in the two file lists are not the same, uploads, to the server, the local subfile (namely, a second local subfile obtained by the electronic device) identified by the file ID; and uploads the local file list to the server. Step908is to be performed.

Step908: The server receives the local subfile and the local file list, and updates the cloud subfile and the cloud file list.

It should be noted that, although the method shown inFIG.9ais applicable to a case in which the segmentation rule is disordered in the foregoing descriptions, the method shown inFIG.9amay also be applicable to an implementation in which the segmentation rule indicates regularity. Compared with a method procedure shown inFIG.9a, a method procedure shown inFIG.8ais simpler and easier to implement.

It should be noted that, in embodiments of this application shown inFIG.8aandFIG.9a, the cloud file list of the DB file is stored in the server. In another possible implementation, the cloud file list of the DB file may be stored in the electronic device. In this case, for example, in step802, step804, step902, and step907, the electronic device does not need to upload the local file list to the server, but directly updates the cloud file list of the DB file in the electronic device based on the local file list. Correspondingly, for example, in step804and step904, the electronic device may directly obtain the cloud file list of the DB file from the electronic device, and does not need to obtain the cloud file list from the server, to reduce data exchange between the electronic device and the server, and further optimize cloud backup performance of the DB file.

It should be noted that, in the foregoing embodiments, the cloud backup of the DB file is used as an example to describe the DB file backup method in embodiments of this application. However, the DB file backup method in embodiments of this application may be extended to the backup of the DB file other than the cloud backup. In this case, the server in the foregoing embodiments may be extended from a cloud server to a server other than the cloud server, the cloud subfile may be extended to a server side subfile, and the cloud file list may be extended to the server side file list. For a specific implementation method, refer to the foregoing embodiments. Details are not described herein again.

It should be noted that, the DB file backup method in embodiments of this application may be further extended to a backup of a non-DB file. In other words, to make the backup of the non-DB file, the backup method in embodiments of this application may also be used.

It can be understood that some or all steps or operations in the foregoing embodiments are merely examples, and other operations or variations of various operations may be performed in embodiments of this application. In addition, steps may be performed in different sequences presented in the foregoing embodiments, and it is possible that not all operations in the foregoing embodiments need to be performed.

FIG.10is a schematic diagram of a structure in an embodiment of a DB file backup apparatus according to this application. As shown inFIG.10, the apparatus100may include:a segmentation unit101, configured to segment a DB file, to obtain a local subfile of the DB file, where the DB file includes a plurality of file blocks, each local subfile includes at least one file block, and the file block is a storage unit of the DB file; andan uploading unit102, configured to: obtain a first local subfile from the local subfile, and upload the first local subfile to a server, where the first local subfile is a local subfile that does not have a corresponding server side subfile in the server; and/or obtain a second local subfile from the local subfile, and upload the second local subfile to the server, where the second local subfile is a local subfile that has a corresponding server side subfile in the server and that corresponds to a content comparison result indicating that the second local subfile and the corresponding server side subfile are inconsistent.

The local subfile and a corresponding server side subfile occupy a same file block.

The uploading unit102may be further configured to: generate a local file list based on the local subfile, and obtain a server side file list of the DB file; and obtain the first local subfile and/or the second local subfile from the local subfile based on the local file list and the server side file list.

The local file list includes a file ID of the local subfile, and the server side file list includes a file ID of the server side subfile. The uploading unit102may be configured to: obtain, from the local subfile, a local subfile whose file ID exists only in the local file list, and use the local subfile as the first local subfile.

The local file list includes a file ID and a file fingerprint of the local subfile, and the server side file list includes a file ID and a file fingerprint of the server side subfile.

The uploading unit102may be configured to: obtain a local subfile whose file ID exists in both the local file list and the server side file list and whose file fingerprints corresponding to the file ID are inconsistent, and use the local subfile as the second local subfile.

The server side file list is stored in the apparatus, and the apparatus may further include:

an updating unit, configured to update, based on the local file list, the server side file list stored in the apparatus.

The segmentation unit101may be configured to: obtain the server side file list of the DB file, where the server side file list includes a file block ID of a file block occupied by a server side subfile of the DB file; determine whether a first file block exists in the DB file, where the first file block is a file block whose file block ID is not recorded in the server side file list; and if the first file block exists, classify the first file block according to a preset rule, and classify a file block other than the first file block in the DB file based on the server side file list; or if the first file block does not exist, segment the DB file based on the server side file list.

The apparatus provided in the embodiment shown inFIG.10may be configured to perform the technical solutions in the method embodiments shown inFIG.7toFIG.9ain this application. For implementation principles and technical effects thereof, refer to related descriptions in the method embodiments.

It should be understood that division into units in the apparatus shown inFIG.10is merely logical function division. In an actual implementation, all or some units may be integrated into one physical entity, or may be physically separated. In addition, these units may be all implemented in a form of calling software by a processing element, may be all implemented in a form of hardware, or may be partially implemented in a form of calling software by a processing element. Some units are implemented in a form of hardware. For example, a segmentation unit may be an independently disposed processing element, or may be integrated into a chip of an electronic device. An implementation of another unit is similar to this. In addition, all or some of these units may be integrated together, or may be implemented independently. In an implementation process, steps in the foregoing methods or the foregoing units can be implemented by using a hardware integrated logical circuit in the processing element, or by using instructions in a form of software.

For example, the foregoing units may be one or more integrated circuits configured to implement the foregoing methods, for example, one or more application-specific integrated circuits (ASIC), one or more microprocessors (Digital Signal Processor, DSP), or one or more field programmable gate arrays (FPGA). For another example, these units may be integrated together, and are implemented in a form of a system-on-a-chip (SOC).

The electronic device in this embodiment of this application may be a mobile phone, and the mobile phone may include one or more processors, a memory, and one or more computer programs. The one or more computer programs are stored in the memory, the one or more computer programs include instructions, and when the instructions are executed by the mobile phone, the mobile phone is enabled to perform the steps in the methods shown inFIG.7toFIG.9a.

This application further provides an electronic device. The device includes a storage medium and a central processing unit, the storage medium may be a nonvolatile storage medium, the storage medium stores a computer-executable program, and the central processing unit is connected to the nonvolatile storage medium, and executes the computer-executable program, to implement the methods provided in embodiments shown inFIG.7toFIG.9a.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is run on a computer, the computer is enabled to perform the methods provided in embodiments shown inFIG.7toFIG.9ain this application.

An embodiment of this application further provides a computer program product. The computer program product includes a computer program. When the computer program product runs on a computer, the computer is enabled to perform the methods provided in embodiments shown inFIG.7toFIG.9ain this application.

In embodiments of this application, “at least one” means one or more, and “a plurality of” means two or more. The term “and/or” describes an association relationship for describing associated objects and indicates that three relationships may exist. For example, A and/or B may indicate the following three cases: only A exists, both A and B exist, and only B exists. A and B may be singular or plural. The character “/” generally indicates an “or” relationship between the associated objects. At least one of the following items and similar expressions refer to any combination of the items, including a single item or any combination of plural items. For example, at least one of a, b, and c may represent a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, and c may be singular or plural.