CN112052128A - Disaster recovery method and device and electronic equipment - Google Patents
Disaster recovery method and device and electronic equipment Download PDFInfo
- Publication number
- CN112052128A CN112052128A CN201910489439.8A CN201910489439A CN112052128A CN 112052128 A CN112052128 A CN 112052128A CN 201910489439 A CN201910489439 A CN 201910489439A CN 112052128 A CN112052128 A CN 112052128A
- Authority
- CN
- China
- Prior art keywords
- target
- file system
- file
- target directory
- hard disk
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 95
- 238000011084 recovery Methods 0.000 title claims abstract description 47
- 238000004590 computer program Methods 0.000 claims description 10
- 238000013507 mapping Methods 0.000 claims description 7
- 230000008439 repair process Effects 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 6
- 238000012423 maintenance Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000007547 defect Effects 0.000 description 2
- 230000002950 deficient Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1608—Error detection by comparing the output signals of redundant hardware
- G06F11/1612—Error detection by comparing the output signals of redundant hardware where the redundant component is persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2089—Redundant storage control functionality
Abstract
The embodiment of the disclosure discloses a disaster recovery method, a disaster recovery device and electronic equipment. One embodiment of the method comprises: receiving information of a fault of a target hard disk mounted with a target directory; restarting the application program corresponding to the target directory; and re-running the application program based on the virtual file system mounted to the target directory. According to the scheme, the application program arranged on the server can be operated again in a short time without waiting for repair of a fault hard disk or replacement of a new hard disk, so that the service can run normally. Corresponding services can be continuously provided to the user during the failure of the server hard disk.
Description
Technical Field
The present disclosure relates to the field of internet technologies, and in particular, to a disaster recovery method and apparatus, and an electronic device.
Background
With the development of the internet, a large amount of internet services are deployed on computer servers. The main resources of the computer server comprise a CPU, a memory, a network, a hard disk and the like. The failure rate of the hard disk is the highest, and the failure of the hard disk usually results in the unavailability of the whole server, thereby affecting the operation of the service and the waste of resources.
The main solution at present is to take the server offline and get the server online again after physical maintenance.
The main disadvantages of the existing method for physically maintaining the server are that the physical maintenance time is long (usually days to weeks are different), during the maintenance period, the hard disk and other resources cannot be utilized, the operation of the server is affected, and the service cannot normally operate. In this way, the user's access to the server is affected during the maintenance period.
Disclosure of Invention
The embodiment of the disclosure provides a disaster recovery method, a disaster recovery device and an electronic device, which can run a server during hard disk maintenance to ensure normal operation of a service, so as to achieve the purpose of not influencing access of a user during hard disk failure.
In a first aspect, an embodiment of the present disclosure provides a disaster recovery method, where the method includes: receiving information of a fault of a target hard disk mounted with a target directory; restarting the application program corresponding to the target directory; and re-running the application program based on the virtual file system mounted to the target directory.
In a second aspect, an embodiment of the present disclosure provides a disaster recovery device, which is applied to a server and includes a receiving unit, configured to receive information that a target hard disk mounted with a target directory fails; the restarting unit is used for restarting the application program corresponding to the target directory; and the rerun unit is used for rerunning the application program based on the virtual file system mounted to the target directory.
In a third aspect, an embodiment of the present disclosure provides an electronic device, including: one or more processors; a storage device, configured to store one or more programs, where when the one or more programs are executed by one or more processors, the one or more processors implement the steps of the disaster recovery method according to the first aspect.
In a fourth aspect, an embodiment of the present disclosure provides a computer-readable medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the disaster recovery method according to the first aspect.
According to the disaster recovery method, the disaster recovery device and the electronic equipment, the information that the target hard disk mounted with the target directory fails is received, and the application program corresponding to the target directory is restarted; and re-running the application program based on the virtual file system mounted to the target directory. According to the scheme, the application program arranged on the server can be operated again in a short time without waiting for repair of a fault hard disk or replacement of a new hard disk, so that the service can run normally. Corresponding services can be continuously provided to the user during the failure of the server hard disk.
Drawings
The drawings are included to provide a further understanding of the disclosure, and are not to be construed as limiting the disclosure. Wherein:
FIG. 1 is a flow diagram of one embodiment of a disaster recovery method according to the present disclosure;
FIG. 2 is a schematic diagram of an application scenario of a disaster recovery method according to the present disclosure;
FIG. 3 is a flow diagram of yet another embodiment of a disaster recovery method according to the present disclosure;
FIG. 4 is a schematic block diagram of one embodiment of a disaster recovery device according to the present disclosure;
FIG. 5 is an exemplary system architecture to which the disaster recovery method of one embodiment of the present disclosure may be applied;
fig. 6 is a schematic diagram of a basic structure of an electronic device provided according to an embodiment of the present disclosure.
Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the present disclosure are included to facilitate understanding. They should be considered as merely exemplary. It will thus be appreciated by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure.
It should be noted that the embodiments provided in the present disclosure can be applied to a server running on various operating system platforms. The operating system may include, for example, a Linux operating system, a Unix operating system, a Windows operating system, and the like.
It should be noted that, in the present disclosure, the embodiments and features of the embodiments may be combined with each other without conflict.
Referring to fig. 1, a flow of one embodiment of a disaster recovery method according to the present disclosure is shown. As shown in fig. 1, the disaster recovery method includes the following steps:
Generally, a user may use a terminal device to interact with a server through a wired or wireless connection, for example, to send an information acquisition request to the server, or to send data to the server for saving on the server side, and so on. The server can run corresponding application programs to complete the interaction with the user. Here, the application program may be any preset application program. The preset application program may analyze the information obtaining request, for example, to obtain the display information indicated by the information obtaining request from a local database or the internet. Or the preset application program can receive data sent by the user through the terminal equipment, so as to be stored in the server and the like. In addition, various kinds of related data related to the operation of the preset application program can be generated in the server. Such as a preset application execution log, etc. The above-mentioned related data may be stored in a specific directory set by the server. In this embodiment, one type of related data may correspond to one directory. In some application scenarios, a directory may mount a physical hard disk.
Here, the physical Hard Disk may be various Hard disks mounted to the server, such as a Solid State Drive (Solid State Drive), a Hybrid Hard Disk (HHD), a mechanical Hard Disk (Hard Disk Drive, HDD), or a block device based on a network protocol (e.g., iSCSI, Ceph).
The directory corresponding to one kind of related data may be set as the target directory in advance. The physical hard disk mounted by the target directory may be a target hard disk.
In the operation process of the server, because the number of access users is large, the frequency of reading and writing supported by the hard disk corresponding to each directory is high, and therefore the hard disk is easy to damage.
In the prior art, when a hard disk is damaged, for example, a hard disk mounted in a log directory is damaged, a system where a server is located may not detect a file system corresponding to the hard disk, or may detect that a storage space of an existing file system is insufficient, and then the operation of a preset application program may be stopped. Accordingly, the service provided by the preset application program to the user is also stopped until the repaired hard disk is mounted or a new hard disk is mounted. Both repairing a failed hard disk and replacing a new hard disk require a long time. For example, tens of minutes to hours or even days. In this longer time, the preset application program cannot run normally, which affects the server to provide the relevant service to the user normally.
In order to improve the above phenomenon, the scheme provided by each step of the present embodiment may be used.
In the server, a fault detection module may be provided, which is responsible for detecting whether the hard disk mounted in the target directory in the server has a fault in real time. When the failure information of the target hard disk mounted by the target directory is detected, the failure information of the target hard disk can be sent to an operating system of the server.
And 102, restarting the application program corresponding to the target directory.
In this embodiment, because a failure occurs in the target hard disk mounted in the target directory, the application program corresponding to the target directory cannot normally run, and the application program may be restarted.
The restarting of the application program corresponding to the target directory may include, for example, closing the application program and releasing resources corresponding to the application program running in the operating system; and re-determining resources required by the running of the application program, and then running the application program by using the resources.
And 103, re-running the application program based on the virtual file system mounted to the target directory.
In this embodiment, the target directory may mount the virtual file system. When the application program is restarted in step 102, the operating system of the server detects whether the target directory corresponding to the application program corresponds to a file system. In this embodiment, the file system may be a virtual file system. When detecting that the virtual file system is mounted to the target directory, the operating system can rerun the application program.
In some application scenarios, the virtual file system may be mounted to the target directory in advance, and is covered by the file system corresponding to the target hard disk when the target hard disk operates normally. In these application scenarios, after receiving the information of failure of the target hard disk mounted with the target directory in step 101, the failed target hard disk may be dynamically uninstalled to expose the virtual file system already mounted to the target directory and covered by the file system corresponding to the target hard disk. In these application scenarios, after dynamically uninstalling the failed target hard disk, the previously overlaid virtual file system mounted to the target directory is exposed. Thus, when the operating system of the server detects the running environment of the application program when the application program is restarted in step 102, the virtual file system is detected. So that the operating system determines that the operating environment of the application program is normal. Thus, in step 103, the application is re-run based on the virtual file system mounted to the target directory.
In some other application scenarios, before restarting the application program corresponding to the target directory in step 102, the disaster recovery method may further include: the virtual file system is mounted to the target directory. In these application scenarios, the server is not required to be restarted, but only the virtual file system needs to be hung in the target directory before the application program is restarted, i.e. the virtual file system can be detected by the operating system when the application program is restarted. Thereby ensuring that the application program can be started normally.
In other application scenarios, the server may be restarted before step 102, and during the process of starting the server, the virtual file system is mounted to the target directory before the application program corresponding to the target directory is restarted. The application program corresponding to the target directory is restarted at step 102. In step 103, the virtual file system may be mounted to the target directory according to the reboot of the server. Therefore, when the application program corresponding to the target directory is restarted, the virtual file system corresponding to the target directory can be detected, and the application program is operated again.
It should be noted that the virtual file system in this embodiment is a virtualized file system. Which have corresponding virtual attributes. The virtual attributes may include, for example, a virtual memory size, a virtual name, and the like. The virtual memory size is a large memory space registered when registering with the operating system, but actually, the memory space does not have a corresponding physical device.
Therefore, as the target directory corresponding to the application program is mounted with the virtual file system, when the operating system detects the operating environment of the application program corresponding to the target directory, the virtual file system makes up the operating environment defect caused by the damage of the target hard disk, so that the normal operation of the application program can be realized. Compared with the prior art that the operation of the application program needs to be resumed after the defective hard disk is uninstalled, the repaired hard disk or the new hard disk is replaced, the method provided by the embodiment can resume the operation of the application program in a short time (for example, within 1 minute).
Referring to fig. 2, a schematic diagram of an application scenario of the disaster recovery method of the present disclosure is shown. As shown in fig. 2, a user 201 initiates an information acquisition request to a terminal apparatus 202. The information acquisition request here may be various information acquisition requests. Such as a request to obtain information by searching, a request to obtain information by opening a page via a link, and so on. The terminal apparatus 202 may transmit the above-described information acquisition request to the server 203. The server 203 may receive the information acquisition request sent by the terminal device 202 through a wired connection manner or a wireless connection manner. The server may operate as a preset application that requests the service for information acquisition. Before the server runs the preset application program or in the process of running the application program, the information 204 that the target hard disk mounted with the target directory fails is received. The target directory may be a data saving directory corresponding to the preset application program. The server 203 may restart the application 205 corresponding to the target directory. The server 203 then re-runs the application 206 based on the virtual file system mounted to the target directory. After the application program determines the information corresponding to the information acquisition request of the user, the server 203 transmits the information 208 determined by the preset application program to the terminal device 202 of the user.
The method provided by the embodiment of the disclosure receives the information that the target hard disk mounted with the target directory has a fault; then, restarting an application program corresponding to the target directory; and finally, based on the virtual file system mounted to the target directory, the application program is re-run. According to the scheme, the defect of the running environment caused by damage of the target hard disk is overcome through the virtual file system, so that the application program can run normally. Compared with the method in the prior art that when the hard disk fails, the defective hard disk needs to be unloaded, the repaired hard disk or the new hard disk needs to be replaced, and the application program operation needs to be recovered, the method provided by the embodiment can recover the application program operation within a short time (for example, within 1 minute). The recovery time of the application program is greatly shortened.
Optionally, before receiving the information that the target hard disk mounted with the target directory fails in step 101, the disaster recovery method further includes:
registering the information of the virtual file system with an operating system corresponding to a server; the information of the virtual file system at least comprises identification information of a target directory to which the virtual file system is mounted.
In these optional implementation manners, when the information of the virtual file system is registered with the operating system corresponding to the server, the operating system may be told the virtual storage space corresponding to the virtual file system, and the attributes of the virtual file system, such as the virtual name corresponding to the virtual file system, etc. Such that the virtual file system can be detected by the operating system of the server. When the virtual file system is mounted to the target directory. The operating system can detect whether the running environment corresponding to the application program is normal or not according to the attribute of the virtual file system.
In addition, the information of the virtual file system includes at least identification information of a target directory to which the virtual file system is mounted. In this way, the virtual file system can mount to the target directory.
Further optionally, the disaster recovery method further includes: registering a preset operation method of an i node corresponding to the virtual file system to the operating system; the preset operation method at least comprises one of the following steps: create file, delete file, symbolic link file, delete symbolic link, find file, create directory, and delete directory.
In these optional implementation manners, since the preset operation method of the i-node corresponding to the virtual file system is registered in the operating system, in the running process of the application program, operations of creating a file, deleting a file, linking a symbol file, deleting a symbol link, searching a file, creating a directory, and deleting a directory in the virtual file system can be implemented.
Further optionally, the disaster recovery method further includes: registering a file operation method corresponding to the virtual file system with the operating system, wherein the file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
In these optional implementation manners, since the file operation method corresponding to the virtual file system is registered in the operating system, in the running process of the application program, it may be implemented to perform related operations on the file in the virtual file system, such as operations of opening the file, reading the file, writing the file, locating the file, locking the file, closing the file, mapping the file, modifying the size of the file, and obtaining the attribute of the file.
It should be noted that, since the virtual file system is virtualized, even if the virtual file system supports the above-mentioned various operation methods for the file, actually, when writing the file, the data requested by the user is discarded, and the size and the file location pointer of the corresponding file are modified according to the size of the requested data, so as to modify the timestamp corresponding to the file. Thus, the file generated by the write file operation supported by the virtual file system is effectively an empty file. However, the size attribute of the empty file matches the size of the data written by the user, and the time attribute of the empty file generated by the write file operation matches the time written by the user.
With further reference to fig. 3, a flow chart of yet another embodiment of a disaster recovery method is shown. As shown in fig. 3, the process of the disaster recovery method includes the following steps:
In this embodiment, parameters corresponding to the virtual file system may be preset. The preset parameter corresponding to the virtual file system may include an identifier of a target directory to which the virtual file system is mounted. The number of target directories to which the virtual file system is mounted may be one, or two or more.
In this embodiment, when the server is started, the virtual file system may be mounted to the target directory based on the preset parameter corresponding to the virtual file system. In this way, it is possible to prepare in advance for restarting the application program corresponding to the target directory using the virtual file system when the target hard disk fails.
In this embodiment, in step 301, after the virtual file system is mounted to the target directory indicated by the preset parameters based on the preset parameters corresponding to the virtual file system, the target hard disk may be mounted to the target directory. The file system included in the target hard disk may overwrite the virtual file system that has been mounted to the target directory. In this way, when the target hard disk corresponding to the target directory can normally run, the operating system corresponding to the server can detect only the file system of the target hard disk. Therefore, whether the running environment of the application program corresponding to the target directory is normal or not is determined according to the file system of the target hard disk. Under the condition that the target hard disk is normal, the operating system of the server can support various operating methods of the i node according to the operation of the user based on the file system corresponding to the target hard disk. The operation method may include, for example, creating a file, deleting a file, symbolic link a file, deleting a symbolic link, finding a file, creating a directory, deleting a directory, and the like. These operations may be actual operations. In addition, the file system corresponding to the target hard disk supports various file operation methods according to the operation of the user. The file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
In this embodiment, step 303 may be the same as or similar to step 101 in the embodiment shown in fig. 1, and is not described herein again.
In this embodiment, after receiving the information of the failure of the target application mounted with the target directory in step 303, the failed target hard disk may be dynamically uninstalled, so that the previously covered virtual file system mounted to the target directory is exposed.
And step 304, restarting the application program corresponding to the target directory.
In this embodiment, when the application program corresponding to the target directory is restarted, the virtual file system is exposed, so that the operating system can detect the virtual file system when detecting the resource corresponding to the target directory.
In this embodiment, step 304 is the same as or similar to step 102 in the embodiment shown in fig. 1, and is not repeated here.
Step 305, the application is re-run based on the virtual file system mounted to the target directory.
In this embodiment, step 305 is the same as or similar to step 103 in the embodiment shown in fig. 1, and is not described herein again.
As can be seen from fig. 3, compared with the embodiment corresponding to fig. 1, the process of the web page generating method in this embodiment highlights the step of mounting the virtual file system to the target directory when the server is started, and overwriting the virtual file system with the file system corresponding to the target hard disk. Therefore, according to the scheme described in this embodiment, when the target hard disk fails, the application program can be restarted directly according to the virtual file system previously mounted to the target directory, so that the time from stopping to rerunning of the application program can be further shortened when the target hard disk fails.
With further reference to fig. 4, as an implementation of the methods shown in the above-mentioned figures, the present disclosure provides an embodiment of a disaster recovery device, which corresponds to the method embodiment shown in fig. 1, and which can be applied to various electronic devices.
As shown in fig. 4, the disaster recovery device of the present embodiment includes: a receiving unit 401, a restarting unit 402 and a rerunning unit 403. The receiving unit 401 is configured to receive information that a target hard disk mounted with a target directory fails; a restarting unit 402, configured to restart an application program corresponding to the target directory; a rerun unit 403, configured to rerun the application based on the virtual file system mounted to the target directory.
In this embodiment, specific processes of the receiving unit 401, the restarting unit 402, and the rerunning unit 403 of the disaster recovery apparatus and technical effects thereof can refer to the related descriptions of step 101, step 102, and step 103 in the corresponding embodiment of fig. 1, which are not described herein again.
Optionally, the disaster recovery device further includes a first mounting unit (not shown in the figure); the first mounting unit is used for: before the receiving unit 401 receives information that a target hard disk mounted with a target directory fails, when a server is started, based on preset parameters corresponding to the virtual file system, mounting the virtual file system to the target directory indicated by the preset parameters; the preset parameters comprise the identification of the target directory mounted by the virtual file system.
In some optional implementations of this embodiment, the disaster recovery device further includes a second mounting unit (not shown in the figure). The second mounting unit is used for: and before the restarting unit restarts the application program corresponding to the target directory, mounting the virtual file system to the target directory.
In some optional implementations of this embodiment, the first mounting unit is further configured to: before the receiving unit 401 receives the information that the target hard disk mounted with the target directory has a fault, the target hard disk is mounted to the target directory, and the file system included in the target hard disk covers the virtual file system mounted to the target directory.
In some optional implementations of this embodiment, the disaster recovery device further includes an unloading unit (not shown in the figure). The unloading unit is used for: before the restarting unit 402 restarts the application program corresponding to the target directory, the failed target hard disk is dynamically uninstalled to expose the virtual file system covered by the target hard disk and mounted to the target directory.
In some optional implementations of this embodiment, the disaster recovery device further includes a registration unit (not shown in the figure). The registration unit is used for: before the receiving unit 401 receives the information that the target hard disk mounted with the target directory fails, registering the information of the virtual file system with an operating system corresponding to a server; the information of the virtual file system at least comprises identification information of a target directory to which the virtual file system is mounted.
In some optional implementations of this embodiment, the registration unit is further configured to: registering an i-node preset operation method corresponding to the virtual file system to the operating system; the preset operation method at least comprises one of the following steps: create file, delete file, symbolic link file, delete symbolic link, find file, create directory, and delete directory.
In some optional implementations of this embodiment, the registration unit is further configured to: registering a file operation method corresponding to the virtual file system with the operating system, wherein the file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
Referring to fig. 5, fig. 5 illustrates an exemplary system architecture to which the disaster recovery method of one embodiment of the present disclosure may be applied.
As shown in fig. 5, the system architecture may include terminal devices 501, 502, 503, a network 504, and a server 505. The network 504 serves to provide a medium for communication links between the terminal devices 501, 502, 503 and the server 505. Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. The terminal devices and servers described above may communicate using any currently known or future developed network Protocol, such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.
The terminal devices 501, 502, 503 may interact with a server 505 over a network 504 to receive or send messages or the like. The terminal devices 501, 502, 503 may have various client applications installed thereon, such as a web browser application, a search-type application, and a news-information-type application.
The terminal devices 501, 502, 503 may be various electronic devices having a display screen, and may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. . When the terminal devices 501, 502, and 503 are software, they can be installed in the electronic devices listed above. Which may be implemented as a plurality of software or software modules (e.g., software or software modules for providing distributed services), and so forth.
The server 505 may be a server capable of providing various services, for example, receiving an information acquisition request sent by the terminal device 501, 502, 503, and acquiring presentation information corresponding to the information acquisition request in various ways according to the information acquisition request. And the relevant data of the presentation information is sent to the terminal equipment 501, 502, 503.
It should be noted that the disaster recovery method provided by the embodiment of the present disclosure is generally executed by the server 505, and accordingly, the disaster recovery device is generally disposed in the server 505.
It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 6, a block diagram of an electronic device (e.g., the server of FIG. 5) suitable for use in implementing embodiments of the present disclosure is shown. The electronic device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 6, the electronic device may include a processing means (e.g., a central processing unit, a graphic processor, etc.) 601, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage means 606 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
Generally, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 606 including, for example, magnetic tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 illustrates an electronic device having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated by the flow chart. In such embodiments, the computer program may be downloaded and installed from a network through the communication device 609, or installed from the storage device 606, or installed from the ROM 602. The computer program, when executed by the processing device 601, performs the above-described functions defined in the methods of the embodiments of the present disclosure.
It should be noted that the computer readable medium in the present disclosure can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.
The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.
The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receiving information of a fault of a target hard disk mounted with a target directory; restarting the application program corresponding to the target directory; and re-running the application program based on the virtual file system mounted to the target directory.
Computer program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including but not limited to an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present disclosure may be implemented by software or hardware. Here, the name of the unit does not constitute a limitation to the unit itself in some cases, and for example, the receiving unit may also be described as a "unit that receives information that a target hard disk mounted with a target directory fails".
The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), systems on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
According to one or more embodiments of the present disclosure, a disaster recovery method is provided, including receiving information that a target hard disk mounted with a target directory has a failure; restarting the application program corresponding to the target directory; and re-running the application program based on the virtual file system mounted to the target directory.
According to one or more embodiments of the present disclosure, before the receiving information that a target hard disk mounted with a target directory fails, an example disaster recovery method provided further includes: when a server is started, based on preset parameters corresponding to the virtual file system, mounting the virtual file system to a target directory indicated by the preset parameters; the preset parameters comprise the identification of the target directory mounted by the virtual file system.
According to one or more embodiments of the present disclosure, before restarting the application corresponding to the target directory, an example disaster recovery method further includes: and dynamically unloading the failed target hard disk to expose the virtual file system covered by the target hard disk and mounted to the target directory.
In one or more embodiments of the present disclosure, before restarting the application corresponding to the target directory, an example disaster recovery method further includes: and mounting the virtual file system to the target directory.
In one or more embodiments of the present disclosure, before the receiving information that a target hard disk mounted with a target directory fails, an example disaster recovery method further includes: registering the information of the virtual file system with an operating system corresponding to a server; the information of the virtual file system at least comprises identification information of a target directory to which the virtual file system is mounted.
In one or more embodiments of the present disclosure, an example disaster recovery method is provided that further includes: registering an i-node preset operation method corresponding to the virtual file system to the operating system; the preset operation method at least comprises one of the following steps: create file, delete file, symbolic link file, delete symbolic link, find file, create directory, and delete directory.
In one or more embodiments of the present disclosure, an example disaster recovery method is provided that further includes: registering a file operation method corresponding to the virtual file system with the operating system, wherein the file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the disclosure herein is not limited to the particular combination of features described above, but also encompasses other embodiments in which any combination of the features described above or their equivalents does not depart from the spirit of the disclosure. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.
Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims (18)
1. A disaster recovery method, comprising:
receiving information of a fault of a target hard disk mounted with a target directory;
restarting the application program corresponding to the target directory;
and re-running the application program based on the virtual file system mounted to the target directory.
2. The method of claim 1, wherein prior to said receiving information that a target hard disk mounted with a target directory fails, the method further comprises:
when a server is started, based on preset parameters corresponding to the virtual file system, mounting the virtual file system to a target directory indicated by the preset parameters; the preset parameters comprise the identification of the target directory mounted by the virtual file system.
3. The method of claim 1, wherein prior to the restarting the application corresponding to the target directory, the method further comprises:
and mounting the virtual file system to the target directory.
4. The method of claim 1 or 2, wherein prior to said receiving information that a target hard disk mounted with a target directory fails, the method further comprises:
and mounting the target hard disk to the target directory, wherein the file system included in the target hard disk covers the virtual file system mounted to the target directory.
5. The method of claim 4, wherein prior to the restarting the application corresponding to the target directory, the method further comprises:
and dynamically unloading the failed target hard disk to expose the virtual file system covered by the target hard disk and mounted to the target directory.
6. The method according to any of claims 1-3, wherein before said re-running said application based on said virtual file system mounted to said target directory, said method further comprises:
registering the information of the virtual file system with an operating system corresponding to a server; the information of the virtual file system at least comprises identification information of a target directory to which the virtual file system is mounted.
7. The method of claim 6, further comprising:
registering an i-node preset operation method corresponding to the virtual file system to the operating system; the preset operation method at least comprises one of the following steps: create file, delete file, symbolic link file, delete symbolic link, find file, create directory, and delete directory.
8. The method of claim 6, further comprising:
registering a file operation method corresponding to the virtual file system with the operating system, wherein the file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
9. A disaster recovery device, comprising:
the receiving unit is used for receiving information of faults of a target hard disk mounted with a target directory;
the restarting unit is used for restarting the application program corresponding to the target directory;
and the rerun unit is used for rerunning the application program based on the virtual file system mounted to the target directory.
10. The apparatus of claim 9, further comprising a first mounting unit configured to:
before the receiving unit receives information that a target hard disk mounted with a target directory fails, when a server is started, the virtual file system is mounted to the target directory indicated by preset parameters based on the preset parameters corresponding to the virtual file system; the preset parameters comprise the identification of the target directory mounted by the virtual file system.
11. The apparatus of claim 9, further comprising a second mounting unit; the second mounting unit is used for:
and before the restarting unit restarts the application program corresponding to the target directory, mounting the virtual file system to the target directory.
12. The apparatus according to claim 9 or 10, wherein the first mounting unit is further configured to:
before the receiving unit receives the information that the target hard disk mounted with the target directory has a fault, the target hard disk is mounted to the target directory, and the file system included in the target hard disk covers the virtual file system mounted to the target directory.
13. The apparatus of claim 12, further comprising an unloading unit to:
before the restarting unit restarts the application program corresponding to the target directory, dynamically uninstalling the failed target hard disk to expose the virtual file system covered by the target hard disk and mounted to the target directory.
14. The apparatus according to one of claims 9-11, wherein the apparatus further comprises a registration unit configured to:
registering information of the virtual file system to an operating system corresponding to a server before the re-running unit re-runs the application program based on the virtual file system mounted to the target directory; the information of the virtual file system at least comprises identification information of a target directory to which the virtual file system is mounted.
15. The apparatus of claim 14, wherein the registration unit is further configured to:
registering an i-node preset operation method corresponding to the virtual file system to the operating system; the preset operation method at least comprises one of the following steps: create file, delete file, symbolic link file, delete symbolic link, find file, create directory, and delete directory.
16. The apparatus of claim 14, wherein the registration unit is further configured to:
registering a file operation method corresponding to the virtual file system with the operating system, wherein the file operation method at least comprises one of the following steps: opening a file, reading a file, writing a file, positioning a file, locking a file, closing a file, mapping a file, modifying the size of the file, and obtaining the attributes of the file.
17. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-8.
18. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910489439.8A CN112052128A (en) | 2019-06-06 | 2019-06-06 | Disaster recovery method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910489439.8A CN112052128A (en) | 2019-06-06 | 2019-06-06 | Disaster recovery method and device and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112052128A true CN112052128A (en) | 2020-12-08 |
Family
ID=73609495
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910489439.8A Pending CN112052128A (en) | 2019-06-06 | 2019-06-06 | Disaster recovery method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112052128A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103425539A (en) * | 2012-05-14 | 2013-12-04 | 联想(北京)有限公司 | Information processing method and information processing device |
| WO2017067213A1 (en) * | 2015-10-20 | 2017-04-27 | 华为技术有限公司 | Device hot-replacement method and apparatus based on virtual machine |
| CN108021372A (en) * | 2016-11-01 | 2018-05-11 | 深圳市中兴微电子技术有限公司 | The management method and device of a kind of application program |
| CN108121620A (en) * | 2017-12-22 | 2018-06-05 | 联想(北京)有限公司 | The restorative procedure and system and server of distributed file system |
| CN108572795A (en) * | 2017-12-21 | 2018-09-25 | 北京金山云网络技术有限公司 | Based on expansion method, device, equipment and the storage medium for building Storage Virtualization |
-
2019
- 2019-06-06 CN CN201910489439.8A patent/CN112052128A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103425539A (en) * | 2012-05-14 | 2013-12-04 | 联想(北京)有限公司 | Information processing method and information processing device |
| WO2017067213A1 (en) * | 2015-10-20 | 2017-04-27 | 华为技术有限公司 | Device hot-replacement method and apparatus based on virtual machine |
| CN108021372A (en) * | 2016-11-01 | 2018-05-11 | 深圳市中兴微电子技术有限公司 | The management method and device of a kind of application program |
| CN108572795A (en) * | 2017-12-21 | 2018-09-25 | 北京金山云网络技术有限公司 | Based on expansion method, device, equipment and the storage medium for building Storage Virtualization |
| CN108121620A (en) * | 2017-12-22 | 2018-06-05 | 联想(北京)有限公司 | The restorative procedure and system and server of distributed file system |
Non-Patent Citations (1)
| Title |
|---|
| 康潇文: "基于虚拟存储的数据容灾关键技术研究", 计算机应用研究, vol. 26, no. 7, pages 2603 - 2606 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10698866B2 (en) | Synchronizing updates across cluster filesystems | |
| US10528337B1 (en) | Container image layer reordering | |
| CN109597677B (en) | Method and apparatus for processing information | |
| US10061665B2 (en) | Preserving management services with self-contained metadata through the disaster recovery life cycle | |
| US8938518B2 (en) | Transferring applications and session state to a secondary device | |
| CN111078262B (en) | Application thermal restoration method and device | |
| CN107644075B (en) | Method and device for collecting page information | |
| CN112965761B (en) | Data processing method, system, electronic equipment and storage medium | |
| US9329953B2 (en) | Reducing application downtime during failover | |
| US8565545B1 (en) | Systems and methods for restoring images | |
| CN111338834B (en) | Data storage method and device | |
| CN111818145A (en) | File transmission method, device, system, equipment and storage medium | |
| CN113886264A (en) | Embedded method, device, equipment and storage medium of distributed database | |
| CN111198853B (en) | Data processing method, device, electronic equipment and computer readable storage medium | |
| CN111367720A (en) | Data protection method and device, electronic equipment and computer readable storage medium | |
| CN112052128A (en) | Disaster recovery method and device and electronic equipment | |
| CN110727945B (en) | Virus scanning method, device and computer readable medium | |
| CN117369952B (en) | Cluster processing method, device, equipment and storage medium | |
| US11782802B2 (en) | Method, electronic device, and computer program product for data protection | |
| CN112749042B (en) | Application running method and device | |
| CN117349035B (en) | Workload scheduling method, device, equipment and storage medium | |
| US20220342686A1 (en) | Virtual machine file management using file-level snapshots | |
| CN111324888B (en) | Verification method and device for application program starting, electronic equipment and storage medium | |
| US20220229659A1 (en) | Pull based inner-loop code deployment | |
| CN116954957A (en) | Information acquisition method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |