Software maintenance method and device

Abstract

The invention relates to a software maintenance method and device. The method comprises the following steps: generating difference metadata according to a software upgrade package and a current version; generating incremental backup data according to the difference metadata, and storing the incremental backup data in a backup directory; recording the feature data of the backup in the backup data link file, adding the upgrade version node as a child node to the current version node in the version tree structure, and recording a change path between the nodes as a backup directory; and when the software needs to roll back, rolling back the software to the target version according to the version tree structure, the backup data link file and the change path. By the adoption of the method, only the changed incremental data are backed up in the software upgrading process, and the storage space occupied by the backup data is reduced; the relation between the versions in the software iteration process is established, cross-level rollback of the software versions is achieved, and convenience and reliability of software maintenance are improved.

Description

Technical Field

[0001] This application relates to the field of data storage and management technology, and in particular to a software maintenance method and apparatus. Background Technology

[0002] In various industries, software is reshaping business processes through automation, intelligence, and data. As software functionality has become richer, it has evolved from a mere "tool" into "infrastructure" driving social progress, making the stability, security, and continuous operation of software crucial requirements. However, while rapid technological advancements drive productivity, they also expose vulnerabilities in early software. Software upgrades have become a key means of addressing these issues, primarily used to fix security vulnerabilities, optimize performance, add new features, maintain compatibility, and avoid risks arising from compliance issues.

[0003] However, existing software upgrade technologies generally include full backup and OSTree upgrade technologies. Full backup technology involves performing a full backup of the file system before the software upgrade and then performing the software upgrade operation (restoring to the pre-upgrade state if the upgrade fails). This technology requires saving a complete system snapshot, resulting in significant storage space waste, and it cannot support cross-level rollback, only rolling back to the last backup state. Therefore, it lacks an effective handling mechanism in the event of consecutive upgrade failures. OSTree upgrade technology is a Git-like content-addressable file system that uses an immutable file system design. It updates the system through atomic commits, avoiding direct modification of existing files and generating new commits for content-addressable storage, reducing redundant storage. However, this technology is mainly geared towards operating system-level upgrades, with weak support for the application layer. Rollback also relies on pre-stored version commits; if historical versions are cleaned up, rollback is impossible, offering limited storage optimization and still requiring the storage of multiple complete versions. In conclusion, building a software maintenance technology that supports incremental backup and cross-version rollback is of great significance. Summary of the Invention

[0004] Therefore, it is necessary to provide a software maintenance method and apparatus to address the aforementioned technical problems, so as to lightweight backup data and support cross-version rollback of software.

[0005] In a first aspect, this application provides a software maintenance method, the method comprising: Generate difference metadata based on the software upgrade package and the current version; Based on the difference metadata, generate incremental backup data and store it in the backup directory; The backup data chain file records the characteristic data of this backup, and in the version tree structure, the upgrade version node is added as a child node under the current version node, and the change path between nodes is recorded as the backup directory; the characteristic data includes the summary value of the incremental backup data; When software needs to be rolled back, it is rolled back to the target version based on the version tree structure, backup data chain files, and changed paths.

[0006] In one embodiment, difference metadata is generated based on the software upgrade package and the current version, including: Get the first file list of the software upgrade package, and the second file list of the current version; Compare each file in the first file list with the corresponding file in the second file list; Based on the file comparison results, record the reference relationship data of the unchanged file content, and the description data of the changed file content; Based on the reference relationship data and description data, generate difference metadata; the difference metadata includes the file path of the changed file content, the data offset address, the offset data size, and the data change type.

[0007] In one embodiment, incremental backup data is generated based on the difference metadata and stored in the backup directory, including: The data to be changed is determined based on the file path, data offset address, and offset data size; Copy changed data block by block to generate incremental changed data blocks; For any incrementally changed data block, construct structured data elements based on the incrementally changed data block, its corresponding file path, data offset address, offset data size, and data change type; All structured data elements are used as incremental backup data and stored in the backup directory.

[0008] In one embodiment, when software needs to be rolled back, the software is rolled back to the target version based on the version tree structure, backup data chain files, and changed paths, including: In the version tree structure, check if the target version node exists in the node relationship of the current version node; if not, throw an error; if yes, roll back the software to the target version based on the node relationship between the current version node and the target version node, the backup data chain file, and the change path.

[0009] In one embodiment, the software is rolled back to the target version based on the node relationship between the current version node and the target version node, the backup data chain file, and the change path, including: Based on the node relationship between the current version and the target version, determine the optimal path to roll back from the current version to the target version; Under the optimal path, obtain the characteristic data between each adjacent node in the backup data chain file, as well as the changed path between each adjacent node; Based on the characteristic data and change paths between adjacent nodes, the software is rolled back to the target version.

[0010] In one embodiment, rolling back the software to the target version based on the characteristic data and change paths between adjacent nodes includes: For any two adjacent nodes, based on the changed path, obtain the incremental backup data under the corresponding backup directory; calculate the summary value of the incremental backup data, and compare the summary value with the summary value recorded in the feature data; If the summary values ​​of all adjacent nodes are the same, then a reverse change operation is performed based on the incremental backup data between all adjacent nodes to roll back the software to the target version; if the comparison results of adjacent nodes are different, then an error is thrown.

[0011] In one embodiment, after the rollback is complete, the method further includes: Update the current version to the target version node in the version tree structure; Record the activation status of the target version in the backup data chain file.

[0012] In one embodiment, incremental backup data is generated based on the difference metadata and stored in a backup directory. The method further includes: Generate the backup directory for this backup, and use the current software version number as the file name; Incremental backup data is stored in the backup directory.

[0013] In one embodiment, before recording the feature data of this backup in the backup data chain file, the method further includes: Check if a backup data chain file exists; if not, initialize the backup data chain file and initialize the version tree structure, using the current version node as the root node of the version tree structure.

[0014] Secondly, this application also provides a software maintenance device, which includes: The generation module is used to generate difference metadata based on the software upgrade package and the current version; The storage module is used to generate incremental backup data based on the differential metadata and store it in the backup directory; The update module is used to record the characteristic data of this backup in the backup data chain file, and add the upgrade version node as a child node under the current version node in the version tree structure, and record the change path between nodes as the backup directory; the characteristic data includes the summary value of the incremental backup data; The rollback module is used to roll back the software to the target version when it needs to be rolled back, based on the version tree structure, backup data chain files, and changed paths.

[0015] The aforementioned software maintenance method and apparatus generate difference metadata based on the software upgrade package and the current version to represent the changes in the software upgrade package compared to the current version; based on the difference metadata, incremental backup data is generated, which can store only the incremental data that has changed, rather than a full backup, reducing the storage space occupied by backup data; the characteristic data of this backup is recorded in the backup data chain file, which can clearly record the software upgrade process and provide a data basis for rollback operations; in the version tree structure, the upgrade version node is added as a child node under the current version node, and the change path between nodes is recorded as a backup directory, which builds the connection between versions in the software iteration process and can directly obtain the software rollback version and rollback path; when the software needs to be rolled back, the software is rolled back to the target version according to the version tree structure, backup data chain file and change path, realizing cross-level rollback of software version and improving the convenience and reliability of software maintenance. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of a version tree structure in one embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] It should be noted that the current version mentioned in this application can be understood as the software version in the current operating environment before the software upgrade or before the software rollback.

[0020] In one alternative embodiment, a software maintenance method is proposed, which may include: S100 generates difference metadata based on the software upgrade package and the current version.

[0021] Among them, difference metadata can be understood as data that describes the differences between two versions.

[0022] In one alternative embodiment, the method for generating difference metadata based on the software upgrade package and the current version may include: S110, obtain the first file list of the software upgrade package, and the second file list of the current version.

[0023] The first file list can be understood as the list of files contained in the software upgrade package after it has been unzipped, and the second file list can be understood as the list of all files in the software installation directory in the current running environment.

[0024] S120, compare the corresponding files in the first file list and the second file list one by one.

[0025] Specifically, comparing the first file list and the second file list can include identifying newly added, deleted, and modified files. Newly added files are those that exist in the first file list but not in the second; deleted files are those that exist in the second file list but not in the first; modified files are those with the same filename but different content. Optionally, the comparison of the file lists can be implemented using algorithms such as diff.

[0026] S130, based on the file comparison results, record the reference relationship data of the unchanged file content, and the description data of the changed file content.

[0027] The reference relationship data for unmodified file content can include pointers or path identifiers to the base version backup data, which are the dependencies of the unmodified files. Modified file content can include adding, deleting, and modifying file content. The descriptive data for modified file content can include the file path, data offset address, offset data size, and data change type. The file path can be understood as the path to the file containing the modified content; the data offset address can be understood as the offset of the modified content relative to a base position (usually the beginning of the file), used to determine the position of the modified content within the file; the offset data size can be understood as the length of the data block involved starting from the offset position; combining the data offset address and offset data size allows locating the data block containing the modified content within the file; the data change type can include addition, deletion, and modification.

[0028] S140, Generate differential metadata based on reference relationship data and description data.

[0029] It is understandable that difference metadata can actually be a data set that combines reference relation data and descriptive data according to a specific data structure. Therefore, difference metadata also includes data such as the file path, data offset address, offset data size, and data change type of each changed file.

[0030] S200 generates incremental backup data based on the difference metadata and stores it in the backup directory.

[0031] Incremental backup data can be understood as backup data of the changes made by the upgraded software version relative to the current version. Optionally, during each backup process, a backup directory for this backup can be generated, with the current software version number used as the filename.

[0032] In one alternative embodiment, the method for generating incremental backup data based on difference metadata may include: S210, determine the changed data based on the file path, data offset address, and offset data size.

[0033] Specifically, the file location where the change occurred can be located through the file path, the position of the changed content in the file can be determined based on the data offset address, and then the changed data can be determined based on the offset data size.

[0034] S220, copy the changed data block by block to generate incremental changed data blocks.

[0035] It is understandable that all changed data is not copied together. Instead, each segment of changed data is copied separately, and corresponding incremental change data blocks are generated. This avoids confusion between changed data and ensures the integrity of the changed data. Optionally, the data block size can be preset, such as 1MB, and then the incremental change data blocks are generated according to the preset data block size.

[0036] S230: For any incrementally changed data block, construct a structured data element based on the incrementally changed data block, the corresponding file path, data offset address, offset data size, and data change type.

[0037] After determining the changed data, it is necessary to store the changed data systematically. Simply storing the changed data is static and cannot determine the changes that have occurred, nor can it clearly indicate the change process. Therefore, it is necessary to construct the incremental changed data blocks and their corresponding file paths, data offset addresses, offset data sizes, and data change types into structured data elements. For example, a separate object can be constructed for each incremental changed data block. For instance, in an object, data and incremental changed data can be used as a key-value pair, and path and file path can be used as a key-value pair, etc.

[0038] S240 stores the structured data, consisting of all structured data elements, as incremental backup data in the backup directory.

[0039] Structured data can be understood as a dataset organized according to a certain format or structure. For example, an array can be created in which each element is an object of incrementally changed data blocks.

[0040] In one optional embodiment, copy-on-write (COW) technology can be introduced during the incremental backup phase. For file data that has not changed, the original data is not copied directly. Instead, the reference relationship of that data (such as a pointer or path identifier pointing to the base version backup data) is recorded in the backup structure. The COW mechanism is triggered only when the file data is modified in this upgrade—that is, only the modified part of the data (not the entire file) is copied, generating incremental change data blocks, while recording the offset and size of the modified data blocks. The incremental change data blocks generated by triggering the COW mechanism, combined with the change type (added, modified, deleted) described in the difference metadata, are organized into structured incremental backup data according to file path and offset, and stored in a backup directory named after the current version number.

[0041] S300 records the characteristic data of this backup in the backup data chain file, and adds the upgrade version node as a child node under the current version node in the version tree structure, and records the change path between nodes as the backup directory.

[0042] The backup data chain file can be understood as a collection of interrelated backup files formed during the data backup process. Feature data can be understood as data reflecting version characteristics, which may include the version to be installed, the version to which it can be rolled back (the version of the backup data), the storage path of the incremental backup data, the overall digest value of the incremental backup data, and the application identifier of the COW mechanism (optional, used to identify that the backup includes COW optimization). The overall digest value of the incremental backup data can be understood as the overall digest value (such as hash aggregation value) of all incremental data blocks in the incremental backup data. As shown in Table 1, taking the first row of data as an example, the version to be installed is 1.0.1, the rollback version is 1.0.0, and the overall digest value of the backup incremental data is eaad90d7b015fc18afbfe8914ef663ee.

[0043] Table 1: Example Table of Feature Data

[0044] A version tree structure can be understood as a model for managing the relationships between different versions of software; it displays the evolution of each software version in the form of a tree. For example... Figure 1As shown, the root node of the tree usually represents the initial version of the software. Starting from the root node, each branch and evolution of the version will form a new node. These nodes are connected through parent-child relationships, showing the development path of the software versions.

[0045] Optionally, based on the record information in the backup data chain file and combined with the version tree structure, a rollback list of backup points can be generated (the tree nodes expand into a list), which is then displayed to the user through a user-friendly interface. Users can also select a specific backup point for rollback. The interface supports a tree view to display the version evolution relationship (such as trunk, branches, and tag nodes), and users can intuitively select any tree node as the rollback target.

[0046] Optionally, before recording the feature data of this backup in the backup data chain file, it is possible to check whether a backup data chain file exists; if not, the backup data chain file is initialized, and the version tree structure is initialized, with the current version node as the root node of the version tree structure.

[0047] Specifically, it can check if a backup data chain file exists. If not, it initializes a backup data chain file to record characteristic information. At the same time, it initializes the root node of the version tree structure (usually the initial version). The root node contains the version number, backup data path, parent node pointer (empty), and child node list (initially empty).

[0048] S400, when software needs to be rolled back, rolls the software back to the target version based on the version tree structure, backup data chain files, and changed paths.

[0049] In one alternative embodiment, the method for software rollback may include: S410: In the version tree structure, check if the target version node exists in the node relationship of the current version node; if not, throw an error; if yes, roll back the software to the target version based on the node relationship between the current version node and the target version node, the backup data chain file, and the change path.

[0050] It is understandable that if the target version node does not exist in the node relationship of the current version node, it means that the current version may not be able to roll back to the target version, or the target version node is missing. Therefore, an error "backup point does not exist" can be thrown.

[0051] Optionally, the S410 software rollback method may further include: S411, based on the node relationship between the current version and the target version, determine the optimal path to roll back from the current version to the target version.

[0052] Specifically, the optimal rollback path can be planned based on the path relationship between the current version node and the target version node in the version tree (such as parent-child path, sibling path, or cross-branch path). This can be done by prioritizing the shortest path or specifying a branch path.

[0053] S412, under the optimal path, obtain the characteristic data between each adjacent node in the backup data chain file, as well as the changed path between each adjacent node.

[0054] Specifically, for any two adjacent nodes, incremental backup data in the corresponding backup directory can be obtained according to the changed path (the changed path is set to point to the backup directory); the summary value of the incremental backup data is calculated, and the summary value is compared with the summary value recorded in the feature data; If the summary values ​​of all adjacent nodes are the same, then a reverse change operation is performed based on the incremental backup data between all adjacent nodes to roll back the software to the target version; if the comparison results of adjacent nodes are different, then an error is thrown.

[0055] For example, suppose there exists an optimal path where the current version node is node C, the target version node is node A, and there is an intermediate node B between nodes A and C. The feature data and change paths of AB and BC in the backup data chain can be obtained separately. Based on the change path of BC, the incremental backup data of BC is found, the digest value of the incremental backup data of BC is calculated, and then compared with the digest value recorded in the feature data of BC to verify whether the incremental backup data has been corrupted. (The process for AB is similar and will not be repeated here). If the digest value comparison results of AB and BC are the same, a reverse change operation is performed; if the digest value comparison results of AB and BC are different, a "backup data corrupted" error can be thrown.

[0056] S413, based on the characteristic data and change paths between adjacent nodes, roll back the software to the target version.

[0057] In an optional embodiment, for each node in the path (including the current version node and the target version node), the corresponding backup data chain record can be found to obtain the software version to which it can be rolled back and the summary value of the backup data; the data storage directory is located according to the backup data path pointed to by the node, the summary value of the backup data in that directory is calculated, and compared with the summary value of the record: If there is a discrepancy, a "backup data corrupted" error will be thrown, all backup data and backup data chain files will be cleaned up, and the administrator will be required to manually reinstall the specified version of the software. If they match, the corresponding reverse change for that node is applied (i.e., restoring to the state of the previous version, or directly switching to the backup data state of the target node based on the tree structure). By directly mapping or incrementally changing the backup data of the tree nodes, the version state can be quickly switched, avoiding redundant operations of rolling back step by step.

[0058] In another alternative embodiment, after the rollback is completed, the current version can be updated to the target version node in the version tree structure; the activation status of the target version is recorded in the backup data chain file.

[0059] Specifically, after the rollback (switch) is completed, the current running version can be updated to the target version node in the tree structure, and the status of the corresponding record (such as "activated" or "current version") can be marked in the backup data chain file. Since the tree structure retains the complete backup data or incremental path of each version node, there is no need to regenerate intermediate states during the version switching process, thus achieving seamless switching between versions.

[0060] In this embodiment, difference metadata is generated based on the software upgrade package and the current version to represent the changes in the software upgrade package compared to the current version. Incremental backup data is generated based on the difference metadata, which can store only the incremental data that has changed, rather than a full backup, reducing the storage space occupied by the backup data. The feature data of this backup is recorded in the backup data chain file, which can clearly record the software upgrade process and provide a data basis for rollback operations. In the version tree structure, the upgrade version node is added as a child node under the current version node, and the change path between nodes is recorded as the backup directory, which builds the connection between versions in the software iteration process and can directly obtain the software rollback version and rollback path. When the software needs to be rolled back, the software is rolled back to the target version according to the version tree structure, backup data chain file and change path, realizing cross-level rollback of software version and improving the convenience and reliability of software maintenance.

[0061] In one alternative embodiment, the software maintenance apparatus may include: The generation module is used to generate difference metadata based on the software upgrade package and the current version; The storage module is used to generate incremental backup data based on the differential metadata and store it in the backup directory; The update module is used to record the characteristic data of this backup in the backup data chain file, and add the upgrade version node as a child node under the current version node in the version tree structure, and record the change path between nodes as the backup directory; the characteristic data includes the summary value of the incremental backup data; The rollback module is used to roll back the software to the target version when it needs to be rolled back, based on the version tree structure, backup data chain files, and changed paths.

[0062] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0063] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A software maintenance method characterized by comprising: The method comprises: According to the software upgrade package and the current version, difference metadata is generated; According to the difference metadata, incremental backup data is generated and stored in the backup directory; In the backup data chain file, feature data of this backup is recorded, and in the version tree structure, the upgrade version node is added as a child node under the current version node, and the change path between the nodes is recorded as the backup directory; the feature data includes the summary value of the incremental backup data; When the software needs to be rolled back, according to the version tree structure, the backup data chain file and the change path, the software is rolled back to the target version.

2. The software maintenance method of claim 1, wherein, According to the software upgrade package and the current version, difference metadata is generated, comprising: Obtaining a first file list of the software upgrade package and a second file list of the current version; Comparing corresponding files in the first file list and the second file list one by one; According to the file comparison result, the reference relationship data of the unchanged file content and the description data of the changed file content are recorded; According to the reference relationship data and the description data, difference metadata is generated; the difference metadata includes the file path, data offset address, offset data size and data change type of the changed file content.

3. The software maintenance method of claim 1, wherein, According to the difference metadata, incremental backup data is generated and stored in the backup directory, comprising: According to the file path, data offset address and offset data size, the changed data is determined; Copy the changed data by block to generate incremental changed data block; For any incremental changed data block, according to the incremental changed data block and the corresponding file path, data offset address, offset data size and data change type, a structured data element is constructed; The structured data composed of all structured data elements is taken as incremental backup data and stored in the backup directory.

4. The software maintenance method of claim 1, wherein, When the software needs to be rolled back, according to the version tree structure, the backup data chain file and the change path, the software is rolled back to the target version, comprising: In the version tree structure, it is queried whether there is a target version node in the node relationship of the current version node; if not, an error is thrown; if yes, according to the node relationship of the current version node and the target version node, the backup data chain file and the change path, the software is rolled back to the target version.

5. The software maintenance method of claim 4, wherein, According to the node relationship of the current version node and the target version node, the backup data chain file and the change path, the software is rolled back to the target version, comprising: According to the node relationship of the current version and the target version, the optimal path from the current version to the target version is determined; In the optimal path, the feature data between adjacent nodes in the backup data chain file and the change path between adjacent nodes are obtained; According to the feature data and the change path between adjacent nodes, the software is rolled back to the target version.

6. The software maintenance method of claim 5, wherein, According to the feature data and the change path between adjacent nodes, the software is rolled back to the target version, comprising: For any two adjacent nodes, according to the change path, the incremental backup data under the corresponding backup directory is obtained; the summary value of the incremental backup data is calculated, and the summary value is compared with the summary value recorded in the feature data; If the comparison results of the digest values of all adjacent nodes are the same, a reverse change operation is performed according to the incremental backup data between all adjacent nodes to roll back the software to the target version; if the comparison results of the adjacent nodes are different, an error is thrown.

7. The software maintenance method of claim 1, wherein, After the rollback is completed, the method further includes: updating the current version to the target version node in the version tree structure; recording the activation state of the target version in the backup data chain file.

8. The software maintenance method of claim 1, wherein, The method further includes: generating a backup directory of the current backup and taking the software version number of the current version as a file name; storing the incremental backup data into the backup directory.

9. The software maintenance method according to claim 1, before the step of recording the feature data of the current backup in the backup data chain file, the method further includes: detecting whether the backup data chain file exists; if not, initializing the backup data chain file and initializing the version tree structure, taking the current version node as the root node of the version tree structure.

10. A software maintenance apparatus characterized by comprising: The device includes: a generation module configured to generate the difference metadata according to the software upgrade package and the current version; a storage module configured to generate the incremental backup data according to the difference metadata and store the incremental backup data into the backup directory; an update module configured to record the feature data of the current backup in the backup data chain file and add the upgrade version node as a child node to the current version node in the version tree structure, and record the change path between the nodes as the backup directory; the feature data includes the digest value of the incremental backup data; a rollback module configured to roll back the software to the target version according to the version tree structure, the backup data chain file and the change path when the software needs to be rolled back.

Images