FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention:
RECOVERY OF MAIL ITEMS
2 vlicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY SERVICES Indian Nirmal Building, 9th Floor, Nariman
LIMITED Point, Mumbai Maharashtra-400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter relates, in general, to recovery of data and, in particular, to recovery of the data pertaining to electronic mails. BACKGROUND
[0002] Electronic mail, or email, has become one of the most common medium of
communication for personal and business interactions. The interactions via emails are data driven, which can be lost or corrupted owing to various reasons, such as, system failures, accidental deletion of data, or virus attacks. Due to increasing dependence on the emails to perform vital personal and business functions various organizations back up data present in the emails, i.e., mail-data, on mail server's, for easy and reliable access to the mail-data in case of non-availability of mail-data in the mail server.
[0003] Therefore, the mail-data on a mail server, generally, has a corresponding
backup copy of the mail-data. The backup copy is periodically created to enable recovery of the mail-data in the event of data loss from the mail server. Conventionally, in some mail servers, while recovering the mail-data from the backup copy, the mail servers are put in offline state, which can affect user activity and can cause inconvenience to the users of the mail server. Further, in the event of loss of the mail-data of a single user, mail-data of all the users associated with the mail server may have to be restored, which can be a time and resource consuming process. SUMMARY
[0004] This summary is provided to introduce concepts related to recovery of mail-
data, which are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] Method(s) and system(s) for recovering mail-data pertaining to one or more
mail items onto a mail server are described. In one embodiment, one or more attributes associated with one or more mail-items are received. Based on the attributes, mail metadata corresponding to the one or more mail items is identified. The mail metadata is indicative of the mail items to be recovered. Subsequent to identification of the mail metadata a recovery file for recovering the one or more mail-items is created. Further, the recovery file includes

at least a mail metafile corresponding to the mail-items to be recovered. The recovery file
facilitates recovery of the mail-items onto the mail server.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in
which the reference number first appears. The same numbers are used throughout the
drawings to reference like features and components.
[0007] Fig. 1 illustrates an exemplary network environment implementing a mail item
recovery system, in accordance with an implementation of the present subject matter.
[0008] Fig. 2 illustrates exemplary components of the mail item recovery system, in
accordance with an implementation of the present subject matter.
[0009] Fig 3 illustrates an exemplary method for recovery of one or more mail items,
in accordance with an implementation of the present subject matter.
DETAILED DESCRIPTION
[00010] The subject matter described herein relates to recovery of mail-data pertaining to one or more mail item. The systems and methods, related to recovery of the mail-data, described herein, can be implemented on devices, such as a server, a desktop, a mobile device, a notebook etc through a mail application, such as, a mail agent. In one implementation, the mail-data includes actual mail-data to be recovered and metadata corresponding to the mail-data to be recovered. The mail-data can be data pertinent to a user mailbox, one or more specific mail items, etc. Generally, the user mailbox includes one or more mail items, such as folders, mail messages, attachments, contacts, flags, to-do lists, and appointments. Thus, it will be understood that the mail-data includes such mail messages, attachments, contacts, flags, to-do lists, appointments, etc., associated with one or more mail items.
[00011] Conventionally, mail-data is recovered from a backup copy of the mail-data by placing a mail server in an offline state and restoring the mail-data onto an auxiliary server. User mailboxes, mailbox folders and individual mail items are then retrieved from the restored mail-data stored on the auxiliary server and provided to user devices. Further, in

order to retrieve the mail-data pertaining to a single mail box or a single folder in a mailbox or a single mail item in a mailbox, the entire backup mail-data is retrieved. Such processes for recovery of the mail-data are tedious and utilize large amount of computational resources.
[00012] According to an embodiment of the present subject matter, methods and systems for recovery of mail-data pertaining to one or more mail items are described. In an implementation, to recover the mail-items of a mail box of a user, one or more attributes of the mail items to be recovered are provided. For example, in case complete mailbox of a user is to be recovered a user ID, for example, an email address, i.e., email ID, of the user is provided. In another example, if a specific mail-data, for instance one or more folders or one or more specific mail items, from a mailbox is to be recovered, the attributes of the mail items may include, for instance, user ID of the user, name of the folder, or mails from a particular mail address.
[00013] In one implementation, based on the attributes, mail metadata of mail items to be recovered is identified. The mail metadata includes information, such as, mailbox ID, mail item ID, folder ID, type, and mod-content. The identification of the mail metadata includes, for example, identification of a database from a backup storage on which the mail items related to the user ID is stored. Subsequently, the mail metadata of mail items to be recovered may be identified using metadata associated with the database. In one implementation, the mail metadata is identified based at least on the mailbox ID. In case a single mail item is to be recovered then the mail metadata of only that mail item is identified and subsequently obtained. In another example, if the complete mailbox is to be recovered then the mail metadata of all the mail items associated with that mailbox is identified. [00014] Once the relevant mail metadata is identified for a mail item, one or more intermediate recovery files are created. In one implementation, to create the intermediate recovery files, for each of the mail item to be recovered, it is determined whether the mail item has a physical file associated with it or not. In one example, when the mail item does not have a physical file associated with it then the intermediate recovery file only includes a mail metafile. In one implementation, the mail metafile is a JavaScript Object Notation (JSON) object. The mail metafile includes information, such as the folder ID, message titles,

the type, modified date, and location parameters. The location parameters help in locating the physical file in the back-up storage. In another example, when the mail item has a physical file associated with it, then the intermediate recovery files created for the mail item includes the mail metafile and a data file. The data file can be created based on the physical file associated with the mail item.
[00015] In one implementation, subsequent to creation of the intermediate recovery files a recovery file is created. In one implementation, the recovery file is a tape archive file.. The recovery file can be used to import the mail items on a mail server associated with the mail items to be recovered. In one example, the recovery file can be created by converting the intermediate recovery file, i.e., mail metafile and if the data file is present then data file, into a byte array. Further, along with the conversion of the intermediate recovery file into the byte array, header information corresponding to each byte array is determined. Thee byte arrays are compressed to form the recovery file and header information is appended as an entry object with the recovery file. In one implementation, the entry object includes information that allows the intermediate recovery files to be restored to their original form.
[00016] The recovery file includes information pertaining to the mail items to be recovered and can be easily imported onto a live mail server without hampering user activity. Further, the present systems and methods facilitate recovery of mail-data pertaining to not only a single mailbox but also a single mail item without having to restore the entire database onto the server, thereby saving computational time and resources. [00017] While aspects of described systems and methods for recovery of mail items can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
EXEMPLARY SYSTEMS
[00018] Fig. 1 illustrates an exemplary network environment 100 implementing a mail
item recovery system 102, according to an embodiment of the present subject matter. The
network environment 100 includes a mail item recovery system 102, one or more user
devices 104-1, 104-2, 104-3 104-n coupled to the mail-item recovery system 102 via a

network 106. For the purpose of explanation, the user devices 104-1, 104-2, 104-3, 104-
n, are collectively referred to as the user devices 104 and individually referred to as the user device 104. The network environment 100 may also include an administrative device, which can be provided as one of the user devices 104 or as the mail-item recovery system 102. The administrative device manages the mail-item recovery system 102.
[00019] The network 106 may be a wireless network, wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. [00020] The mail item recovery system 102, hereinafter referred to as recovery system 102, and the user devices 104 can be implemented as any of a variety of conventional computing devices, including, for example, servers, a desktop PC, a notebook or portable computer, a workstation, a mainframe computer, a mobile computing device, an entertainment device, and an internet appliance.
[00021] The users, via, the user devices 104, communicate with various users, using a mail application, which sends an email, hereinafter interchangeably referred to as mail, to a mail server. The mail server further sends this mail to one or more users devices coupled to the same mail server or some other mail server based on a list of recipients. In one implementation, the recovery system 102 is deployed on the mail server coupled to the user devices 104. However, it will be understood that the recovery system 102 can be external to the mail server and accordingly is externally associated with the mail server.
[00022] In order to avoid any data loss following a system failure, deletion, or corruption of data, a backup copy of the mail-data pertaining to the user mailboxes associated with the recovery system 102 is stored in a backup storage, such as the backup storage 108. Although the backup storage 108 is illustrated external to the recovery system 102, it will be understood that the backup storage 108 can be internal to the recovery system 102 as well. In one implementation, the backup storage 108 is a consistent backup so that

the mail items can be restored on the mail server in a readable format. The backup storage 108 can be created using various back-up mechanisms, such as snapshots, and can be stored onto various mediums, for example, tapes and disks.
[00023] The recovery system 102 includes, amongst other things, a metadata identification module 110 and a recovery module 112. In the event of data loss, a user may interact with the recovery system 102 to recover required mail items. For example, a user may directly interact with the recovery system 102 via user devices 104. In another example, one of the user devices 104 can be an administrative device and a user may interact through the administrative device with the recovery system 102 to fetch the relevant data. In order to recover the mail items, one or more attributes of the mail items are provided as an input to the metadata identification module 110. The attributes includes, for example, a user ID, a folder name, and certain parameters like sender, date, subject, etc, associated with a mail item. Based on the attributes, the metadata identification module 110 identifies mail metadata corresponding to the mail items to be recovered.
[00024] In one implementation, the metadata identification module 110 identifies a database in the backup storage 108, on which the mail items corresponding to the user mailbox under consideration is stored. The metadata identification module 110 may identify the database based on an attribute, such as, the user ID. Subsequent to identification of the database, the metadata identification module 110 identifies the mail metadata. In one implementation, the metadata identification module 110 determines a mailbox ID, which uniquely identifies a user account, i.e., mailbox within the mail server, associated with that user ID. For example, based on a mail address of a user, the metadata identification module 110 identifies the mailbox ID. Based on the mailbox ID and, if required, other attributes of the mail items the metadata identification module 110 identifies the mail metadata and thus the mail items from the backup storage 108 which are to be recovered.
[00025] For example, if the complete mailbox is to be recovered then the metadata associated with all the mail items corresponding to the mailbox is identified. In another example, if one or more folders of a user mailbox are to be recovered then only those mail items, which are associated with these folders are identified. In said example, the mail metadata can be identified based on the attributes, such as, the user ID and name of folder

associated with the mail items. In yet another example, in case a single mail item is to be recovered then the mail metadata associated with only this mail item is identified. In said example, the mail metadata can be identified based on the user ID, and parameters like folder name, sender, subject, date, etc.
[00026] Once the mail metadata is identified, the recovery module 112 creates one or more intermediate recovery files for each of the mail items to be recovered. The intermediate recovery file(s) includes at least a mail metafile. Further, if a physical file is associated with a mail item, a data file may also be included in the intermediate recovery file. In one implementation, the mail metafile contains metadata corresponding to a mail-item to be recovered and the data file contains actual data corresponding to a mail-item that is stored in the back-up storage 108. Subsequent to creation of the intermediate recovery file(s), the recovery module 112 converts the intermediate recovery file(s) into a "recovery file", which can be in the form of, for example, an archive file. In one implementation, to create the recovery file, the recovery module 112 converts each file in the intermediate recovery file to form a corresponding byte array. For example, if the intermediate recovery file includes only a mail metafile then a single byte array corresponding to the mail metafile is created. In another example, if the intermediate recovery file includes a mail metafile and data file, then a byte array corresponding to the mail metafile and a byte array corresponding to the data file is created. Further, the byte arrays are converted into the recovery file, which includes these byte arrays in a compresses format. In other words, recovery file includes the intermediate recovery files in a compressed format. In addition to the byte array, the recovery module 112 appends header information, which Can be in the form of an "entry object", to form the archive file. In one implementation, the entry object includes information, for example, an absolute path of the mail item, the mail item ID, a type of the mail item, and size of the byte array, regarding the mail item being recovered.
[00027] Subsequently, the recovery module 112 based on the recovery file, which includes mail-data in compressed format, imports the mail-data onto the mail server while keeping the mail server online. In one implementation, the recovery module 112 implements a recovery command and uses the recovery file as an input parameter to recover the mail items.

[00028] Fig. 2 illustrates exemplary components of the recovery system 102, according to an embodiment of the present subject matter. In one implementation, the recovery system 102 includes interface(s) 202, one or more processor(s) 204, and a memory 206 coupled to the processor 204.
[00029] The interfaces 202 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interfaces 202 may enable the recovery system 102 to communicate with other computing systems, such as web servers and external databases. The interfaces 202 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example local area network (LAN), cable, etc., and wireless networks such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the interfaces 202 may include one or more ports for connecting a number of computing systems with one another or to another server computer.
[00030] The processor 204 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor 204 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 204 is configured to fetch and execute computer-readable instructions and data stored in the memory 206.
[00031] The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 also includes module(s) 208 and data 210. [00032] The modules 208, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The modules 208 further include, for example, the metadata identification module 110, the recovery module 112, and other module(s) 212. The other modules 212 may include programs that supplement applications on the recovery system

102, for example, programs in the operating system. The data 210 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules 208. The data 210 includes, for example, metadata 214, recovery data 216, and other data 220. The other data 220 includes data generated as a result of the execution of one or more modules in the other modules 208.
[00033J As previously mentioned, a user may directly interact or may interact via an administrator with the recovery system 102 to recover the mail-data pertaining to one or mail items. In an implementation, where a user directly interacts with the recovery system, the user may provide one or more attributes of the mail iterns as input to the recovery system 102. In another implementation, where a user interacts via an administrator device, the administrator may provide one or more attributes to the recovery system 102. Based on the attributes, the metadata identification module 110 identifies the database in which the mail-data is stored. For the purpose of identification of the database, the metadata identification module 110 uses information regarding various mail-items stored in the metadata 214. The metadata 214 may be internal to the recovery system 102, however it will be understood that the metadata 214 can be stored on an external database, for example, a database maintained by the backup storage 108. The metadata 214 includes, for example, a mailbox table, one or more mail-item table(s), and other metadata. Although the description of metadata 214 is with reference to various tables, however, it will be understood that metadata 214 can be represented in any other form as well.
[00034] The mailbox table includes user account or mailbox information of users, which are hosted on the mail server associated with the recovery system 102. The mailbox table includes fields, for example, the mailbox ID, the user ID, and a database ID, for each user account in the mail server. Each user ID has a unique mailbox ID associated with it that uniquely identifies a user account, i.e., a mailbox within the mail server. Further, each database on the backup storage has a unique database ID associated with it. [00035] In one implementation, each database has corresponding metadata represented as a mail-item table, which provides information pertaining to the mail-items of all the mailboxes saved in that database. It will be understood that each database can have separate mail-item table or all the databases may have a consolidated mail item table where mail-

items from one database can be distinguished from other databases based on the database ID associated with them. The mail item table for a database, includes fields, for example, the mailbox ID, the mail item ID, type, the folder ID, a volume ID, a subject, and a mod-content corresponding to each mail item in the database. In one example, the mod-content field is used to keep track of message blob file revisions. If a blob file is updated, for example, if a calendar appointment is modified, the filename and the mod-content are updated. The other metadata may include a mail-item list and a folder list. In one implementation, each mail-item has a value for the type field associated with it and the mail-item list includes a list of values associated with each type of mail-items. For example, mail-item with a "folder" type has a value 1, "search folder" type has a value 2, "message" type has a value 5, "appointment" type has a value 11, "chat" type has a value 16, and so on. Similarly, the folder list includes a list of values associated with each folder ID, i.e., type of folder. For example, value of the folder ID for root folder is 1, value of the folder ID for inbox folder is 2, value of the folder ID for junk folder is 4, value of the folder ID for contacts folder is 7, and so on.
[00036] As previously mentioned, the metadata identification module 110 identifies the database in which the relevant metadata is stored using the metadata 214. In an implementation, the metadata identification module 110 determines, using the mailbox table, a mailbox ID corresponding to a user ID provided as input by the user. Further, based on the mailbox ID, the metadata identification module 110 identifies a corresponding database ID. In order to identify the database ID, the metadata identification module 110, for example, computes modulo 100 of a value of the mailbox ID and on appending the resultant value with a database label, the database ID and hence the database is identified. For instance, modulo 100 of a mailbox ID of 105 is 5, which gives the database ID and the database ID when appended with the database label "mboxgroup" gives mboxgroup5, which denotes the database on which the mail items are stored. In another example, the metadata identification module 110 directly identifies the database ID corresponding to the user ID. In said implementation, the database ID is directly identified from the mailbox table. [00037] Subsequent to identification of the database, the metadata identification module 1.10 identifies the mail metadata corresponding to mail items to be recovered. As previously

mentioned, in case complete mailbox of a user is to be recovered, then metadata of ail the mail items associated with that mailbox is identified. In said case, a user may only provide a user ID as an input. Further, if in case specific mail items of a mailbox are to be recovered then the user may provide other attributes in addition to the user ID. Based on one or more attributes, the metadata identification module 110 identifies, using the mail-item table associated with the previously identified database, the mail metadata corresponding the mail-items.
[00038] In an implementation, the metadata identification module 110 identifies all the mail items corresponding to the mailbox ID. Thus, in case complete mailbox is to be recovered, the metadata corresponding to all the mail items in the mailbox is saved in the recovery data 216. On the other hand, if specific mail items are to be recovered, the metadata for the required mail-items is filtered out based on the attributes of the mail items to be recovered. For example, if a specific folder is to be recovered then the metadata identification module 110 determines the folder ID for the folder to be recovered using the folder list. Further, based on the folder ID, mail-item IDs, the mail items referring to the folder ID are identified and saved in the recovery data 216. Thus, the mail metadata is indicative of the mail-items to be recovered, i.e., the mail-data to be recovered. Further, information pertaining to the location of the mail-data may be gathered from fields, such as mailbox ID, mail-item ID, and mod-content in the mail-item table. In one example, the location of the mail-data can be obtained as: concat ("/store/" + " (mailbox_id >>12) "+ "/" + "Mailbox_id" + "/msg/" + "(mail-item id»12)" + "/" + "-"+ "mod_content" + ".msg" ). The directory structure referred is indicative of a physical location within the backup storage 108. [00039] Once the mail metadata is identified, the recovery module 112 creates one or more intermediate recovery files for each of the mail-items. For the purpose of creation of the intermediate recovery files, the recovery module 112 determines whether a physical file is associated with the mail item or not. The recovery module 112 determines association of a physical file with a mail item based on, for example, a folder ID of the folder in which the mail item to be recovered is stored. For example, the mail-items belonging to folders, such as, inbox, trash, junk, sent, drafts, tags, notebook, and chats, have a physical file that is

stored within the directory structure of the back-up storage.. Further, the mail-item belonging to folders, such as, contacts, conversations, and emailed contacts, do not have a physical associated with them since the information represented by such mail-items is small, which can be stored in database itself. In one implementation, information represented by the mail-items, which do not have a physical file associated with them is stored in the metadata 214, for example, in the mail-items table. Based on the association of the physical file with the mail item, a corresponding intermediate recovery files are createdfor the mail item. Further, if in case no physical file is associated with a mail-item, the actual data corresponding to the mail-item can be extracted from the mail-item table itself and stored in the mail metafile.
[00040] For example, if the recovery module 112 determines that a physical file is associated with the mail item, then the intermediate recovery files created for the mail item includes the mail metafile and the data file. The data file includes the actual data of the physical file, which is to be recovered. The data file can be fetched from the backup storage 108. The recovery module 112, in an implementation, obtains the location of the physical file based on the mail item ID, mail-box ID, and the modcontent of the mail item from the mail-item table. In another example, if the recovery module 112 determines that the mail item does not have a physical file associated with it then the intermediate recovery file only includes the mail metafile. The mail metafile can be created based on values of the various fields in the mail-item table corresponding to a mail-item ID. The mail metafile includes information such as, the folder ID, message titles, the type, modified date, and location parameters. The location parameters help in locating the physical file in the back-up storage. Examples of the location parameters include, but are not limited to, mailbox ID, mail-item ID, and mod-content. In one implementation, the recovery module 112 creates the mail metafile, which is a JSON object. The JSON object includes one or more key-value pairs. Examples of the keys include, but are not limited to, type, mod-metadata, mail-item ID, date, folder ID, tags, size, volume ID, and mod-content. Further, for each key a corresponding value for the key is inserted in the JSON object. For instance, "size" field of the metafile is inserted as a key and corresponding value of the size field, say, "1626", is inserted as the value of the key. In another example, "folder-ID" field of the metafile is

inserted as a key and corresponding value of the "folder-ID", say, "2" is inserted as the value of the key. The JSON object facilitates compatibility of the recovery file with the recovery command, since the recovery module 112 may employ a recovery command that may import data, i.e., recover data using the recovery file only when it is in a predefined format. [00041] In one implementation, once the intermediate recovery files for all the mail-items to be recovered are created, the recovery module 112 creates byte arrays for each of the files, i.e., mail metafile and data file, of intermediate recovery files. Further, the recovery module 112 may determine header information for each byte array. The header information includes various fields, such as, a path of the mail item, size of the byte array, a minor-device ID, a major-device ID, and a group name. For example, minor-device ID is set as mail-item ID and the major-ID is set as type field. Further, the group name can be set as a string representation of type, which can be gathered from the mail-item list in other data 220, for example, for a mail-item with type value "1"; its string representation will be "Folder".
[00042] The recovery module 112 may be configured to convert these byte arrays into the recovery file, which may include compression of these byte arrays. In one example, the recovery file is an archive file created using various archival techniques, for example, by using a tar (tape archive) program, and various compression techniques, such as tar, gzip and bzip2. Further, the recovery module 112 may append the header information for all the byte arrays in an entry object with the recovery file
[00043] Thus, the recovery file includes the intermediate recovery files and therefore, the mail data in a compressed format, for example, a compressed tar file, and the entry abject, which contains information that allows these intermediate recovery files to be restored to their original form. The recovery module 112 may store the data pertaining to the intermediate recovery file(s) and the recovery file in the recovery data 216.
[00044] Once the recovery file is created, the recovery module 112 recovers the mail items, and corresponding metadata using various recovery commands. For example, the mail items are recovered by providing the recovery file as input parameter to a recovery command. Upon execution of the recovery command, the mail items are imported onto the mail server, which can now be accessed by the user.

[00045] Fig. 3 illustrates a method to recover one or more mail-items on a mail server, according to an embodiment of the present subject matter. The exemplary method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[00046] The order in which the method are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method is presently provided for a recovery of mail-items pertaining to a single user. It would be appreciated that the same method can also be implemented for a plurality of users without deviating from the scope of the present subject matter.
[00047] At block 302, one or more attributes associated with one or more mail items to be recovered are received. The mail item can be for example, folders, mail messages, attachments, contacts, flags, to-do lists, and appointments. The attributes includes, for example, a user ID, a folder name, and certain parameters like sender, date, subject, etc, associated with a mail item. In an implementation, a user provides the attributes to the recovery system 102 based on the mail-items to be recovered.
[00048] At block 304, based on the attributes of the mail item, mail metadata corresponding to the mail items is identified. The mail metadata includes information, for example, a database ID, the folder ID, and a mail item ID, which helps identify the mail item to be recovered. For example, the metadata identification module 110 indentifies the mail metadata corresponding to the mail items using information regarding various mail items

stored in the metadata 214. In one implementation, the metadata identification module 110 identifies a database associated with the mail items and subsequently identifies the mail metadata using metadata associated with the identified database.
[00049] At block 306, once the mail metadata is identified, one or more intermediate recovery files are created based on the mail metadata. For example, if the mail metadata indicates that a physical file is associated with a mail item, then corresponding intermediate recovery file includes a mail metafile and a data file. On the other hand, if the metadata indicates that no physical file is associated with the mail item, the intermediate recovery file only includes a mail metafile. In an example where the mail item is a folder, association of the physical file with the mail item is determined by checking association of the physical file with the folder, based on a folder-ID of the folder. In another example, if an entire mailbox is to be recovered, i.e., more than one mail item is to be recovered, then for each mail-item in the mailbox it is determined whether a physical file is associated with each mail-item or not. In yet another example, where the mail-item, such as a message, contact, and tag, is an item, which stored within a folder, then a corresponding folder of this mail-item is identified and based on a folder ID of the identified folder, it is determined whether a physical file is associated with the mail-item or not. In one implementation, the recovery module 112 creates the intermediate recovery files based on the folder ID associated with a mail item. [00050] At block 308, each intermediate recovery file is transformed into one or more byte arrays. In an example, the byte array contains the intermediate recovery file in a binary format and header information regarding the intermediate recovery file. In one implementation, the recovery module 112 transforms the intermediate recovery files into the byte arrays.
[00051] At block 310, the byte arrays are converted into a recovery file. The recovery file includes the byte arrays in a compressed format. Further, the recovery file may also include an entry object having the header information of the byte arrays. In an example, the recovery file facilitates recovery of the intermediate recovery files onto the mail server in their original format. In one implementation, the recovery module 112 converts the byte arrays into the recovery file, such as a compressed archive file. The intermediate recovery

files, byte arrays, and the compressed archive file, in an example, are stored in the recovery
data 216.
[00052] At block 312, the mail items are restored using the recovery file. In one
implementation, the recovery module 112 restores the mail items onto the mail server using
a recovery command, which uses the recovery file as an input.
[00053] Thus, the mail-items, which were not available on the mail server due to a data
loss, are made available to a user without having to put the mail server offline. Further, a
single mail-item, such as a mail message, may be recovered without having to restore entire
mailbox to which the mail-item belongs.
[00054] Although embodiments for recovery of the mail-items onto a mail server have
been described in language specific to structural features and/or methods, it is to be
understood that the invention is not necessarily limited to the specific features or methods
described. Rather, the specific features and methods are disclosed as exemplary
embodiments recovery of the mail-items onto the mail server.

I/We claim:
1. A method of recovering one or more mail items onto a mail server, the method
comprising:receiving at least one attribute associated with the one or more mail items; identifying mail metadata indicative of the one or more mail items to be recovered, based on the at least one attribute; and creating, based on the mail metadata, a recovery file for recovering the one or more mail items onto the mail server.
2. The method as claimed in claim 1, wherein the one or more mail items are from a group consisting of a folder, a tag a conversation, a message, a contact, an invite, a document, a note, a flag, an appointment, a virtual conversation, a mountpoint, a wiki, a task, and a chat.
3. The method as claimed in claim 1, wherein the one or more attributes comprise at least a user identification (ID).
4. The method as claimed in claim 1, wherein the mail metadata comprises one or more of a database ID, a mailbox ID, a folder ID, and a mail item ID.
5. The method as claimed in claim 1, wherein the identifying comprises: determining, based on the at least one attribute, a database associated with the one or more mail items; and gathering the mail metadata corresponding to the one or more mail items based on metadata associated with the database.
6. The method as claimed in claim 1, wherein the creating the recovery file comprises: generating, based on the mail metadata, at least one intermediate recovery file for the one or more mail items; and converting the at least one intermediate recovery file into the recovery file.
7. The method as claimed in claim 6, wherein the generating the at least one intermediate
recovery file comprises: determining, based on the mail metadata, association of a physical file with each of the one or more mail items; and based on the determining, providing a data file in the at least one intermediate recovery file.
8. The method as claimed in claim 6, wherein the at least one intermediate recovery file comprises at least a mail metafile.
9. The method as claimed in claim 6, wherein the converting the at least one intermediate recovery file into the recovery file comprises:
transforming the at least one intermediate recovery file into a byte array; and compressing the byte array to create the recovery file.
10. The method as claimed in claim 9, wherein the method further comprises: determining header information corresponding the byte array; and appending the header information with the recovery file.
11. A mail-item recovery system (102) comprising: a processor (204); and a memory (206) coupled to the processor (204), the memory (206) comprising, a metadata identification module (110) configured to identify mail metadata indicative of one or more mail items to be recovered based on at least one attribute of the one or more mail items; and a recovery module (112) configured to create a recovery file for recovering the one or more mail items onto a mail server, based on the mail metadata, wherein the recovery file includes at least a mail metafile which is indicative of the mail metadata corresponding to the one or more mail items.

12. The mail-item recovery system (102) as claimed in claim 11, wherein the recovery
module (112) is configured to: determine, based on the mail metadata, association of a physical file with each of the one or more mail items; and generate one or more intermediate recovery file for each of the mail items based on association of the physical file with each of the one or more mail items.
13. The mail-item recovery system (102) as claimed in claim 12, wherein the one or more intermediate recovery files include a data file when the physical file is associated with the one or more mail items.
14 The mail-item recovery system (102) as claimed in claim 12, wherein, the recovery module (112) is configured to: transform the intermediate recovery files into one or more byte arrays; determine header information corresponding to the byte arrays; compress the byte arrays to create the recovery file; and append the header information corresponding to the byte arrays with the recovery file.
15. The mail-item recovery system (102) as claimed in claim ] 1, wherein the recovery file is a tape archive file and the mail metafile is a JavaScript Object Notation object.
16. The mail-item recovery system (102) as claimed in claim 11, wherein the mail server is in a live state.