Abstract: A backup administrator can backup files from a production server on any of a plurality of different bases. In particular, some files can be replicated on a changed-byte basis. In other cases, files can be backed up by replicating updated copies of the entire file, or even byte blocks of the file. Determinations as to how a replication agent will back up a certain file or set of files can be made by a backup administrator, automatically through a predefined logic, or dynamically based on defined criteria. Corresponding agents at the production server can then flag these files as indicated. Thus, at a later point, when the DPM server requests the updates of each file, the production server can either send over copies of the changed file bytes, entire copies of the changed file itself, or even changed blocks of a file, as appropriate.

Abstract: Data can be protected at a production server in a virtually continuous fashion, without necessarily imposing severe constraints on the source application(s). For example, a production server can create an application-consistent backup of one or more volumes, the backups corresponding to a first instance in time. A volume filter driver can monitor data changes in each volume using an in-memory bitmap, while a log file and/or update sequence number journal can keep track of which files have been added to or updated. The volume updates are also consistent for an instance (later) in time. At the next replication cycle, such as every few minutes (however configured), the volume filter driver passes each in-memory bitmap to the physical disk on the production server. The production server then sends the updates to the backup server, which thus stores application-consistent backups for the volume for multiple instances of time.

Abstract: A method for verifying data copies generated by a data protection system is provided. In accordance with the method, intents for selecting a data copy to be verified are determined. The intents may specify a time period after which data is to be verified and an interval for which the verification is to be repeated. Additionally, utilizing the intents, a data copy matching those intents is identified and verified. A data copy may be verified by comparing a checksum of the data copy with a known checksum value. If the data copy fails to be verified, a copy of the data copy is generated.

Abstract: A backup system in accordance with an implementation of the present invention includes one or more light-weight (i.e., stateless) storage nodes that are positioned close enough to one or more assigned production servers to enable as rapid and efficient a data recovery as possible. The one or more light-weight storage nodes are driven by, and implement backup policies in accordance with, control settings determined by and received from a centralized backup server. Changes to the control settings are simply produced at the centralized backup server and propagated to each storage node in the system. In addition to efficient backup times, general backup administration can be greatly simplified at least in part since a large number of production serves can be serviced through a small or large number of light-weight storage nodes, which in turn can be managed by a single centralized backup server.

Abstract: Data can be protected at a production server in a virtually continuous fashion, without necessarily imposing severe constraints on the source application(s). For example, a production server can create an application-consistent backup of one or more volumes, the backups corresponding to a first instance in time. A volume filter driver can monitor data changes in each volume using an in-memory bitmap, while a log file and/or update sequence number journal can keep track of which files have been added to or updated. The volume updates are also consistent for an instance (later) in time. At the next replication cycle, such as every few minutes (however configured), the volume filter driver passes each in-memory bitmap to the physical disk on the production server. The production server then sends the updates to the backup server, which thus stores application-consistent backups for the volume for multiple instances of time.

Abstract: A method and system thereof for dynamically configuring a device, adapted to be communicatively coupled in a wireless personal area network, with an attribute corresponding to a characteristic of the device. In one embodiment, the method involves receiving an attribute setting corresponding to characteristics of the device and implementing a corresponding configuration state. In this embodiment, the configuration state activates a corresponding device configuration. In one embodiment, the attribute setting constitutes a discretely variable value conforming to the degree of mobility of the device. In one embodiment, an attribute setting constitutes a discretely variable value conforming to the location of the device. In one embodiment, two attribute settings constitute discretely variable values conforming, one to the degree of mobility of the device, and the other to its location. In one embodiment, the device and network incorporate communicative capability compliant with the Bluetooth specification.

Abstract: An improved mechanism for processing client requests is disclosed. The first time a client request for a particular resource is received by a server, it is processed by stepping through a configuration file, and selectively executing directives specified in the configuration file. As the request is processed, a list of executed directives is compiled. This list of directives is stored for future reference. The next time a request for that same resource is received, the configuration file is not consulted. Instead, the stored list of directives is accessed and used to process the request. More specifically, all of the directives on the list are executed to process the request. Processing the subsequent request in this way eliminates much of the overhead associated with request processing. There is no need to open or to step through the configuration file, and there is no need to step through the directives themselves.