Disaster recovery tool
AssigneeBank of America Corporation
InventorsAnant Bondalapati Sharma, Badelal Rameshwar Prasad Yadav, Rakesh Madanlal Shah
Life of this patent
Estimating the term…
Loading patent…
AssigneeBank of America Corporation
InventorsAnant Bondalapati Sharma, Badelal Rameshwar Prasad Yadav, Rakesh Madanlal Shah
Estimating the term…
A disaster recovery tool includes a server monitoring engine, a configuration engine, a security engine, and a runtime engine. The server monitoring engine detects a production server and determines that a disaster recovery server should be created for the production server. The configuration engine compares database configuration files for the production server and the disaster recovery server and copies the database configuration file for the production server to the disaster recovery server. The security engine compares user logins and file sharing credentials of the production server and the disaster recovery server and copies the user login and file sharing credential of the production server to the disaster recovery server. The runtime engine compares database jobs and schedules of the production server and the disaster recovery server and copies the database job and schedule of the production server to the disaster recovery server.
A disaster recovery tool comprising:
A method comprising:
A system comprising:
Dependencies are inferred from the claim text.
Drawings are temporarily unavailable. Open the PDF at USPTO
From the US filing history. Foreign family members aren’t listed.
Management of the backup or restore process: backup scheduling policy
Responding to the occurrence of a fault, e.g. fault tolerance: error detection or correction of the data by redundancy in operations
Management of the data involved in backup or backup restore: by selection of backup contents
Management of the backup or restore process: backup restoration techniques
About 10 years 5 months of term left · ends 22 Mar 2037 (estimated)
This disclosure relates generally to disaster recovery.
Servers and databases store and use information used by applications. In some instances, the servers and databases encounter events (characterized as disastrous events) that result in the information on the servers and databases being destroyed in some manner. For example, the servers and databases may encounter a crash, an intrusion, and/or an external force (such as a natural disaster and/or terrorist attack) that causes the information to be destroyed and/or to become inaccessible.
According to an embodiment, a disaster recovery tool includes a server monitoring engine, a configuration engine, a security engine, and a runtime engine. The server monitoring engine detects a production server and determines that a disaster recovery server should be created for the production server. The configuration engine compares a database configuration file for the production server with a database configuration file for the disaster recovery server and copies the database configuration file for the production server to the disaster recovery server if the database configuration file for the production server does not match the database configuration file for the disaster recovery server. The security engine compares a user login of the production server with a user login of the disaster recovery server and copies the user login of the production server to the disaster recovery server if the user login of the production server does not match the user login of the disaster recovery server. The security engine further compares a file sharing credential of the production server with a file sharing credential of the disaster recovery server and copies the file sharing credential of the production database to the disaster recovery server if the file sharing credential of the production server does not match the file sharing credential of the disaster recovery server. The runtime engine compares a database job of the production server with a database job of the disaster recovery server and copies the database job of the production server to the disaster recovery server if the database job of the production server does not match the database job of the disaster recovery server. The runtime engine further compares a schedule of the production server with a schedule of the disaster recovery server and copies the schedule of the production server to the disaster recovery server if the schedule of the production server does not match the schedule of the disaster recovery server.
For a more complete understanding of the present disclosure, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
FIG. 1 illustrates a system for disaster recovery;
FIG. 2 illustrates the disaster recovery tool of the system of FIG. 1; and
Embodiments of the present disclosure and its advantages are best understood by referring to FIGS. 1 through 3 of the drawings, like numerals being used for like and corresponding parts of the various drawings.
Servers and databases store and use information used by applications. In some instances the servers and databases encounter events characterized as disastrous events that result in the information on the servers and databases being destroyed in some manner. For example, the servers and databases may encounter a crash in which the disks or drives that store the information become inoperable. As another example, the servers and databases may encounter an intrusion in which a malicious actor alters and/or deletes information stored on the servers and databases. As yet another example, the servers and databases may encounter an external force such as a natural disaster or a terrorist attack in which the server and/or database is damaged or destroyed. In each of these events, the information on the server and/or database is destroyed and/or becomes inaccessible.
To protect against data loss and/or damage, users may implement a form of data redundancy. For example, users may implement backup servers and backup databases that keep redundant copies of the data and/or information stored in the servers and databases. When the servers and databases are damaged and/or compromised, the users may restore data from the backup servers and databases. However, a disadvantage of existing implementations is that backup servers and databases maintain copies of only application data. As a result, certain types of information such as configuration data, security data and runtime data are not preserved. When it comes time to restore the server and/or database, the restored server and database may not be capable of performing all the functions of the destroyed server or database.