Method and system for single web application recovery on a collaborative platform

1. A method for web application recovery, comprising:

verifying that a web application on a first collaborative platform farm (CPF) is to be recovered;

based on the verifying:

redirecting user client traffic from the first CPF to a second CPF;

pausing data backup operations on the first CPF;

dismounting at least one content database associated with the web application;

obtaining an application topology metadata (ATM) object; and

recreating, using the ATM object, the web application to obtain a recovered web application.

2. The method of claim 1 , wherein the data backup operations comprise a continuous assembly of ATM objects and a sharing of the ATM objects with the second CPF, wherein the second CPF is operatively connected to the first CPF.

3. The method of claim 1 , wherein the ATM object comprises application recreation information (ARI) comprising a web application name associated with the web application, user authentication credentials, user secure sockets layer (SSL) certificates, a default zone uniform resource locator (URL), and application pool information.

4. The method of claim 1 , wherein the ATM object is obtained from one selected from a group consisting of a first application metadata repository on the first CPF and a second application metadata repository on the second CPF, wherein the second CPF is operatively connected to the first CPF.

5. The method of claim 1 , further comprising:

mounting the at least one content database to the recovered web application;

resuming the data backup operations on the first CPF; and

redirecting the user client traffic from the second CPF to the first CPF.

6. The method of claim 5 , wherein redirecting the user client traffic from the first CPF to the second CPF comprises issuing a first redirect request to a domain name system (DNS) operatively connected to the first CPF and the second CPF, wherein redirecting the user client traffic from the second CPF to the first CPF comprises issuing a second redirect request to the DNS.

7. The method of claim 5 ,

wherein redirecting the user client traffic from the first CPF to the second CPF comprises spoofing a status of the first CPF to exhibit failover,

wherein a failover monitoring service (FMS), based on detecting the failover, notifies a domain name system (DNS) of the failover,

wherein redirecting the user client traffic from the second CPF to the first CPF comprises un-spoofing the status of the first CPF to exhibit normal operations,

wherein the FMS, based on detecting the normal operations, notifies the DNS of the normal operations, and

wherein the DNS is operatively connected to the first CPF and the second CPF, wherein the FMS is operatively connected to at least the first CPF.

8. The method of claim 5 ,

wherein redirecting the user client traffic from the first CPF to the second CPF comprises issuing a first status notification to a failover monitoring service (FMS),

wherein the FMS, based on the first status notification, notifies a domain name system (DNS) that the first CPF has experienced failover,

wherein redirecting the user client traffic from the second CPF to the first CPF comprises issuing a second status notification to the FMS,

wherein the FMS, based on the second status notification, notifies the DNS that the first CPF is executing normally, and

wherein the DNS is operatively connected to the first CPF and the second CPF, wherein the FMS is operatively connected to at least the first CPF.

9. The method of claim 1 , wherein verifying that the web application on the first CPF is to be recovered, comprises:

receiving, from an administrator client, a restore request comprising a web application identifier (ID) associated with the web application;

determining, based on at least on receiving the restore request, that recovery a full CPF restore for the first CPF is not sought; and

verifying, based on the determining, that the web application on the first CPF is to be recovered.

10. The method of claim 1 , wherein verifying that the web application on the first CPF is to be recovered, comprises:

issuing a heartbeat packet to the web application;

obtaining a heartbeat issuance time for the heartbeat packet;

listening for a heartbeat response from the web application;

obtaining, while listening for the heartbeat response, a current time;

making a first determination, based on the listening, that the heartbeat response has yet to be received;

making a second determination that a difference between the heartbeat issuance time and the current time exceeds a timeout period;

making a third determination, based on the first and second determinations, that the web application has experienced failover; and

verifying, based on the third determination, that the web application on the first CPF is to be recovered.

11. The method of claim 1 , further comprising:

prior to verifying that the web application on the first CPF is to be recovered:

aggregating application recreation information (ARI) for the web application using a web application name associated with the web application, user authentication credentials, user secure sockets layer (SSL) certificates, a default zone uniform resource locator (URL), and application pool information; and

generating the ATM object using the ARI.

12. A system, comprising:

a first collaborative platform farm (CPF) operatively connected to a second CPF; and

an application recovery agent (ARA) executing on the first CPF, and programmed to:

verify that a web application on the first CPF is to be recovered;

based on the verifying:

redirect user client traffic from the first CPF to the second CPF;

pause data backup operations on the first CPF;

dismount at least one content database associated with the web application;

obtain an application topology metadata (ATM) object; and

recreate, using the ATM object, the web application to obtain a recovered web application.

13. The system of claim 12 , wherein the ARA comprises an agent kernel, an application metadata assembler (AMA), an application heartbeat tracker (AHT), an intra-farm communicator (IFC), and an application metadata repository.

14. The system of claim 12 , wherein the first CPF comprises the ARA, a configuration database, the at least one content database, at least one web application comprising the web application, an application programming interface (API), and a peer CPF communicator.

15. The system of claim 14 , wherein each web application of the at least one web application comprises at least one site collection, wherein the at least one site collection comprises a plurality of sites comprising a top level site and at least one sub-site, wherein each site of the plurality of sites comprises at least one list, wherein the at least one list comprises at least one field and a plurality of list items.

16. The system of claim 12 , further comprising an administrator client operatively connected to the ARA.

17. The system of claim 12 , further comprising a domain name system (DNS) operatively connected to the first CPF and the second CPF.

18. The system of claim 17 , further comprising a failover monitoring service (FMS) operatively connected to the first CPF and the DNS.

19. The system of claim 17 , further comprising a user client operatively connected to the DNS, wherein the user client traffic pertains to network traffic originating from the user client.

20. A non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor, enables the computer processor to:

verify that a web application on a first collaborative platform farm (CPF) is to be recovered;

based on the verifying:

redirect user client traffic from the first CPF to a second CPF;

pause data backup operations on the first CPF;

dismount at least one content database associated with the web application;

obtain an application topology metadata (ATM) object; and

recreate, using the ATM object, the web application to obtain a recovered web application.