HK1177520B - Recovery of tenant data across tenant moves - Google Patents

Description

Recovery of tenant data moved across tenants

Technical Field

The present invention relates to data storage, and more particularly to recovery of tenant data moved across tenants.

Background Art

Tenant data can be moved to different locations for various reasons. For example, tenant data can be moved when upgrading a farm, when more space is needed for tenant data, etc. In these cases, a new backup of the tenant data is made.

Summary of the Invention

This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Maintain a history of the location of tenant data. Tenant data includes data currently being used by the tenant and corresponding backup data. When tenant data is changed from one location to another, the location and time are stored in a history that can be accessed to determine the location of the tenant data at a given moment. Different operations trigger the storage of location/time within the history. Generally speaking, an operation that changes the location of tenant data triggers the storage of that location within the history (e.g., a farm upgrade, a tenant move, adding a tenant, load balancing of data, etc.). When an operation (e.g., restore) requires tenant data, the history can be accessed to determine the location of the data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 illustrates an exemplary computing environment;

FIG2 illustrates a system for moving data across tenants while preserving the location of tenant data;

FIG3 shows a history including a record of changes in the location of tenant data;

FIG4 illustrates a process for updating tenant data location change history; and

FIG. 5 illustrates a process for handling a request to restore tenant data from a backup location.

DETAILED DESCRIPTION

The various embodiments will now be described with reference to the accompanying drawings, in which like reference numerals represent like elements. In particular, FIG1 and the corresponding discussion are intended to provide a brief, general description of a suitable computing environment in which the various embodiments may be implemented.

Generally speaking, program modules include routines, programs, components, data structures, and other types of structures that perform specific tasks or implement specific abstract data types. Other computer system configurations may also be used, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Distributed computing environments in which tasks are performed by remote processing devices linked through a communication network may also be used. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

1 , an illustrative computer environment of a computer 100 utilized in various embodiments will be described. The computer environment shown in FIG1 includes computing devices, each of which can be configured as a mobile computing device (e.g., a phone, tablet, netbook, laptop), a server, a desktop computer, or some other type of computing device, and includes a central processing unit 5 (“CPU”), system memory 7 including random access memory 9 (“RAM”) and read-only memory (“ROM”) 10, and a system bus 12 that couples the memory to the central processing unit (“CPU”) 5.

A basic input/output system, containing the basic routines that help to transfer information between elements within the computer, such as during startup, is stored in ROM 10. Computer 100 also includes a mass storage device 14 for storing an operating system 16, applications 24, a web browser 25, and a backup manager 26, which are described in more detail below.

The mass storage device 14 is connected to the CPU 5 through a mass storage controller (not shown) connected to the bus 12. The mass storage device 14 and its associated computer-readable media provide non-volatile storage for the computer 100. Although the description of computer-readable media contained herein is directed to a mass storage device such as a hard disk or CD-ROM drive, computer-readable media can be any available media that can be accessed by the computer 100.

By way of example and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media also include, but are not limited to, RAM, ROM, erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), flash memory or other solid-state memory technology, CD-ROM, digital versatile disk ("DVD") or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the computer 100.

The computer 100 operates in a networked environment using logical connections to remote computers via a network 18, such as the Internet. The computer 100 can be connected to the network 18 via a network interface unit 20 connected to the bus 12. The network connection can be wireless and/or wired. The network interface unit 20 can also be used to connect to other types of networks and remote computer systems. The computer 100 may also include an input/output controller 22 for receiving and processing input from a plurality of other devices, including a keyboard, mouse, or electronic stylus (not shown in FIG. 1 ). Similarly, the input/output controller 22 can provide input/output for a display screen 23, a printer, or other types of output devices.

As briefly described above, a plurality of program modules and data files may be stored within the mass storage device 14 and RAM 9 of the computer 100, including an operating system 16 suitable for controlling the operation of the computer, such as the Windows 7, Windows Server, or Windows Phone 7 operating systems from Microsoft Corporation of Redmond, Washington. The mass storage device 14 and RAM 9 may also store one or more program modules. Specifically, the mass storage device 14 and RAM 9 may store one or more application programs, including one or more applications 24 and a web browser 25. According to one embodiment, the application 24 is an application configured to interact with an online service, such as a business point of sale that provides solutions to different tenants. Other applications may also be used. For example, the application 24 may be a client application configured to interact with data. The application may be configured to interact with many different types of data, including, but not limited to, documents, spreadsheets, slides, notes, and the like.

Network storage 27 is configured to store tenant data for tenants. Network storage 27 is accessible to one or more computing devices/users via IP network 18. For example, network storage 27 may store tenant data for one or more tenants for an online service, such as online service 17. Other network storage may also be configured to store tenant data. Tenant data may also be moved from one network storage to another.

The backup manager 26 is configured to maintain the location of tenant data in a history such as history 21. The backup manager 26 can be part of an online service such as online service 17, and all/some of the functionality provided by the backup manager 26 can be located inside/outside the application. Tenant data includes data currently being used by the tenant and corresponding backup data. When a tenant's data is changed from one location to another, the location and time are saved to history 21, which can be accessed to determine the location of the tenant data at a given moment. Different operations trigger the storage of the location/time in the history. Generally speaking, an operation that changes the location of tenant data triggers the storage of the location in the history (e.g., an upgrade of the farm, a move of a tenant, adding a tenant, load balancing of data, etc.). When an operation (e.g., a restore) requires tenant data, the history can be accessed to determine the location of the data. More details related to the backup manager are disclosed below.

2 shows a system for maintaining the location of tenant data while moving across tenants. As shown, system 200 includes a service 210, a data store 220, a data store 230, and a computing device 240.

The computing devices used may be any type of computing device configured to perform operations related to the use of the computing device. For example, some of these computing devices may be mobile computing devices (e.g., cell phones, tablet computers, smartphones, laptop computers, etc.); some may be desktop computing devices; and other computing devices may be configured as servers. Some computing devices may be arranged to provide cloud-based online services (e.g., service 210); some computing devices may be arranged to provide data sharing for data storage services; some computing devices may be arranged in a local network; some computing devices may be arranged in a network accessible via the Internet, etc.

The computing devices are coupled via a network 18. The network 18 can be any of many different types of networks. For example, the network 18 can be an IP network, a carrier network for cellular communications, and so on. Generally speaking, the network 18 is used to transfer data between computing devices such as the computing device 240, the data store 220, the data store 230, and the service 210.

Computing device 240 includes application 242, web browser 244, and user interface 246. As shown, a user uses computing device 240 to interact with a service, such as service 210. According to one embodiment, service 210 is a multi-tenant service. Generally speaking, multi-tenancy refers to the isolation of data (including backup), usage, and management between customers. In other words, even though data from each tenant can be stored in the same database within the same data store, data from one customer (Tenant 1) cannot be accessed by another customer (Tenant 2).

User interface (UI) 246 is used to interact with various applications that may be local or non-local to computing device 240. One or more user interfaces of one or more types may be used to interact with documents. For example, UI 246 may include the use of context menus, menus within a menu bar, menu items selected from a ribbon user interface, graphical menus, and the like. Generally speaking, UI 246 is configured so that a user can easily interact with the functionality of the applications. For example, a user may choose to restore tenant data maintained by service 210 by simply selecting an option within UI 246.

Data storage 220 and data storage 230 are configured to store tenant data. The data storage is accessible by various application computing devices. For example, the network storage may be associated with an online service that supports an online point of sale for a solution service. For example, the online service may provide data services, word processing services, spreadsheet services, etc.

As shown, data store 220 includes tenant data for N different tenants, including corresponding backup data. A data store can store all or part of a tenant's data. For example, some tenants may use more than one data store, while other tenants share the data store with many other tenants. Although the corresponding backup data for a tenant is shown within the same data store, the backup data may be stored elsewhere. For example, one data store may be used to store tenant data, while one or more other data stores may be used to store the corresponding backup data.

Data store 230 shows that the location of tenant data has been changed and the backup data has been changed from a different data store. In the current example, Tenant Data 2 and the corresponding backup data have been changed from data store 220 to data store 230. Tenant 3's backup data has been changed from data store 220 to data store 230. Tenant Data 8 has been changed from data store 220 to data store 230. Location changes can occur for a variety of reasons. For example, a tenant may need more space, a data store may be load balanced, the farm where the tenant is located may be upgraded, a data store may fail, a database may be moved/upgraded, and so on. Many other scenarios may cause a tenant's data to change. As can be seen from the current example, a tenant's data may be stored in one data store and the corresponding backup data may be stored in another data store.

Service 210 includes backup manager 26, historian 212, and web application 214 including web renderer 216. Service 210 is configured as an online service that provides services related to displaying and interacting with data from multiple tenants. Service 210 provides a shared infrastructure for multiple tenants. According to one embodiment, service 210 is Microsoft Corporation's SHAREPOINT ONLINE service. Different tenants can use service 210 to host their web application/site collections. Tenants can also use a dedicated service alone or in conjunction with the services provided by service 210. Web application 214 is configured to receive and respond to data-related requests. For example, service 210 can access tenant data stored on network storage 220 and/or network storage 230. Web application 214 can be used to provide an interface for users of computing devices, such as computing device 240, to interact with data accessible via network 18. Web application 214 can communicate with other servers to perform operations related to the service.

The service 210 receives a request from a computing device such as computing device 240. The computing device can send a request to the service 210 in order to interact with documents and/or other data. In response to this request, the web application 214 obtains data from a location such as a network share 230. The data to be displayed is converted into a markup language format such as the ISO/IEC 29500 format. The data can be converted by the service 210 or by one or more other computing devices. Once the web application 214 has received the markup language representation of the data, the service utilizes a web renderer 216 to convert the document formatted in the markup language into a representation of the data that can be rendered by a web browser application (such as a web browser 244 on the computing device 240). The rendered data looks substantially similar to the output of a corresponding desktop application for viewing the same data. Once the web renderer 216 has completed the rendering of the file, it is returned by the service 210 to the requesting computing device, where it can be rendered by the web browser 244.

The web renderer 216 is also configured to render one or more scripts into a markup language file for allowing a user of a computing device, such as the computing device 240, to interact with data in the context of the web browser 244. The web renderer 216 can be used to render script code that can be executed by the web browser application 244 into the returned web page. These scripts can, for example, provide functionality that allows a user to change data segments and/or modify values associated with the data. These scripts can be executed in response to certain types of user input. When the script is executed, a response can be transmitted to the service 210 that indicates that the document has been manipulated; identifies the type of interaction that has occurred; and further identifies to the web application 214 the function that should be performed on the data.

In response to an operation that causes a change in the location of tenant data, backup manager 26 places an entry in history 212. History 212 maintains a record of the location of tenant data and corresponding backup data. According to one embodiment, history 212 stores the name of the database and location used to store tenant data, the name and location of the backup location for the tenant data, and the time the data was stored at that location (see FIG. 3 and related discussion). Historical information can be stored in a variety of ways. For example, a historical record for each tenant can be stored in a database, historical information can be stored in a data file, etc.

According to one embodiment, backup manager 26 is configured to perform full backups of tenant data, as well as incremental backups and transaction log entries between full backups. The schedule for full backups is configurable. According to one embodiment, full backups are performed weekly, incremental backups are performed daily, and transactions are stored every five minutes. Other schedules may also be used and may be configurable. Different backups may be stored in the same location and/or in different locations. For example, full backups may be stored in a first location, while incremental backups and transaction logs may be stored in different locations.

Figure 3 shows a history including a record of changes in tenant data location. History 300 includes a record for each tenant being managed. For example, history 300 shows the history records for tenant 1 (310), tenant 2 (320), and tenant 8 (330).

As shown, history record 310 is created in response to Tenant 1 being added. According to one embodiment, the history record includes fields for content location, time, backup location, and time. The content location provides information about where the tenant's content is stored (e.g., database name, URL to the content location, etc.). The time 1 field indicates the last time the tenant's data was located at the specified location. According to one embodiment, when the time 1 field is empty, the time 2 value is used for the record. When both the time 1 field and the time 2 field are empty, the data is still located at the content location and backup location listed in the record. The backup location field indicates where the backup of the content is located. The time 2 field indicates the last time the tenant's backup data was located at the specified location.

Referring to the history (310) of Tenant 1, it can be seen that Tenant 1's data is located at the content location "Content 12" (e.g., the name of the database), and the backup data of Tenant 1's data is located at "backups\ds220\Content 12." In this case, the location of Tenant 1's data has not changed since Tenant 1 was added.

Tenant 2's data location changes from "Content 12" to "Content 56" and then to "Content 79." Before 10:00 AM on March 4, 2010, and after 1:04 AM on January 2, 2010, the data is stored in "Content 56," and the corresponding backup data is stored in "backups\ds220\Content 56." Before 1:04 AM on January 2, 2010, the data is stored in "Content 12," and the corresponding backup data is stored in "backups\ds220\Content 12."

The location of Tenant 3's data has changed from "Content 12" to "Content 15." The corresponding backup data has changed from "backups\ds220\Content 12" to "backups\ds220\Content 15" to "backups\ds230\Content 79." After 7:35 AM on March 12, 2010, Tenant 3's data is stored in "Content 15." Before 1:22 AM on March 24, 2010, and after 7:35 AM on March 12, 2010, the corresponding backup data is stored in "backups\ds220\Content 15." Before 7:35 AM on March 12, 2010, the data is stored in "Content 12," and the corresponding backup data is stored in "backups\ds220\Content 12." In the present example, while the location of the tenant data of the tenant 3 is not changed from "Content 15", the location of the backup data of the tenant 3 is changed.

Many other ways of storing information about the location of tenant data are possible. For example, a time field can include a start time and end time, a start time and no end time, or an end time and no start time. The location can be specified as a name, an identifier, a URL, etc. Other fields can also be included, such as a size field, a number of records field, a last access field, etc.

Figures 4 and 5 show an illustrative process for restoring tenant data across tenant moves. When reading the discussion of the routines provided herein, it should be understood that the logical operations of the various embodiments are implemented as (1) a series of computer-implemented actions or program modules running on a computing system, and/or (2) interconnected machine logic circuits or circuit modules within the computing system. The implementation is selected depending on the performance requirements of the computing system implementing the present invention. Therefore, the logical operations illustrated and constituting the embodiments described herein are variously represented as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented using software, firmware, dedicated digital logic, and any combination thereof.

FIG4 illustrates a process for updating tenant data location change history.

After the start block, process 400 moves to operation 410, where it is determined whether an operation has changed the location of tenant data. The change may involve all or part of the tenant data. Many different operations can cause a change in the location of tenant data. For example, adding a tenant, a field upgrade, a tenant move, load balancing of tenant data, load balancing of corresponding backup data, a maintenance operation, a failure, etc. In general, any operation that causes a change in the location of tenant data and/or corresponding backup data is determined.

Flowing to operation 420, the history of the tenant whose data is changing location is accessed. The history can be accessed within a local data store, a shared data store, and/or some other memory location.

Moving to operation 430, the tenant's history is updated to reflect the current state and any previous states of the tenant's data. According to one embodiment, each tenant includes a table indicating its corresponding history. The history can be stored using many different methods, using many different types of structures. For example, the history can be stored in memory, a file, a spreadsheet, or a database. The history can also be mixed within the data store, such as in a list, a spreadsheet, etc. According to one embodiment, the history includes fields for content location, time, backup location, and time. The content location provides information about where the tenant's content is stored (e.g., database name, URL to the content location, etc.). The time1 field indicates the time when the tenant's data was last located at the specified location. According to one embodiment, when the time1 field is empty, the time1 value is the same as the time2 field. When the time1 field and the time2 field are empty, the data is still located at the content location and the backup location. The backup location field indicates the location where the backup of the content is located. The time2 field indicates the time when the tenant's backup data was last located at the specified location.

The process then proceeds to the end block and returns to process other actions.

FIG. 5 illustrates a process for handling a request to restore tenant data from a previous location.

After the start block, the process moves to operation 510, where a request to restore tenant data is received. For example, the tenant may have accidentally deleted data they wish to restore. According to one embodiment, the request includes a time indicating when they believe they deleted the data. According to another embodiment, a time range may be specified. According to yet another embodiment, every location in the tenant's history may be searched for data without providing a time in the request.

Flowing to operation 520, the tenant's history is accessed to determine where the data is located. As discussed above, the history includes the current location of the tenant data and corresponding backup data, as well as each previous location of the data.

Moving to operation 530 , the tenant's data is restored to the temporary location so that the tenant's current data is not overwritten by undesired previous data.

Transitioning to operation 540, the requested data is extracted from the temporary location and restored to the current location of the tenant data.The data at the temporary location may be erased.

The process then flows to the end block and returns to process other actions.

The above specification, examples and data provide a complete description of the manufacture and use of the components of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (7)

1. A method for restoring lessee data across lessees, comprising: Perform a backup operation on the lessee data to generate lessee backup data; A historical database for maintaining the lessee's data, wherein the historical database includes at least a first storage location for the lessee's data and a second storage location for the corresponding lessee backup data; Determine the change operation to change the first storage location of the lessee data to a different third storage location; In response to the change operation, the historical database is updated, wherein updating the historical database includes: Update the storage location of the lessee data from the first storage location to the third storage location; Update the storage location of the corresponding lessee's backup data from the second storage location to the fourth storage location; and Add the time associated with the storage location of the updated tenant data; When requested, access the historical database to determine the first storage location of the tenant's data; and The lessee data is restored using the lessee data stored in the first storage location. 2. The method of claim 1, wherein the history is updated in response to at least one of the following: load balancing of at least one of the following: tenant data and backup data; tenant migration; in response to a field upgrade. 3. The method as described in claim 1, wherein the update history includes: the storage location of backup data corresponding to the backup of the storage and the lessee data. 4. The method as described in claim 3, wherein the backup data includes a full backup of the lessee data, an incremental backup of the lessee data, and a transaction log backup of the lessee data. 5. The method as described in claim 1, further comprising: determining the previous storage location of the tenant's data by accessing the storage location based on a comparison between a specified time and a historical time. 6. An apparatus for restoring lessee data across lessees, comprising: A unit for performing backup operations on the lessee data to generate backup data for the lessee; A unit for maintaining a historical database of the lessee's data, wherein the historical database includes at least a first storage location for the lessee's data and a second storage location for corresponding lessee backup data; A unit for determining a change operation that changes the first storage location of the lessee's data to a different third storage location; A unit for updating the historical database in response to the change operation, wherein the unit for updating the historical database includes: A unit for updating the storage location of the lessee data from the first storage location to the third storage location; A unit for updating the storage location of the corresponding lessee's backup data from the second storage location to the fourth storage location; and A unit for adding the time associated with the storage location of the updated lessee data; A unit for accessing the historical database upon request to determine the first storage location of the lessee's data; and A unit for restoring the lessee data using the lessee data stored in the first storage location. 7. A system for restoring lessee data across lessees, comprising: A network connection configured to connect to a network; Processors, memory, and computer-readable storage media; An operating environment stored on the computer-readable storage medium and executed on the processor; Data storage for tenant data associated with different tenants; and The backup manager is configured to perform actions, including: Perform a backup operation on the lessee data to generate lessee backup data; A historical database for maintaining the lessee data is provided, wherein the historical database includes the current storage location of the lessee data and corresponding backup data, as well as the previous storage location of the lessee data and corresponding backup data; Receive requests for tenant data; Access the historical database to determine the previous storage location of the lessee data using the time indicating when the lessee data was moved to backup storage, wherein the historical database also includes records for each storage location where the lessee data has been stored, wherein the records include the lessee data storage location, the backup storage location of the lessee backup data, and time information indicating when the data was located at each storage location; and The lessee data is restored using the lessee data stored in the previously stored location.