Database backup automatic recovery verification method and system based on large language model

Abstract

The present application relates to a database backup automatic recovery verification method and system based on a large language model, first, a user interaction interface is constructed using a RAG platform, then historical script files and log records are collected and converted into a text format and stored in the knowledge base of the RAG platform to form a historical data set, the natural language requirement information input by the user is analyzed through a large language model combined with a prompt word, and a backup recovery script containing recovery resource configuration parameters is generated based on the historical backup recovery records and the large language model combined with the prompt word; then, according to the script requirements and the large language model analysis, a matched recovery server is selected and automatically executed to recover and verify the backup files of the target database and perform real-time monitoring, the large language model analysis is triggered in case of abnormality, and finally the execution log is stored and the user is notified of the task execution result, completing the automatic recovery verification of the database backup and effectively reducing the use threshold of the user for backup recovery verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database operation and maintenance and intelligent information processing, and particularly relates to a database backup automatic recovery verification method and system based on a large language model. BACKGROUND

[0002] In the digital economy era, data has become the core strategic asset of enterprise operation and development, and its security and availability are directly related to business continuity, user experience and stable operation of social public service system. With the wide application of cloud computing, AI and other technologies, the data scale is growing exponentially, and the reliability of database systems as the core infrastructure carrying key business data is facing unprecedented challenges. Under this background, database backup and recovery technology is not only the basic defense line to deal with hardware failure, human error, network attack and other risks, but also an important cornerstone to support enterprise digital transformation and realize data lifecycle management.

[0003] Database backup verification is an important part of digital work and a core link to ensure enterprise data security. It ensures the effectiveness of backup files by restoring backup data regularly. However, the daily large number of recovery verification operations require a lot of manpower and resources to operate. Currently, a single database recovery requires a total time of 127-134 hours, which means that 5-6 working days are needed to verify the monthly database backup. In addition, because of the possibility of recovery failure, manual follow-up is required, which occupies a lot of manual intervention time. Furthermore, the backup and recovery verification work requires a lot of parameter configuration, which requires certain professional knowledge, making it difficult for users lacking such knowledge to perform database backup verification.

[0004] The existing solutions mainly use the following methods for database backup recovery: 1) Manual + automated combination for processing, which involves manual processing of test requirements and checking of recovery status, and automated calling of API scripts to perform recovery operations and verify data integrity based on logs and requirements. However, this method requires continuous manual follow-up and operation, and requires certain professional knowledge. Currently, according to the total amount of internal databases, the recovery estimate requires a large amount of manpower. 2) Using mature middleware for processing, such as OEM or third-party middleware, to perform recovery and automated recovery verification. However, this method requires professional knowledge for configuration information, which increases communication costs for non-professional personnel. As can be seen, most existing solutions are based on automated program construction for the entire backup verification scheme, which requires users to be familiar with database backup and recovery related parameters and to configure a large number of parameters to implement automated recovery processes. This is not suitable for users who are not familiar with database backup and recovery related parameters to perform recovery verification.

[0005] In summary, in order to reduce labor costs, minimize manual work, and not occupy a large number of developers and time, and not increase the communication cost between departments, an efficient, accurate and full-coverage method is needed to optimize the database backup verification work and improve the overall competitiveness and efficiency of enterprises. SUMMARY

[0006] To solve the problems of requiring a large amount of manpower and material resources, occupying a large number of developers and time, and users lacking professional knowledge being unable to implement database backup verification, the present application provides a database backup automatic recovery verification method based on a large language model, which can effectively reduce the cost of manual operation, reduce the workload of users on database backup recovery operation, and reduce the use threshold of users on backup recovery verification, thereby improving the efficiency of backup recovery verification. The present application also relates to a database backup automatic recovery verification system based on a large language model.

[0007] The technical scheme of the present application is as follows:

[0008] A database backup automatic recovery verification method based on a large language model, characterized in that it comprises the following steps:

[0009] A user interaction interface construction step: a user interaction interface is constructed using an RAG platform, and database backup recovery requirement information input by a user in natural language form is received through the user interaction interface;

[0010] A historical data set construction step: script files and log records used in historical backup recovery operations of a number of databases of an enterprise are collected; the script files and log records are converted into text format and stored in a knowledge base of an RAG platform to form a historical data set;

[0011] A user requirement analysis step: a large language model is used to analyze database backup recovery requirement information input by a user in natural language form in combination with prompt words to generate target positioning information that the user needs to recover;

[0012] A backup recovery script generation step: the historical data set is queried to obtain historical backup recovery records matching the target positioning information that the user needs to recover, and a backup recovery script containing recovery resource configuration parameters is generated based on the historical backup recovery records by using a large language model in combination with prompt words;

[0013] A recovery server selection step: backup cluster server performance data stored in the historical data set is queried, a recovery server that meets performance requirements determined based on the performance data and the estimated backup data volume in the backup recovery script is selected from the backup cluster servers by using a large language model;

[0014] The recovery verification execution step: automatically executing the generated backup recovery script on the selected recovery server to perform recovery verification on the backup file of the target database specified by the user, monitoring the execution process of the backup recovery script in real time and recording the execution log, when an error in the execution of the backup recovery script task is monitored, the error execution log is fed back to the large language model for cause analysis, and according to the analysis result of the large language model, the backup recovery script is re-executed or a new backup recovery script is generated after adjusting the recovery resource configuration parameters;

[0015] The result feedback and optimization step: when the execution of the backup recovery script task is monitored, the complete execution log of this recovery process is stored in the historical data set, and the user is notified of the task execution result through the user interaction interface, and the automatic recovery verification of the database backup is completed.

[0016] Preferably, in the backup recovery script generation step, a backup recovery verification interface is also built based on the FastAPI framework developed by Python, the backup recovery verification interface includes a backup query interface and a parameter query interface; the backup query interface is used to call the RMAN API to query the backup dataset file name corresponding to the target positioning information in the historical data set, based on the backup dataset file name, the recovery resource configuration parameters required for the backup file of the target database are analyzed by the large language model combined with the prompt word, and then the backup recovery script is constructed;

[0017] In the recovery server selection step, the backup cluster server performance data stored in the historical data set is queried through the parameter query interface, the performance data includes current running environment parameters and physical server performance indicators, based on the estimated backup data volume in the backup recovery script, and through the large language model, the recovery server that meets the storage space demand and memory capacity demand in the current running environment parameters, and the processor performance indicator demand in the physical server performance indicator is selected from the backup cluster server; the running environment parameters include memory configuration state, storage path information and version characteristics.

[0018] Preferably, the backup recovery verification interface further includes a log callback interface, a backup execution interface and a backup state query interface, in the recovery verification execution step, the recorded execution log is fed back to the large language model in real time through the log callback interface for analysis, and the recovery strategy is dynamically adjusted based on the analysis result of the large language model; the backup recovery script is called through the backup execution interface to perform recovery verification on the backup file of the target database; the current backup file recovery state is obtained by querying the execution log through the backup state query interface; the recovery strategy includes parameter optimization, script correction and server reselection.

[0019] Preferably, the backup query interface further receives a query request containing a target database identifier and a recovery time range, and returns backup file metadata in a standardized JSON format.

[0020] Preferably, in the user interaction interface construction step, the database backup recovery requirement information includes a target database identifier and a desired recovery time point.

[0021] In the historical data set construction step, the script file includes backup recovery commands and parameter configurations, and the log record includes script execution results and error information.

[0022] In the user requirement analysis step, the target positioning information includes a target database network address, a database system identifier, and a time node to which the user expects to recover.

[0023] Preferably, in the backup recovery script generation step, the recovery resource configuration parameters include system global memory area configuration parameters, program global memory area configuration parameters, and recovery operation target instruction sets. The system global memory area configuration parameters include memory allocation values of database buffers, shared pools, and redo log buffers. The program global memory area configuration parameters include memory limits of sorting areas, hash areas, and private SQL areas. The recovery operation target instruction sets include backup set paths, recovery termination points, and data file redirection rules.

[0024] A database backup automatic recovery verification system based on a large language model, characterized by comprising, in sequence, a user interaction interface construction module, a historical data set construction module, a user requirement analysis module, a backup recovery script generation module, a recovery server selection module, a recovery verification execution module, and a result feedback and optimization module.

[0025] The user interaction interface construction module uses the RAG platform to construct a user interaction interface, and receives database backup recovery requirement information input by a user in natural language form through the user interaction interface.

[0026] The historical data set construction module collects script files and log records used in historical backup recovery operations of a plurality of databases of an enterprise, converts the script files and log records into a text format, and stores them in a knowledge base of the RAG platform to form a historical data set.

[0027] The user requirement analysis module analyzes database backup recovery requirement information input by a user in natural language form through a large language model and in combination with prompt words, and generates target positioning information required by the user for recovery.

[0028] The backup recovery script generation module queries the historical data set, obtains a historical backup recovery record matched with target positioning information required by the user to be recovered, and then generates a backup recovery script containing recovery resource configuration parameters based on the historical backup recovery record through a large language model and in combination with prompt word analysis.

[0029] The recovery server selection module queries backup cluster server performance data stored in the historical data set, selects a recovery server that meets performance requirements determined based on the performance data from the backup cluster servers based on the estimated backup data volume in the backup recovery script, and through a large language model.

[0030] The recovery verification execution module automatically executes the generated backup recovery script on the selected recovery server, performs recovery verification on the backup file of the target database specified by the user, monitors the execution process of the backup recovery script in real time and records execution logs, feeds error execution logs back to the large language model for cause analysis when monitoring task execution errors of the backup recovery script, and selects to re-execute the backup recovery script or generate a new backup recovery script after adjusting the recovery resource configuration parameters according to the analysis result of the large language model.

[0031] The result feedback and optimization module stores the complete execution logs of this recovery process to the historical data set when monitoring the completion of the backup recovery script task execution, sends a task execution result notification to the user through the user interaction interface, and completes the automatic recovery verification of the database backup.

[0032] Preferably, the backup recovery script generation module also builds a backup recovery verification interface based on the FastAPI framework developed by Python, which includes a backup query interface and a parameter query interface; the backup query interface calls the RMAN API to query the backup data set file name corresponding to the target positioning information in the historical data set, and based on the backup data set file name, the large language model and the prompt word analysis are used to analyze the recovery resource configuration parameters required for the backup file of the target database, and then the backup recovery script is constructed.

[0033] In the recovery server selection module, the backup cluster server performance data stored in the historical data set is queried through the parameter query interface, the performance data includes current running environment parameters and physical server performance indicators, and based on the estimated backup data volume in the backup recovery script, a recovery server that meets the storage space requirement and memory capacity requirement in the current running environment parameters and the processor performance indicator requirement in the physical server performance indicators is selected from the backup cluster servers through the large language model; the running environment parameters include memory configuration state, storage path information and version characteristics.

[0034] Preferably, the backup and recovery verification interface further includes a log callback interface, a backup execution interface, and a backup status query interface. In the recovery verification execution module, the recorded execution logs are fed back to the large language model in real time for analysis through the log callback interface, and the recovery strategy is dynamically adjusted based on the analysis results of the large language model; the backup execution interface calls the backup and recovery script to perform recovery verification on the backup files of the target database; the backup status query interface queries the execution logs to obtain the current backup file recovery status; the recovery strategy includes parameter optimization, script correction, and server reselection.

[0035] Preferably, the backup query interface also receives a query request containing a target database identifier and a recovery time range, and returns backup file metadata in a standardized JSON format.

[0036] The technical effects of this invention are as follows:

[0037] This invention provides an automated database backup and recovery verification method based on a large language model. First, a user interface is built using the RAG platform. This interface receives database backup and recovery requests input by the user in natural language, effectively lowering the user's operational threshold. This allows non-professionals to describe their needs using natural language, without requiring expertise in database command syntax, thus improving interaction efficiency and avoiding formatting errors or parameter omissions that may occur with traditional command-line input. Next, script files and log records used in historical database backup and recovery operations are collected. These script files and log records are converted to text format and stored in the RAG platform's knowledge base, forming a searchable historical dataset (knowledge base). The RAG platform searches the knowledge base in real time, matching user input with historical cases, effectively improving the accuracy of subsequent large language model parsing and providing data support for subsequent automated decision-making. Furthermore, structured storage enables rapid matching, avoiding the inefficiency of manually reviewing historical records. Then, using a large language model and prompt words, the database backup and recovery request information input by the user in natural language is parsed to generate the target location information that the user needs to restore. This accurately extracts the user's intent, avoids subjective errors from manual parsing, effectively reduces the professional knowledge threshold required by users, and supports multilingual input to meet the needs of international enterprise environments. Based on historical backup and recovery records and the large language model, and combined with prompt word analysis, a backup and recovery script containing recovery resource configuration parameters is generated. The script automatically calls the backup and recovery API and automatically executes the recovery operation, skipping traditional manual coding and avoiding potential memory shortages or resource waste caused by manual settings. It replaces the tedious and inefficient manual spot checks and inherits historical success experience, effectively improving the recovery success rate. Based on the script requirements and the large language model analysis, a matching recovery server is selected, realizing dynamic resource allocation to ensure that server performance matches the recovery task requirements and avoid recovery failures or performance bottlenecks due to insufficient resources. The backup and recovery script is then automatically executed to verify the recovery of the target database backup files and monitors them in real time. In case of anomalies, the large language model analysis is triggered, and through real-time fault detection and self-repair, the need for manual intervention is reduced. Log analysis quickly locates the root cause and shortens the fault handling time. Finally, the execution log is stored and the task execution result notification is sent to the user, completing the automatic verification of the database backup, forming a closed-loop learning process. This effectively reduces the cost of manual operation, reduces the workload of users in database backup and recovery operations, lowers the barrier to entry for users to use backup and recovery verification, and improves the efficiency of backup and recovery verification.

[0038] This invention directly parses user natural language input using a large language model to understand user intent, significantly reducing reliance on database expertise and achieving "zero-configuration" operation. This greatly lowers the barrier to entry for backup and recovery verification, improving its efficiency. In other words, it can be understood as using an AIGC large model (i.e., a generative artificial intelligence large language model capable of semantic understanding and content generation based on user-input natural language) to understand user semantics, automatically perform parameter parsing and script invocation, reducing the barrier to entry for users with specialized knowledge compared to existing solutions. Furthermore, it constructs a structured knowledge base from historical backup scripts and log records, combined with RAG (Retrieval Augmented Generation) technology, enabling the large model to dynamically recommend optimal recovery strategies (such as server selection and risk warnings) based on historical data. This avoids repetitive manual analysis of historical logs and automatically matches similar scenarios through the knowledge base (historical dataset), effectively improving recovery success rates and reducing trial-and-error costs. Furthermore, by integrating the FastAPI interface with automated scripts, this invention achieves a closed-loop process from requirement analysis to script generation, recovery execution, log monitoring, and failure callbacks (such as automatic retries or email notifications). Traditional solutions require manual step-by-step operations and cannot correct errors in real time. In contrast, this invention, through automated tracking and callback mechanisms, reduces the single recovery time from 127+ hours to unattended completion, effectively improving the efficiency and success rate of recovery verification and greatly saving labor costs.

[0039] This invention reduces the traditional 5-6 person-days of manual operation to a fully automated process, improving efficiency by over 90%. By utilizing a historical knowledge base and a large language model, it reduces reliance on professional DBAs, lowering labor costs by 70%. An automated anomaly handling mechanism increases the recovery success rate from 80% with manual operation to over 98%. Standardized processes eliminate human error and ensure enterprise data security.

[0040] Furthermore, the backup and recovery script generation step also builds a backup and recovery verification interface based on the FastAPI framework developed in Python. The backup and recovery verification interface includes a backup query interface and a parameter query interface. The backup query interface calls the RMAN API to query the backup dataset file name corresponding to the target location information in the historical dataset, and injects the queried backup dataset file name as a key parameter into the backup and recovery script generation process. In the recovery server selection step, the current operating environment parameters of the database and the physical server performance indicators are obtained through the parameter query interface. The obtained current operating environment parameters and physical server performance indicators are used as important basis for the selection of the recovery server. The backup information is obtained through the RMAN official API, avoiding manual input errors, ensuring the accuracy of the backup set path, and eliminating the manual operation of manually querying parameters and backup files, reducing the preparation time for a single recovery from 30 minutes to within 10 seconds.

[0041] Furthermore, the backup and recovery verification interface also includes a log callback interface, a backup execution interface, and a backup status query interface. The log callback interface feeds back the recorded execution logs to a large language model for analysis in real time. Based on the analysis results of the large language model, the recovery strategy is dynamically adjusted, enabling real-time monitoring of the backup / recovery process. This ensures that any anomalies or errors are captured promptly. Combined with the powerful semantic understanding and reasoning capabilities of the large language model, the system can automatically identify potential problems and patterns in the logs, thereby improving overall recovery efficiency and success rate. The backup execution interface calls the backup and recovery script to perform backup and recovery. The backup status query interface queries the logs to obtain the current backup and recovery status. The backup and recovery verification interface system integrates three core capabilities: intelligent analysis, automated execution, and visual monitoring. It achieves a closed-loop process from log collection, intelligent analysis, and strategy adjustment to task execution and status feedback. This improves the stability, flexibility, and intelligence of the backup and recovery system; significantly reduces manual maintenance costs; and enhances the system's adaptability and fault tolerance in complex scenarios. It also supports unified backup and recovery management across multiple tenants, business lines, and environments, possessing good scalability and deployment adaptability.

[0042] This invention also relates to a database backup automatic recovery verification system based on a large language model. This system corresponds to the aforementioned database backup automatic recovery verification method based on a large language model. It can be understood as a system that implements the aforementioned database backup automatic recovery verification method based on a large language model. It includes a user interface construction module, a historical dataset construction module, a user requirement parsing module, a backup recovery script generation module, a recovery server selection module, a recovery verification execution module, and a result feedback and optimization module, all connected sequentially. These modules work collaboratively, directly parsing the user's natural language input through the large language model to understand the user's intent. This significantly reduces the reliance on database expertise, greatly lowers the barrier to entry for users of backup recovery verification, and improves the efficiency of backup recovery verification. Furthermore, historical backup scripts and log records are constructed into a structured knowledge base. Combined with RAG technology, the large model can dynamically recommend the optimal recovery strategy based on historical data, avoiding repetitive manual analysis of historical logs. By automatically matching similar scenarios through historical datasets, it effectively improves the recovery success rate and reduces trial-and-error costs. Furthermore, this invention integrates the FastAPI interface with automated scripts to achieve a closed-loop process from requirements analysis to script generation, recovery execution, log monitoring, and failure callbacks (such as automatic retries or email notifications), effectively improving the efficiency and success rate of recovery verification and significantly saving labor costs. This system reduces the time required for manual intervention in recovery verification operations and improves communication efficiency between development departments and backup recovery verification, greatly saving labor costs and increasing digital efficiency. Calculations show that compared to traditional methods, overall manual intervention time is reduced by more than 90%, and overall communication efficiency is improved by more than 50%. After adopting this system, backup verification work can save more than 20% in labor costs. Attached Figure Description

[0043] Figure 1 This is a flowchart of the database backup automatic recovery verification method based on a large language model according to the present invention.

[0044] Figure 2 This is a schematic diagram illustrating the implementation principle of an automatic recovery verification method for database backup based on a large language model. Detailed Implementation

[0045] The present invention will now be described with reference to the accompanying drawings.

[0046] This invention relates to an automatic database backup and recovery verification method based on a large language model. The method obtains the user's target database for recovery, automatically analyzes and constructs relevant recovery parameters, and performs database recovery operations. It uses an AIGC large language model to understand user semantics, accurately identify user needs, extract the target database IP and SID, automatically analyze the database size, allocate it to a backup and recovery environment that meets the requirements, configure corresponding database parameters, analyze potential risk points, construct backup and recovery scripts, automatically call the scripts within the planned scope in the backup and recovery environment, track recovery logs, analyze the causes of errors, appropriately call back the scripts to re-recover, and automatically send an email notification to the user if the recovery cannot be completed. The flowchart of this method is as follows. Figure 1 As shown, the steps are as follows:

[0047] I. Steps for building the user interface: Build the user interface using the RAG platform, and receive database backup and recovery request information from users in natural language through the user interface.

[0048] Specifically, such as Figure 2 As shown, firstly, an open-source RAG platform (such as FastGPT or Dify) is used to build a user interface that supports natural language input (e.g., "Please restore the production database to last night's backup"), allowing users to interact with the large language model and perform subsequent low-code operations. After the user initiates a natural language request via PC, the RAG platform receives the database backup and recovery request information input by the user in natural language form through the user interface. This database backup and recovery request information includes the target database identifier and the desired recovery time.

[0049] II. Historical Dataset Construction Steps: Collect script files and log records used in historical backup and recovery operations for several enterprise databases; convert the script files and log records into text format and store them in the knowledge base of the RAG platform to form a historical dataset. The historical dataset is a crucial and indispensable step in enhancing the knowledge understanding capabilities of large language models. Its purpose is to enable large language models to understand the meaning within the backup and recovery scripts through a series of processing steps.

[0050] Specifically, the process begins by collecting script files and log records used in historical backup and recovery operations across the enterprise's databases over a past period (e.g., the last few years). The script files include backup and recovery commands and parameter configurations; the log records include script execution results and error messages. These script files and log records are then converted to TXT text format and stored in the RAG platform's knowledge base (i.e., in the target database DB of the RAG platform, such as the temporary verification database VDB and relational database RDBMS), forming a historical dataset for the RAG platform to access. By constructing a historical dataset (also known as a knowledge base) from historical backup scripts and log records, and combining it with RAG (Retrieval Enhanced Generation) technology, the large model can dynamically recommend optimal recovery strategies (such as server selection and risk warnings) based on historical data. This avoids repetitive manual analysis of historical logs, and by automatically matching similar scenarios through the knowledge base, it significantly improves recovery success rates and reduces trial-and-error costs.

[0051] III. User Requirement Analysis Steps: The database backup and recovery requirement information entered by the user in natural language form is analyzed using a large language model and in combination with prompt words to generate the target location information that the user needs to restore.

[0052] Specifically, a large language model (such as the DeepSeek-R1:32B model) uses prompts to parse the user's database backup and recovery request information (such as "restore database A to its state on May 1, 2024") in natural language form. This parsing includes text parsing, parameter generation, and log analysis, generating the target location information the user needs to restore. The DeepSeek-R1:32B model is a medium-sized, locally deployed model that can achieve high-precision text generation and semantic understanding with minimal computing power requirements. Its text generation process can be simply viewed as a black box; the focus is on the input text and knowledge base, as well as the output. Preferably, the target location information includes the target database network address (target database IP), the database system identifier (SID), and the time point the user expects to restore to.

[0053] IV. Backup and recovery script generation steps: Query the historical dataset to obtain historical backup and recovery records that match the target location information that the user needs to restore. Then, based on the historical backup and recovery records, generate a backup and recovery script containing recovery resource configuration parameters through a large language model and in combination with prompt words analysis.

[0054] Specifically, a backup and recovery verification interface is first built based on the FastAPI framework developed in Python (development tool: PyCharm; API service interface transmission format: JSON). This interface includes a backup query interface, a parameter query interface, a log callback interface, a backup execution interface, and a backup status query interface. The backup query interface calls the RMANAPI to query historical datasets, retrieving historical backup and recovery records (such as backup dataset filenames) that match the user's target location information. Based on these historical records, a large language model is used, along with prompt words, to analyze the required recovery resource configuration parameters for restoring the target database's backup file, thereby constructing the backup and recovery script. Furthermore, the backup query interface also receives query requests containing the target database identifier and recovery time range, returning backup file metadata in standardized JSON format. The recovery resource configuration parameters include System Global Memory Area (SGA) configuration parameters, Program Global Memory Area (PGA) configuration parameters, and recovery operation target instruction set. The System Global Memory Area (SGA) configuration parameters include the memory allocation values ​​for the database buffer, shared pool, and redo log buffer; the Program Global Memory Area (PGA) configuration parameters include the memory limits for the sorting area, hash area, and private SQL area; and the recovery operation target instruction set includes the backup set path, recovery termination point, and data file redirection rules.

[0055] V. Recovery Server Selection Steps: The process involves querying the historical data (i.e., current database operating environment parameters and physical server performance metrics) of the backup cluster servers (which include multiple recovery servers) stored in the historical dataset via a parameter query interface. Based on the estimated backup data volume in the backup and recovery script, and using appropriate prompts through a large language model, a recovery server is selected from the backup cluster servers that meets the performance requirements determined by the performance data (e.g., storage space and memory capacity requirements in the current database operating environment parameters, and processor performance metrics in the physical server performance metrics). In other words, based on the size of the recovery data, the large language model uses appropriate prompts to determine which recovery server meets the performance requirements. For example, based on the estimated backup data volume in the backup and recovery script, the large language model performs the following matching decision:

[0056] 1) Filter server nodes with available storage space ≥ 120% of backup volume.

[0057] 2) Select a physical host with free memory capacity ≥ 110% of the total SGA / PGA requirements of the script.

[0058] 3) Prioritize matching processor resources that have no recent overload records.

[0059] The final output identifies the recovery server that meets the overall performance requirements. The current database operating environment parameters are: memory configuration status, storage path information, and version characteristics obtained by querying the database operating parameters view; the physical server performance indicators are: remaining storage capacity, available memory space, and real-time processor load.

[0060] VI. Recovery Verification Execution Steps: The generated backup and recovery script is automatically executed on the selected recovery server to perform recovery verification on the backup files of the target database. The execution process of the backup and recovery script is monitored in real time and the execution log is recorded. When an error is detected in the backup and recovery script task, the error execution log is fed back to the large language model for cause analysis. Based on the analysis results of the large language model, the backup and recovery script is either re-executed or a new backup and recovery script is generated after adjusting the recovery resource configuration parameters.

[0061] Specifically, the generated backup and recovery script is first automatically executed on the selected recovery server. The script is then invoked via a backup execution interface to verify the recovery of the target database's backup files. The execution process of the backup and recovery script is monitored in real time and an execution log is recorded. On one hand, the log is queried through a backup status query interface to obtain the current backup and recovery status. On the other hand, the recorded execution logs are fed back to a large language model for analysis in real time through a log callback interface. Based on the analysis results of the large language model, the recovery strategy is dynamically adjusted. When an error is detected in the backup and recovery script task execution, the error execution log is fed back to the large language model through the log callback interface for cause analysis. Based on the analysis results of the large language model, the system may choose to re-execute the backup and recovery script, adjust the recovery resource configuration parameters to generate a new backup and recovery script, or notify the user of the recovery failure and its cause through various methods. Furthermore, the recovery strategy can also be dynamically adjusted based on the analysis results of the large language model. This recovery strategy includes parameter optimization, script correction, and server reselection. The recovery resource configuration parameters include system global memory area configuration parameters, program global memory area configuration parameters, and recovery operation target instruction set. The system global memory area configuration parameters include the memory allocation values ​​for the database buffer, shared pool, and redo log buffer; the program global memory area configuration parameters include the memory limits for the sorting area, hash area, and private SQL area; and the recovery operation target instruction set includes the backup set path, recovery termination point, and data file redirection rules.

[0062] VII. Result Feedback and Optimization Steps: After the backup and recovery script task is completed, the complete execution log of this recovery process is stored in the historical dataset. At the same time, the task execution result (including the recovery success status or failure reason analysis) is sent to the user through the user interface to complete the automatic recovery verification of the database backup.

[0063] Figure 2This diagram illustrates the implementation principle of an automated database backup and recovery verification method based on a large language model. It showcases the entire process from user requirements to large model parsing, automated execution, and closed-loop feedback. The core RAG platform involves dialogue interaction, interface calls, and a data bus, which can be understood as corresponding to user interface construction, user requirement parsing, and result feedback. Specifically, dialogue interaction receives user natural language requirements and passes them to the large language model for parsing; interface calls connect to the backup and recovery verification interface, scheduling execution, log callbacks, and queries; and the data bus integrates historical datasets, server information, and execution logs to support the entire data flow. The large language model service involves text parsing, parameter generation, and log analysis, which can be understood as corresponding to user requirement parsing, backup and recovery script generation, and recovery verification execution (error analysis). Specifically, text parsing analyzes user natural language requirements and extracts location information such as the target database IP, SID, and recovery time; parameter generation combines historical datasets to generate recovery resource configuration parameters such as SGA and PGA to construct the backup and recovery script; and log analysis monitors execution logs, automatically analyzes the cause of errors, and decides to retry or adjust the script.

[0064] Example:

[0065] A database administrator in an enterprise inputs a natural language request command, "Please help me restore yesterday's CORIS database data," through the user interface built on the RAG platform. The RAG platform transmits the request command to the large language model center via the data bus. Upon receiving the request, the model communication module in the model center schedules the large language model service. The large language model parses the natural language request and accurately extracts the unique identifier information of the target database, including the database server's network protocol address (IP: 192.168.1.100), the database system identifier (SID: ORCL_CORIS), and the specific recovery time (e.g., 2025-7-10 23:00:00). Then, through the query interface in the backup and recovery verification interface, it queries a pre-built historical dataset in the data source, matching five historical backup and recovery records from similar periods within the past three months. Based on these historical backup and recovery records and the prompt words, the large language model generates a database containing the System Global Area (SGA) memory. The system uses a resource configuration scheme of 12GB and 6GB Program Global Area (PGA) memory (backup and recovery script), and estimates that this recovery will require 500GB of storage space. The system continues to query the server performance data in the historical dataset and selects the physical recovery server Node-12 from the backup cluster servers, which has a current load rate of less than 40% and available storage space of more than 600GB, as the recovery node. The generated recovery script is automatically executed on the Node-12 server. When the error "ORA-19809: Insufficient space in the specified recovery area" is detected in real time, the error log is immediately fed back to the large language model. After analysis, the large language model dynamically adjusts the recovery area parameters from 400GB to 650GB and continues to execute. After successful verification, the system updates all configuration parameters, execution indicators and optimization records of this recovery to the historical dataset, and sends a notification to the administrator that "ORCL_PROD database backup verification successful, time taken 8 hours and 23 minutes", which fully realizes the closed-loop automated process from requirement input to verification completion.

[0066] This invention also relates to an automatic database backup recovery verification system based on a large language model. This system corresponds to the aforementioned automatic database backup recovery verification method based on a large language model and can be understood as a system that implements the above method. The system includes, in sequence, a user interface construction module, a historical dataset construction module, a user requirement parsing module, a backup recovery script generation module, a recovery server selection module, a recovery verification execution module, and a result feedback and optimization module. Specifically,

[0067] The user interface construction module uses the RAG platform to build the user interface and receives database backup and recovery request information input by the user in natural language through the user interface.

[0068] The historical dataset construction module collects script files and log records used in historical backup and recovery operations of several enterprise databases; converts the script files and log records into text format and stores them in the knowledge base of the RAG platform to form a historical dataset;

[0069] The user requirement parsing module parses the database backup and recovery requirement information input by the user in natural language form using a large language model and in combination with prompt words, and generates the target location information that the user needs to restore.

[0070] The backup and recovery script generation module queries the historical dataset to obtain historical backup and recovery records that match the target location information that the user needs to restore. Based on the historical backup and recovery records, it generates a backup and recovery script containing recovery resource configuration parameters through a large language model and in combination with prompt words analysis.

[0071] The recovery server selection module queries the performance data of the backup cluster servers stored in the historical dataset, selects the recovery server that meets the performance requirements determined based on the performance data from the backup cluster servers based on the estimated backup data volume in the backup recovery script, and uses a large language model.

[0072] The recovery verification execution module automatically executes the generated backup recovery script on the selected recovery server, performs recovery verification on the backup file of the target database specified by the user, monitors the execution process of the backup recovery script in real time and records the execution log. When an error is detected in the backup recovery script task execution, the error execution log is fed back to the large language model for cause analysis, and based on the analysis results of the large language model, it chooses to re-execute the backup recovery script or adjust the recovery resource configuration parameters to generate a new backup recovery script.

[0073] The result feedback and optimization module, upon detecting the completion of the backup and recovery script task, stores the complete execution log of this recovery process in the historical dataset, and simultaneously sends a task execution result notification to the user through the user interface, thus completing the automatic recovery verification of the database backup.

[0074] Preferably, in the backup and recovery script generation module, a backup and recovery verification interface is also built based on the FastAPI framework developed in Python. The backup and recovery verification interface includes a backup query interface and a parameter query interface. The backup query interface calls RMANAPI to query the backup dataset file name corresponding to the target location information in the historical dataset. Based on the backup dataset file name, the recovery resource configuration parameters required to restore the backup file of the target database are analyzed by a large language model and combined with prompt words, and then the backup and recovery script is constructed.

[0075] In the recovery server selection module, the performance data of the backup cluster servers stored in the historical dataset is queried through the parameter query interface. The performance data includes the current operating environment parameters and physical server performance indicators. Based on the estimated backup data volume in the backup recovery script, a recovery server that meets the storage space and memory capacity requirements in the current operating environment parameters and the processor performance indicator requirements in the physical server performance indicators is selected from the backup cluster servers through a large language model. The operating environment parameters include memory configuration status, storage path information, and version characteristics.

[0076] Preferably, the backup and recovery verification interface further includes a log callback interface, a backup execution interface, and a backup status query interface. In the recovery verification execution module, the recorded execution logs are fed back to the large language model in real time for analysis through the log callback interface, and the recovery strategy is dynamically adjusted based on the analysis results of the large language model; the backup execution interface calls the backup and recovery script to perform recovery verification on the backup files of the target database; the backup status query interface queries the execution logs to obtain the current backup file recovery status; the recovery strategy includes parameter optimization, script correction, and server reselection.

[0077] Preferably, the backup query interface also receives a query request containing the target database identifier and the recovery time range, and returns backup file metadata in a standardized JSON format.

[0078] This invention provides an objective and scientific database backup automatic recovery verification method and system based on a large language model. By directly parsing user natural language input through a large language model and understanding user intent, it significantly reduces reliance on database expertise, greatly lowers the barrier to entry for backup recovery verification, and improves efficiency. Furthermore, it constructs a structured knowledge base from historical backup scripts and log records, combined with RAG technology, enabling the large model to dynamically recommend optimal recovery strategies based on historical data. This avoids repetitive manual analysis of historical logs and automatically matches similar scenarios using historical datasets, effectively improving recovery success rates and reducing trial-and-error costs. In addition, this invention integrates the FastAPI interface with automated scripts to achieve a closed-loop process from requirement analysis to script generation, recovery execution, log monitoring, and failure callbacks (such as automatic retries or email notifications), effectively improving recovery verification efficiency and success rates while significantly saving labor costs.

[0079] It should be noted that the specific embodiments described above enable those skilled in the art to more fully understand the present invention, but do not limit the present invention in any way. Therefore, although the present invention has been described in detail with reference to the accompanying drawings and embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention. In short, all technical solutions and improvements that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the present invention patent.

Claims

1. A database backup automatic recovery verification method based on a large language model, characterized in that, Includes the following steps: User interface construction steps: Use the RAG platform to build the user interface, and receive database backup and recovery request information input by the user in natural language through the user interface; Historical dataset construction steps: Collect script files and log records used in historical backup and recovery operations of several enterprise databases; convert the script files and log records into text format and store them in the knowledge base of the RAG platform to form a historical dataset; User requirement analysis steps: The database backup and recovery requirement information entered by the user in natural language form is analyzed by using a large language model and combining prompt words to generate the target location information that the user needs to restore; Backup and recovery script generation steps: Query the historical dataset to obtain historical backup and recovery records that match the target location information that the user needs to restore. Then, based on the historical backup and recovery records, generate a backup and recovery script containing recovery resource configuration parameters through a large language model and in conjunction with prompt words analysis. Specifically, this includes: constructing a backup and recovery verification interface based on the FastAPI framework developed in Python, which includes a backup query interface and a parameter query interface; calling the RMAN API through the backup query interface to query the backup dataset file name corresponding to the target location information in the historical dataset; based on the backup dataset file name, analyzing the backup resource configuration parameters required to restore the backup file of the target database through a large language model and in conjunction with prompt words, and then constructing the backup and recovery script. The recovery server selection process involves: querying the performance data of the backup cluster servers stored in the historical dataset; selecting a recovery server from the backup cluster servers that meets the performance requirements determined by the performance data based on the estimated backup data volume in the backup recovery script, using a large language model; specifically, querying the performance data of the backup cluster servers stored in the historical dataset through a parameter query interface, where the performance data includes current operating environment parameters and physical server performance indicators; selecting a recovery server from the backup cluster servers that meets the storage space and memory capacity requirements in the current operating environment parameters and the processor performance indicator requirements in the physical server performance indicators based on the estimated backup data volume in the backup recovery script; and selecting a recovery server from the backup cluster servers that meets the processor performance requirements in the physical server performance indicators based on the estimated backup data volume in the backup recovery script. The operating environment parameters include memory configuration status, storage path information, and version characteristics. Recovery verification execution steps: The generated backup and recovery script is automatically executed on the selected recovery server to perform recovery verification on the backup file of the target database specified by the user. The execution process of the backup and recovery script is monitored in real time and the execution log is recorded. When an error is detected in the backup and recovery script task execution, the error execution log is fed back to the large language model for cause analysis. Based on the analysis results of the large language model, the backup and recovery script is re-executed or a new backup and recovery script is generated after adjusting the recovery resource configuration parameters. Results feedback and optimization steps: After the backup and recovery script task is detected to be completed, the complete execution log of this recovery process is stored in the historical dataset. At the same time, the task execution result notification is sent to the user through the user interface to complete the automatic recovery verification of the database backup.

2. The database backup automatic recovery verification method based on a large language model according to claim 1, characterized in that, The backup and recovery verification interface also includes a log callback interface, a backup execution interface, and a backup status query interface. In the recovery verification execution step, the log callback interface feeds back the recorded execution logs to the large language model in real time for analysis, and dynamically adjusts the recovery strategy based on the analysis results of the large language model; the backup execution interface calls the backup and recovery script to perform recovery verification on the backup files of the target database; and the backup status query interface queries the execution logs to obtain the current backup file recovery status. The recovery strategy includes parameter optimization, script modification, and server reselection.

3. The database backup automatic recovery verification method based on a large language model according to claim 1, characterized in that, The backup query interface also receives query requests containing the target database identifier and recovery time range, and returns backup file metadata in standardized JSON format.

4. The database backup automatic recovery verification method based on a large language model according to claim 1, characterized in that, In the user interface construction step, the database backup and recovery requirement information includes the target database identifier and the expected recovery time point; In the historical dataset construction step, the script file includes backup and restore commands and parameter configurations; the log records include script execution results and error information. In the user requirement parsing step, the target location information includes the target database network address, the database system identifier, and the time point to which the user expects to recover.

5. The database backup automatic recovery verification method based on a large language model according to claim 1, characterized in that, In the backup and recovery script generation step, the recovery resource configuration parameters include system global memory area configuration parameters, program global memory area configuration parameters, and recovery operation target instruction set. The system global memory area configuration parameters include memory allocation values ​​for the database buffer, shared pool, and redo log buffer. The program global memory area configuration parameters include memory limits for the sorting area, hash area, and private SQL area. The recovery operation target instruction set includes the backup set path, recovery termination point, and data file redirection rules.

6. A database backup automatic recovery verification system based on a large language model, characterized in that, It includes, in sequence, a user interface construction module, a historical dataset construction module, a user requirement analysis module, a backup and recovery script generation module, a recovery server selection module, a recovery verification execution module, and a result feedback and optimization module. The user interface construction module uses the RAG platform to build the user interface and receives database backup and recovery request information input by the user in natural language through the user interface. The historical dataset construction module collects script files and log records used in historical backup and recovery operations of several enterprise databases; converts the script files and log records into text format and stores them in the knowledge base of the RAG platform to form a historical dataset; The user requirement parsing module parses the database backup and recovery requirement information input by the user in natural language form using a large language model and in combination with prompt words, and generates the target location information that the user needs to restore. The backup and recovery script generation module queries the historical dataset to obtain historical backup and recovery records that match the target location information that the user needs to restore. Based on the historical backup and recovery records, it generates a backup and recovery script containing recovery resource configuration parameters through a large language model and in conjunction with prompt words. Specifically, this includes: building a backup and recovery verification interface based on the FastAPI framework developed in Python, which includes a backup query interface and a parameter query interface; calling the RMAN API through the backup query interface to query the backup dataset file name corresponding to the target location information in the historical dataset; and based on the backup dataset file name, analyzing the backup resource configuration parameters required to restore the backup file of the target database through a large language model and in conjunction with prompt words, thereby constructing the backup and recovery script. The recovery server selection module queries the performance data of the backup cluster servers stored in the historical dataset. Based on the estimated backup data volume in the backup recovery script, it selects a recovery server from the backup cluster servers that meets the performance requirements determined based on the performance data using a large language model. Specifically, this includes: querying the performance data of the backup cluster servers stored in the historical dataset through a parameter query interface. The performance data includes current operating environment parameters and physical server performance indicators. Based on the estimated backup data volume in the backup recovery script, it selects a recovery server from the backup cluster servers that meets the storage space and memory capacity requirements in the current operating environment parameters, and the processor performance indicator requirements in the physical server performance indicators using a large language model. The operating environment parameters include memory configuration status, storage path information, and version characteristics. The recovery verification execution module automatically executes the generated backup recovery script on the selected recovery server, performs recovery verification on the backup file of the target database specified by the user, monitors the execution process of the backup recovery script in real time and records the execution log. When an error is detected in the backup recovery script task execution, the error execution log is fed back to the large language model for cause analysis, and based on the analysis results of the large language model, it chooses to re-execute the backup recovery script or adjust the recovery resource configuration parameters to generate a new backup recovery script. The result feedback and optimization module, upon detecting the completion of the backup and recovery script task, stores the complete execution log of this recovery process in the historical dataset, and simultaneously sends a task execution result notification to the user through the user interface, thus completing the automatic recovery verification of the database backup.

7. The database backup automatic recovery verification system based on a large language model according to claim 6, characterized in that, The backup and recovery verification interface also includes a log callback interface, a backup execution interface, and a backup status query interface. In the recovery verification execution module, the recorded execution logs are fed back to the large language model in real time for analysis through the log callback interface, and the recovery strategy is dynamically adjusted based on the analysis results of the large language model; the backup execution interface calls the backup and recovery script to perform recovery verification on the backup files of the target database; and the backup status query interface queries the execution logs to obtain the current backup file recovery status. The recovery strategy includes parameter optimization, script modification, and server reselection.

8. The database backup automatic recovery verification system based on a large language model according to claim 6, characterized in that, The backup query interface also receives query requests containing the target database identifier and recovery time range, and returns backup file metadata in standardized JSON format.

Images