A method and device for disaster recovery construction, a bank core system and a medium

Abstract

The application discloses a disaster recovery construction method and device, a bank core system and a medium, and relates to the technical field of disaster recovery. The method comprises the following steps: obtaining target data and a virtual tape library; wherein the virtual tape library comprises a virtual drive and a virtual tape, and the virtual tape is obtained by using a file simulation; the target data is backed up to the virtual tape through the virtual drive; and the target data is backed up to a target device through remote mirroring of the virtual tape to realize off-site disaster recovery reservation of the target data. The method can perform disaster recovery construction only by using the virtual tape library, and is convenient for small and medium-sized enterprise cores to perform disaster recovery construction. In addition, the virtual tape library is used to realize multiple backup of the target data, and the reliability of the data is ensured. Finally, the virtual tape is simulated by using a file in the virtual tape library, data transmission and backup are facilitated, and the disaster recovery construction requirement of the small and medium-sized enterprise core is met.

Description

Technical Field

[0001] This application relates to the field of disaster recovery technology, and in particular to a method, apparatus, bank core system and medium for disaster recovery construction. Background Technology

[0002] In the event of anomalies such as fires or earthquakes, computer equipment may malfunction, leading to data unavailability. Therefore, disaster recovery is necessary, as is the case with core banking systems. High availability disaster recovery can be categorized into three levels: business-level, application-level, and data-level. Application-level disaster recovery allows for rapid production restoration but requires significant investment and complex technology. Besides adequate infrastructure, sufficient personnel are also required, such as in a dual-active data center. Business-level disaster recovery requires the necessary hardware and software for application operation, as well as the deployment of corresponding application programs to ensure necessary business operations can be maintained when disaster recovery is needed. Data-level disaster recovery requires mainframes, storage, operating systems, etc. It is evident that the construction of different levels of disaster recovery currently requires a large amount of equipment and involves complex implementation processes, making it difficult to implement for core disaster recovery systems in small and medium-sized enterprises.

[0003] Therefore, how to meet the core disaster recovery needs of small and medium-sized enterprises as much as possible is an urgent problem to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a method, device, core banking system, and medium for disaster recovery construction, to meet the core disaster recovery construction needs of small and medium-sized enterprises.

[0005] To address the aforementioned technical problems, this application provides a method for disaster recovery construction, comprising:

[0006] Acquire target data and a virtual tape library; wherein the virtual tape library includes a virtual driver and a virtual tape, and the virtual tape is simulated using files;

[0007] The target data is backed up to the virtual tape via the virtual drive;

[0008] The target data is backed up to the target device through remote mirroring of the virtual tape to achieve off-site disaster recovery retention of the target data.

[0009] Preferably, there are multiple virtual drives, and backing up the target data to the virtual tape via the virtual drive includes:

[0010] The target data is automatically and / or manually backed up to the target device in parallel via multiple virtual drives.

[0011] Preferably, in the case of backing up the target data to the virtual tape via the virtual drive, the method further includes:

[0012] Retrieve target data that has changed since the backup task was started;

[0013] The target data of the change is cached in memory so that the business process can access the target data of the change in memory.

[0014] Preferably, backing up the target data to the target device via remote mirroring of the virtual tape includes:

[0015] The target data for the change will be used as the data to be backed up.

[0016] Compress the data to be backed up;

[0017] The compressed data to be backed up is backed up to the target device via a remote mirroring of the virtual tape.

[0018] Preferably, after backing up the target data to the virtual tape via the virtual drive, the method further includes:

[0019] Record the information of the virtual magnetic tape.

[0020] Preferably, after backing up the target data to the target device via remote mirroring of the virtual tape, the method further includes:

[0021] Conduct disaster recovery drills at a fixed frequency.

[0022] Preferably, in the case of backing up the target data to the target device via a remote mirror of the virtual tape, the method further includes:

[0023] Record data during the backup process.

[0024] To address the aforementioned technical problems, this application also provides a disaster recovery construction apparatus, comprising:

[0025] The acquisition module is used to acquire target data and a virtual tape library; wherein the virtual tape library includes a virtual driver and a virtual tape, and the virtual tape is simulated using a file.

[0026] The first backup module is used to back up the target data to the virtual tape via the virtual drive;

[0027] The second backup module is used to back up the target data to the target device through remote mirroring of the virtual tape to achieve off-site disaster recovery retention of the target data.

[0028] To address the aforementioned technical problems, this application also provides a core banking system, comprising:

[0029] Memory, used to store computer programs;

[0030] A processor is used to execute the computer program to implement the steps of the disaster recovery construction method described above.

[0031] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the disaster recovery construction method described above.

[0032] The disaster recovery construction method provided in this application includes: acquiring target data and a virtual tape library; wherein the virtual tape library includes a virtual drive and a virtual tape, the virtual tape being simulated using files; backing up the target data to the virtual tape via the virtual drive; and backing up the target data to the target device via a remote mirror of the virtual tape to achieve off-site disaster recovery retention of the target data. This method only requires a virtual tape library for disaster recovery construction, making it convenient for small and medium-sized enterprises to build their core disaster recovery systems. Secondly, the virtual tape library enables multiple backups of the target data, ensuring data reliability. Finally, the virtual tape library simulates a virtual tape using files, facilitating data transfer and backup, thus meeting the disaster recovery construction needs of small and medium-sized enterprises.

[0033] In addition, this application also provides a disaster recovery construction device, a bank core system, and a computer-readable storage medium, which correspond to the disaster recovery construction method mentioned above and have the same effect. Attached Figure Description

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

[0035] Figure 1 A method for disaster recovery construction is provided in the embodiments of this application;

[0036] Figure 2 A schematic diagram of a remote mirror provided in an embodiment of this application;

[0037] Figure 3 A structural diagram of a disaster recovery construction apparatus provided in one embodiment of this application;

[0038] Figure 4 This is a structural diagram of a bank core system provided in another embodiment of this application. Detailed Implementation

[0039] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0040] The core of this application is to provide a method, device, core banking system, and medium for disaster recovery construction, to meet the disaster recovery construction needs of small and medium-sized enterprises.

[0041] In the event of anomalies such as fires or earthquakes, data centers may lose critical information, leading to severe losses for businesses and users. Therefore, every enterprise needs appropriate disaster recovery measures. Currently, high availability disaster recovery is categorized into three types: business-level, application-level, and data-level. These three types require extensive equipment, incur high costs, and are technically complex. While feasible for some large enterprises, they are typically unsuitable for small and medium-sized enterprises (SMEs). Therefore, this application utilizes virtual tape libraries to implement disaster recovery for SMEs. It should be noted that this method of using virtual tape libraries for disaster recovery is not limited to SMEs; it can also be employed by some large enterprises.

[0042] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 A disaster recovery construction method provided in the embodiments of this application, such as Figure 1 As shown, the method includes:

[0043] S10: Obtain target data and virtual tape library; the virtual tape library includes virtual driver and virtual tape, and the virtual tape is simulated using a file.

[0044] Virtual tape libraries utilize a file system to simulate tape library devices and use files to simulate physical tape libraries. They connect via a fiber optic link to the IBM AS400 device driver, recognizing themselves as tape libraries and driver devices, and accessing them using tape library commands. Virtual tape libraries simulate Linear Tape Open (LTO) tape libraries, connecting to the AS400 device driver via an interface, automatically configuring the tape library and driver devices. Accessing virtual tape libraries from the AS400 device is virtually indistinguishable from accessing physical tape libraries. Virtual tape libraries use files to simulate physical tapes, perfectly resolving issues such as tape media aging and physical damage. Using virtual tapes is no different from writing data to a file system. Multiple Logitech drivers can easily be virtualized within a virtual tape library, overcoming the limitations of physical tape drivers and maximizing the advantages of concurrent backup and recovery. For example, a tape library can virtualize 32 drivers, achieving a maximum backup parallelism of 32. Theoretically, the data in virtual tape library drivers is only limited by the operating system's support for the device. Virtual tape libraries simulate virtual tapes through files on top of a file system. Because files can be transferred and compressed, virtual tape libraries make it easy to back up data.

[0045] During disaster recovery, it is typically necessary to back up target data. The target data is not limited; it is selected based on the actual situation. Target data can also be understood as core data. For core banking systems, target data usually consists of account-related information, which could be the application hosting the accounts, data within the accounts, intermediate data, etc. When backing up target data, the backup content can be managed, allowing for precise location of the data to be restored during data recovery, facilitating data recovery.

[0046] S11: Back up the target data to a virtual tape via a virtual drive.

[0047] The target data identified in the above steps is backed up to virtual tape using a virtual drive. The backup method is not limited; parallel or non-parallel backups can be performed. In practice, to minimize the backup time window, parallel backup is preferred. To achieve parallel backup, multiple virtual drives are typically used for synchronous backup.

[0048] S12: Back up the target data to the target device via remote mirroring of virtual tape to achieve off-site disaster recovery retention of the target data.

[0049] Figure 2 This is a schematic diagram illustrating a remote mirror provided in an embodiment of this application. For example... Figure 2As shown, locally, host 1 is connected to switch 2 via fiber optic cable, and switch 2 is connected to tape library device 3 via fiber optic cable. Through remote mirroring of the virtual tape library, the same device appears remotely as locally; that is, host 1 is connected to switch 2 via fiber optic cable, and switch 2 is connected to tape library device 3 via fiber optic cable. Remote mirroring of the virtual tape library enables disaster recovery requests for off-site storage of core data. The virtual tape library itself is still a UNIX host. Through remote mirroring technology of the UNIX file system, or through more efficient processing and transmission applications, the purpose of mirroring local data to a remote node is achieved. The target data is backed up to the target device through remote mirroring of the virtual tape. Here, the specific target device or the number of target devices is not limited; it can be a remote device, multiple remote devices, etc. In this embodiment, the target data is first backed up to a virtual disk, and then backed up to the target device through remote mirroring of the virtual tape. This achieves at least two backups of the target data, effectively preventing data from being backed up on a single device and becoming inaccessible if that device fails.

[0050] The disaster recovery construction method provided in this embodiment includes: acquiring target data and a virtual tape library; wherein the virtual tape library includes a virtual drive and a virtual tape, and the virtual tape is simulated using files; backing up the target data to the virtual tape via the virtual drive; and backing up the target data to the target device via a remote mirror of the virtual tape to achieve off-site disaster recovery retention of the target data. This method only requires a virtual tape library for disaster recovery construction, making it convenient for small and medium-sized enterprises to carry out disaster recovery construction; secondly, the virtual tape library enables multiple backups of the target data, ensuring data reliability; finally, the virtual tape library simulates a virtual tape using files, facilitating data transmission and backup, and meeting the disaster recovery construction needs of small and medium-sized enterprises.

[0051] To improve the efficiency of backing up target data, multiple virtual drives are configured in the implementation. Backing up target data to virtual tape via virtual drives includes:

[0052] The target data is automatically and / or manually backed up to the target device in parallel via multiple virtual drives.

[0053] Parallel backup typically utilizes multiple backup processes to shorten the backup time window. For example, in a bank's end-of-day backup of 12TB of data, using only one drive (e.g., LTO7) would achieve a backup speed of approximately 1.5TB / hour, requiring 8 hours. Using eight drives reduces this to about one hour. However, the backup process includes data integrity checks, data correlation checks, and tape preparation, necessitating increased concurrency to meet backup estimates. For instance, using 12 virtual drives to back up 12TB of data still requires approximately one hour for the effective backup window. Parallel backup includes automatic and manual parallel backup. Automatic parallel backup uses backup software to automatically back up a single object to multiple tapes. This results in a relatively balanced backup load, with each backup task completing at roughly the same time. Manual backup task dispatch achieves parallel backup by preventing single objects from being saved across tapes, requiring data to be grouped by size as much as possible. However, with changes to core data, manual grouping often requires reactive adjustments, and uneven backup task distribution can lead to significant differences in completion times between different backup tasks. In practice, backups can be performed using automatic parallel backup, manual parallel backup, or a combination of both. No specific backup method is specified here.

[0054] In this embodiment, manual backup groups are preferred. Each group backs up the assigned objects, and each object is not saved across tapes. The purpose of this is to improve the deduplication ratio of the virtual tape library in the mirror transfer algorithm. Even if the same object is backed up repeatedly, and the object changes significantly each time, this grouping makes it easier to improve the deduplication ratio when judging the changed parts of the object, thus reducing the size of objects that need to be mirrored every day.

[0055] This embodiment provides a configuration of multiple drive devices, which achieves the backup of target data through parallel backup, thereby improving the efficiency of data backup.

[0056] The backup script needs to consider the nodes where the backup operation occurs: production machines and backup machines, including disaster recovery machines. When the backup occurs on a production node, the impact of the backup operation on production is particularly important. During the backup process, there is usually a time limit for locking objects; if the object locking time is too long, it will affect the normal operation of the business. Therefore, as a preferred implementation, when backing up the target data to virtual tape via a virtual drive, the script further includes:

[0057] Retrieve target data that has changed since the backup task was started;

[0058] Cache the changed target data in memory so that business processes can access the changed target data in memory.

[0059] When backups occur on production nodes, the impact of backup actions on production is particularly important. Backup actions lock backup objects, releasing the locks only upon completion. For banking operations, especially for critical data such as transaction logs and user information tables that require frequent changes, prolonged table locking during backups can inevitably cause operational disruptions. This necessitates the use of dynamic backup technology. A bitmap table in memory is used to track changes to all backup objects after the backup task begins. If changes occur, they are buffered in memory. The backup task still reads the complete object data from storage, while the transaction process accesses the changed portion in memory. All memory changes are only written to disk upon backup completion. The moment memory is ready is called the sync point, after which the backup process truly begins, and the locks on the backup objects are released. Dynamic backups also involve object locking, but the locking time is much shorter than static backups, resulting in a significantly smaller impact on production. When backups occur on backup machines and disaster recovery machines, the impact on production is less of a concern, but the object locking time and related processes such as backup completion and logging still need to be considered.

[0060] This embodiment provides a method for backing up target data to virtual tape via a virtual drive. It acquires target data that has changed after the backup task is started and caches the changed target data in memory so that business processes can access it from memory. The locking time for dynamic backup technology is only the time counted using a bitmap table, while static backup requires consistency between memory and disk data, meaning the entire backup process involves locking the target data. Therefore, the dynamic backup method in this embodiment, with its shorter locking time, can ensure that business operations can continue normally during backup as much as possible.

[0061] Remote mirroring of virtual tapes differs from file system mirroring. Simply mirroring the backup results to a remote node is insufficient. Firstly, synchronizing mirrored data significantly slows down the backup process. Secondly, the bandwidth and quality of the communication lines between the two nodes severely impact communication speed. In practice, reducing the size of the transferred data improves backup speed. A preferred implementation involves backing up the target data to the target device via remote mirroring of virtual tapes, including:

[0062] The changed target data will be used as the data to be backed up.

[0063] Compress the data to be backed up;

[0064] The compressed data to be backed up is backed up to the target device via a remote mirroring of a virtual tape.

[0065] There are no limitations on the method for reducing data transmission size. This embodiment reduces the transmitted data size through data deduplication and data compression. In practice, only one of the above methods can be used to reduce the transmitted data size, or both methods can be used together. In this embodiment, both methods are used to make the transmitted data smaller and the backup speed faster.

[0066] When performing data deduplication, the changed target data is obtained and used as the data to be backed up, i.e., the data to be transferred. The method for determining the changed target data is not limited; it can be comparing the object's modification timestamp, or comparing the MD5 hash value of the same object with the MD5 hash value of the same object from the previous day, etc. When local changes occur in the data, the changed portion is marked, and the changed target data is used as the data to be backed up, instructing the virtual tape library remote mirror to only process the changed portion.

[0067] Data compression uses a high-compression algorithm to compress the data before sending it to the remote mirror node. The remote node receives the data, decompresses it, and restores it to the specified directory. In this embodiment, the changed target data is compressed, and the compressed data is backed up to the target device via a remote mirror of a virtual tape.

[0068] In practice, backup efficiency can be improved by using the highest possible driver version, such as LTO8; increasing parallelism by using as many drivers as possible; and ensuring that backups occur in memory by increasing memory configuration in specific memory pools.

[0069] The method for backing up target data to a target device via remote mirroring of virtual tape provided in this embodiment reduces the amount of data transmitted by using data deduplication and data compression methods, thereby increasing the efficiency of backup.

[0070] In order to quickly locate the data to be recovered during data recovery, as a preferred implementation, after backing up the target data to a virtual tape via a virtual drive, the following steps are also included:

[0071] Record information from a virtual magnetic tape.

[0072] A crucial aspect of tape backup is the archiving of the backup results, including tape label, tape sequence, backup command, backup directory, backup objects, backup size, backup device, whether the backup was serial and if so, other tape labels for serial backups, whether the backup was parallel and if so, other tape labels for parallel backups, whether there were any errors in the backup, and specific error messages. Because the tape information is recorded, the backup records allow for precise location of the virtual tape volume and backup sequence containing the data to be recovered; it also allows for determining whether the necessary serial or parallel tape groups are in place; it enables the assembly of recovery commands using backup parameters; and it reserves the necessary space for data recovery.

[0073] The method provided in this embodiment for recording information of a virtual tape after backing up target data to a virtual tape via a virtual drive facilitates data recovery when data is damaged, and allows users to easily view and understand the information of the data on the tape when the data is not damaged.

[0074] The above embodiments complete the construction of disaster recovery; however, in practice, various factors may cause disaster recovery to become unavailable. Therefore, to ensure the availability of disaster recovery, as a preferred implementation, after backing up the target data to the target device via a remote mirror of virtual tape, the following steps are also included:

[0075] Conduct disaster recovery drills at a fixed frequency.

[0076] After disaster recovery infrastructure is built, regular disaster recovery drills are needed to test its availability. In practice, these drills can be conducted at a fixed frequency or a non-fixed frequency; no specific limit is imposed here. To ensure timely understanding of disaster recovery availability, this embodiment preferably uses a fixed frequency for disaster recovery drills. The specific frequency is not limited and can be selected based on actual circumstances.

[0077] The technologies used for data recovery through disaster recovery include the following:

[0078] Technique 1: Recovery using the backup records described in the above embodiments.

[0079] Technique 2: During the recovery process, if an object needs to be overwritten, the original object is renamed to avoid overwriting the original data. For example, if CBSADPFM21 needs to be recovered, the original file will be renamed to CBSAD00001. If the name already exists, it will be renamed to CBSAD00002.

[0080] Technique 3: If a single object fails during the recovery process, record the object name and failure keywords, and continue to recover the next object.

[0081] Business verification typically employs two methods: verifying data validity and consistency by running end-of-day batch processing; and verifying the feasibility of executing counter transactions by establishing counter access paths.

[0082] The disaster recovery service drills conducted at a fixed frequency, as provided in this embodiment, enable timely assessment of disaster recovery availability and prompt recovery of data that has failed.

[0083] In order to understand the backup process, in a preferred implementation, when backing up the target data to the target device via a remote mirroring of a virtual tape, the following additional steps are included:

[0084] Record data during the backup process.

[0085] This embodiment utilizes the monitoring function of the virtual tape library data mirror to record data during the backup process. Monitoring data includes: whether the monitoring action is initiated; the percentage of monitoring data sent; the average data transmission rate; the data directories and specific object names at the sending and receiving ends of the data transmission; and the specific values ​​of the deduplication ratio and compression ratio, etc.

[0086] The data recorded during the backup process provided in this embodiment allows for understanding the entire backup process based on the recorded data.

[0087] The above embodiments have described the disaster recovery construction method in detail. This application also provides embodiments of disaster recovery construction apparatus and corresponding bank core systems. It should be noted that this application describes the embodiments of the apparatus from two perspectives: one based on functional modules and the other based on hardware.

[0088] Figure 3 A structural diagram of a disaster recovery construction apparatus provided in one embodiment of this application. This embodiment, based on functional modules, includes:

[0089] The acquisition module 10 is used to acquire target data and a virtual tape library; the virtual tape library includes a virtual driver and a virtual tape, and the virtual tape is simulated using a file.

[0090] The first backup module 11 is used to back up the target data to a virtual tape via a virtual drive;

[0091] The second backup module 12 is used to back up the target data to the target device via remote mirroring of virtual tape to achieve off-site disaster recovery retention of the target data.

[0092] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0093] The disaster recovery construction apparatus provided in this embodiment acquires target data and a virtual tape library through an acquisition module; backs up the target data to a virtual tape via a virtual drive through a first backup module; and uses a second backup module to back up the target data to a target device via a remote mirror of the virtual tape to achieve off-site disaster recovery retention of the target data. This apparatus only requires a virtual tape library for disaster recovery construction, making it convenient for small and medium-sized enterprises to build disaster recovery systems. Secondly, the virtual tape library enables multiple backups of the target data, ensuring data reliability. Finally, the virtual tape library uses files to simulate a virtual tape, facilitating data transfer and backup, thus meeting the disaster recovery construction needs of small and medium-sized enterprises.

[0094] Figure 4 This is a structural diagram of a bank core system provided as another embodiment of this application. This embodiment is based on a hardware perspective, such as... Figure 4 As shown, the core banking system includes:

[0095] Memory 20 is used to store computer programs;

[0096] The processor 21 is used to execute computer programs to implement the steps of the disaster recovery construction method mentioned in the above embodiments.

[0097] The core banking system provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0098] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0099] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the disaster recovery construction method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the disaster recovery construction method mentioned above.

[0100] In some embodiments, the bank core system may also include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0101] Those skilled in the art will understand that Figure 4 The structure shown does not constitute a limitation on the core banking system and may include more or fewer components than illustrated.

[0102] The core banking system provided in this application includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a disaster recovery construction method, with the same effect as above.

[0103] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments.

[0104] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0105] The computer-readable storage medium provided in this application includes the disaster recovery construction method mentioned above, and has the same effect.

[0106] The foregoing has provided a detailed description of a disaster recovery construction method, apparatus, bank core system, and medium provided in this application. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0107] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for disaster recovery construction, characterized in that, include: Acquire target data and virtual tape library; The virtual tape library includes a virtual driver and a virtual tape, wherein the virtual tape is simulated using files; The target data is backed up to the virtual tape via the virtual drive; The target data is backed up to the target device through remote mirroring of the virtual tape to achieve off-site disaster recovery retention of the target data; The virtual drives are multiple, and the step of backing up the target data to the virtual tape via the virtual drives includes: The target data is automatically and / or manually backed up to the target device in parallel using multiple virtual drives. When a backup occurs on a production node, the backup action locks the backup object, and the object lock is released only when the backup is complete. Dynamic backup technology is used. A bitmap table is used in memory to count whether all backup objects have changed after the backup task is started. If changes have occurred, they need to be buffered in memory. The backup task still reads the complete object data from storage, while the transaction process accesses the changed part in memory. All memory changes can be written to disk when the backup is finished. The moment when memory is ready is called the synchronization point. After this, the backup action really begins and the lock on the backup object is released.

2. The method for disaster recovery construction according to claim 1, characterized in that, In the case of backing up the target data to the virtual tape via the virtual drive, the method further includes: Retrieve target data that has changed since the backup task was started; The target data of the change is cached in memory so that the business process can access the target data of the change in memory.

3. The method for disaster recovery construction according to claim 2, characterized in that, The step of backing up the target data to the target device via remote mirroring of the virtual tape includes: The target data for the change will be used as the data to be backed up. Compress the data to be backed up; The compressed data to be backed up is backed up to the target device via a remote mirroring of the virtual tape.

4. The method for disaster recovery construction according to any one of claims 1 to 3, characterized in that, After backing up the target data to the virtual tape via the virtual drive, the method further includes: Record the information of the virtual magnetic tape.

5. The method for disaster recovery construction according to claim 4, characterized in that, After backing up the target data to the target device via remote mirroring of the virtual tape, the method further includes: Conduct disaster recovery drills at a fixed frequency.

6. The method for disaster recovery construction according to claim 5, characterized in that, In the case of backing up the target data to the target device via a remote mirror of the virtual tape, the method further includes: Record data during the backup process.

7. A disaster recovery construction device, characterized in that, include: The acquisition module is used to acquire target data and virtual tape libraries; The virtual tape library includes a virtual driver and a virtual tape, wherein the virtual tape is simulated using files; The first backup module is used to back up the target data to the virtual tape via the virtual drive; The second backup module is used to back up the target data to the target device through remote mirroring of the virtual tape to achieve off-site disaster recovery retention of the target data; The virtual drivers are multiple, and the first backup module is specifically used to: automatically and / or manually back up the target data to the target device through multiple virtual drivers in parallel. When a backup occurs on a production node, the backup action locks the backup object, and the object lock is released only when the backup is complete. Dynamic backup technology is used. A bitmap table is used in memory to count whether all backup objects have changed after the backup task is started. If changes have occurred, they need to be buffered in memory. The backup task still reads the complete object data from storage, while the transaction process accesses the changed part in memory. All memory changes can be written to disk when the backup is finished. The moment when memory is ready is called the synchronization point. After this, the backup action really begins and the lock on the backup object is released.

8. A core banking system, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the disaster recovery construction method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the disaster recovery construction method as described in any one of claims 1 to 6.

Images