Methods and systems for creating and managing backups using virtual disks

A computer-implemented method may, at a first point in time, back up at least a portion of a data-storage entity to a first virtual-disk file. The computer-implemented method may capture, in a second virtual-disk file, at least one change made to data in the data-storage entity after the first point in time. The computer-implemented method may also create a parent-child relationship between the first virtual-disk file and the second virtual-disk file, with first virtual-disk file being a parent of the second virtual-disk file. The computer-implemented method may further copy data stored in the second virtual-disk file to the first virtual-disk file so that the first virtual-disk file includes the at least one change made to data in the data-storage entity after the first point in time. Various other methods, systems, and computer-readable media are also disclosed.

BACKGROUND

Backup and recovery are two significant issues facing Information Technology (“IT”) administrators. Whether from physical failure, human error, or a system crash, data loss is inevitable without an appropriate backup and recovery solution. IT administrators may examine their recovery point objectives (“RPO”) and recovery time objectives (“RTO”) when considering a proper backup and recovery solution. An IT organization may have a system that allows some data loss and only requires a backup once every day. Another system may require every change to be backed up, allowing data to be recovered from any point in time. Some non-critical systems may allow several days to recover after a failure; however, other critical systems, requiring high-availability, may require immediate failover.

Some IT organizations use physical machines for backup and recovery. A physical recovery point may need to be configured with hardware identical to a failed machine to recover data for the failed machine. Other solutions may allow recovery machines and failed machines to have different hardware, which may necessitate modifying data backed up from the failed machine to allow the data to run on the recovery machine.

Systems that need short recovery times may include a substantial amount of hardware redundancy—sometimes up to twice the number of physical machines needed for day-to-day operations. The extra machines may contain hot backups that allow a failed machine to be replaced instantly. In addition to the extra hardware costs, such disaster recovery systems may consume management resources to keep the backup machines and the production machines in sync.

IT administrators are increasingly turning to computer system virtualization to better administer and manage their infrastructures. In some cases, virtualization may reduce overall costs, including those associated with backup and recovery. Some traditional backup and recovery systems may implement virtualization by converting a backup file to a virtual-disk file to allow a virtual machine to be booted from the virtual-disk file. Unfortunately, converting backup files to virtual-disk files may consume additional data storage and may involve substantial input/output (“I/O”) and processing.

SUMMARY

The instant disclosure is directed to methods and systems for creating and managing backups using virtual-disk files. Embodiments of the instant disclosure may enable an IT administrator to backup data to a virtual-disk file, capture incremental changes in an incremental virtual-disk file, and roll the incremental changes into the virtual-disk file. For example, at a first point in time, a backup module may back up data from a data-storage entity (e.g., a volume) to a first virtual-disk file. At a second point in time, the backup module may capture, in a second virtual-disk file (e.g., an incremental virtual-disk file), a change made to the data in the data-storage entity. The backup module may create a parent-child relationship linking the first and second virtual-disk files. The backup module may then copy the data from the second virtual-disk file to the first virtual-disk file so that the first virtual-disk file contains a synthetic full backup of the data from the data-storage entity as it existed at the second point in time.

In some embodiments, the first virtual-disk file may include a full backup of the data-storage entity, and the second virtual-disk file may include an incremental backup of the data-storage entity. In other embodiments, the first and second virtual-disk files may both be incremental backups of the data-storage entity. According to certain embodiments, the first and second virtual-disk files may comprise a virtual-machine-disk-format file or a virtual-hard-disk file.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Embodiments of the instant disclosure provide methods and systems for creating and managing backups using virtual disks. For example, a backup module may backup a data-storage entity, (e.g., a full or incremental backup) to a virtual-disk file at a first point in time. Later, the backup module may capture, in a second virtual-disk file, at least one change made to data stored in the data-storage entity (e.g., an incremental backup). The backup module may then copy data from the second virtual-disk file to the first virtual-disk file so that the first virtual-disk file contains a backup that represents the data-storage entity at the later point in time. A recovery module may be programmed to use an empty virtual-disk file for retargeting and/or to use the first empty virtual-disk file to boot a virtual machine from the first virtual-disk file.

Embodiments described herein may provide one or more features and/or advantages not provided by traditional backup systems. For example, using a virtual-disk file as a backup as described herein may avoid the costly I/O, processing, and data storage involved in converting backup files to virtual-disk files. Furthermore, using a virtual-disk file as a backup may be advantageous because one or more other appliances, such as deduplication appliances, may be configured to handle virtual-disk file formats but may not be configured to handle one or more other traditional backup file formats.

FIG. 1shows an exemplary system for creating and managing backups using virtual disks,FIGS. 2 and 3show an exemplary method for accomplishing the same.FIG. 4illustrates a timeline showing backup events, andFIGS. 5 and 6illustrate an exemplary network and computing system for implementing embodiments of the instant disclosure.

FIG. 1illustrates an exemplary backup system100for creating and managing backups using virtual disks. System100may include modules110and storage entities120. Modules110may include a backup module112and a recovery module114. Backup module112may be programmed to, at a first point in time, back up at least a portion of data-storage entity122to backup virtual-disk file124. Backup module112may also be programmed to capture, in backup virtual-disk file128, one or more changes made to the data in data-storage entity122. Backup module112may also be programmed to create a parent-child relationship between backup virtual-disk file124and backup virtual-disk file128, where backup virtual-disk file124is the parent of backup virtual-disk file128. Backup module112may be further programmed to copy data stored in backup virtual-disk file128to backup virtual-disk file124so that backup virtual-disk file124contains the one or more changes made to data-storage entity122. Recovery module114may be programmed to use an empty virtual-disk file126for retargeting and/or to boot a virtual machine from backup virtual-disk file124.

In certain embodiments, one or more of modules110inFIG. 1may represent one or more software applications or programs that, when executed by a computing system, may cause the computing system to perform one or more steps disclosed herein. For example, as will be described in greater detail below, one or more of modules110may represent software modules configured to run on one or more computing devices, such as computing system510inFIG. 5and/or portions of exemplary network architecture600inFIG. 6. One or more of modules110inFIG. 1may also represent all or portions of one or more special-purpose computers configured to perform one or more of the tasks associated with steps disclosed herein.

As previously noted, system100may include storage entities120. As used herein, the phrase “storage entity” may refer to any physical and/or logical storage entity. For example, a storage entity may include a volume, a physical disk, a virtual disk, a partition on a drive, a set of one or more data entities (e.g., files, blocks, clusters), and/or any other data storage area.

Storage entities120may include data-storage entity122, a backup virtual-disk file124, an empty virtual-disk file126, a backup virtual-disk file128, an empty virtual-disk file130, a backup virtual-disk file132, and an empty virtual-disk file134. One or more of storage entities120inFIG. 1may represent a portion of one or more computing devices. For example, one or more of storage entities120may represent a portion of one or more of computing system510inFIG. 5, and/or portions of exemplary network architecture600inFIG. 6. Alternatively, one or more of storage entities120inFIG. 1may represent one or more physically separate devices capable of being accessed by a computing device, such as one or more of computing system510inFIG. 5, and/or portions of exemplary network architecture600inFIG. 6.

As used herein, the phrases “virtual disk” and “virtual-disk file” may refer to a disk that may appear to an operating system to be a physical disk. In some embodiments, virtual disks may be implemented using a disk emulator. A virtual disk may emulate any type of physical disk, such a hard drive, an optical disk, a network share, and/or any other physical storage entity.

A backup virtual-disk file may comprise a virtual-machine-disk-format file, a virtual-hard-disk file, or any other virtual-disk file format. An example of a virtual-machine-disk-format file is a VMWARE VIRTUAL-MACHINE-DISK-FORMAT file (“VMDK”). An example of a virtual-hard-disk file is a MICROSOFT VIRTUAL-HARD-DISK file (“VHD”). In certain embodiments, a backup virtual-disk file may include an incremental virtual-disk file. An incremental virtual-disk file may include any file that stores incremental changes. An incremental virtual-disk file may store an incremental backup. Examples of incremental virtual-disk files include MICROSOFT's UNDO file and VMWARE's REDO file.

FIG. 2shows an exemplary method for creating and managing backups using virtual disks. The steps shown inFIG. 2may be performed by any suitable computer executable code and/or computing system. In some embodiments, the steps shown inFIG. 2may be performed by one or more of backup module112and/or recovery module114. For example, at step210backup module112may, at a first point in time, back up at least a portion of data-storage entity122to backup virtual-disk file124. Backup module112may back up at least a portion of data-storage entity122to virtual-disk file124in any suitable manner. Backing up at least a portion of the data-storage entity may include backing up one or more bytes from the data-storage entity, backing up one or more blocks from the data-storage entity, backing up one or more sectors from the data-storage entity, backing up one or more file-level elements (e.g., files, directories, etc.) stored in the data-storage entity, and/or backing up any other data unit stored in the data-storage entity.

Backup module112may backup any data stored in data-storage entity122. Data may include any computer-readable (i.e. binary) information stored in data-storage entity122. Examples of data include files (e.g., program files, registry files, hidden files, encrypted files, etc.), directories, system descriptions, boot sectors, partition layouts, file metadata, and system metadata. In some embodiments, data-storage entity122may comprise a volume. A volume may include any storage medium accessible by a single file system. Examples of a volume include a hard disk, an optical disk (e.g., DVD-ROM, CD-ROM, etc.), a flash memory drive, a floppy disk, a tape medium (e.g., DAT, DDS, LTO, or DLT), a partition on a hard disk, a RAID array, a storage area network (“SAN”), a network-attached storage (“NAS”) device, or a virtual disk.

In some embodiments, backup virtual-disk file124may contain a full back up of data-storage entity122. As used herein, the phrase “full backup” may refer to any data backup that includes each data unit (e.g., block, sector, cluster, file, etc.) in a set of data units. For example, a full backup of a volume may include each block in the volume. In some embodiments, a full backup may include only those clusters (blocks) that are currently allocated by the file system while skipping clusters that are not currently allocated by the file system. In some embodiments, a full backup may include only those files which have been identified for backup, which means that a full backup may include a subset of the data on a system or volume. In other embodiments, a full backup may include a copy of all data and/or software on a system. For example, a full backup may include an entire data store, regardless of whether or not that data has been changed since a previous backup was performed. A full backup may include all data needed for a complete system restoration. A full backup may be a starting point for other backups (e.g., incremental backups).

In other embodiments, backup virtual-disk file124may contain an incremental backup of data-storage entity122. An incremental backup may include only changes made to data that has already been backed up. For example, an incremental backup may only include changes made to a data storage entity since a previous incremental or full backup. In some embodiments, an incremental backup may include data units for which an archive bit (or other backup indicator) is set.

At step220, backup module112may capture, in backup virtual-disk file128, at least one change made to data in data-storage entity122after the first point in time. Backup module112may capture the at least one change in any suitable manner. For example, backup module112may capture changes to one or more blocks stored in data-storage entity122, changes to one or more sectors stored in data-storage entity122, changes to one or more clusters stored in data-storage entity122, and/or changes to one or more file-level elements stored in data-storage entity122. The one or more changes captured after the first point in time may be referred to as a snapshot of data-storage entity122. Backup module112may capture the at least one change as a full or incremental backup. In some embodiments, backup virtual-disk file128may comprise an incremental backup of data-storage entity122. In other embodiments, backup virtual-disk file128may comprise a full backup of data-storage entity122. In at least one embodiment, backup module112may monitor data-storage entity122and use a copy-on-write method to capture the at least one change by capturing every write made to data-storage entity122.

Backup module112may capture the at least one change made to data in data-storage entity122at various intervals. For example, backup module112may capture changes to data-storage entity122once every minute, once every hour, once every day, or once every week. In other embodiments, backup module112may capture changes to data-storage entity122at irregular intervals. Backup module112may also provide continuous data protection by capturing every write made to data in data-storage entity122to a separate backup file.

At step230, backup module112may create a parent-child relationship between backup virtual-disk file124and backup virtual-disk file128, with backup virtual-disk file124being a parent of backup virtual-disk file128. Backup module112may create and store the parent-child relationship in any suitable manner. A parent-child relationship between two virtual-disk files may indicate that the child virtual-disk file holds incremental changes made to data since the parent virtual-disk file was created.

At step240, backup module112may copy data stored in backup virtual-disk file128to backup virtual-disk file124so that backup virtual-disk file124includes the at least one change made to data in data-storage entity122after the first point in time. As a result, virtual-disk file124may represent data-storage entity122at a second point in time. In embodiments where backup virtual-disk file124includes a full backup, backup virtual-disk file124may be referred to as a full synthetic backup of data-storage entity122. As used herein, the phrase “full synthetic backup” may refer to a full backup taken at a first point in time that has been updated to include one or more changes made to a data-storage entity through a second point in time. Backup module112may transform backup virtual-disk file124into a full synthetic backup by copying data stored in backup virtual-disk file128to backup virtual-disk file124.

Backup module112may begin copying data stored in backup virtual-disk file128to backup virtual-disk file124at various points during a backup process. In some embodiments, backup module112may begin copying data from backup virtual-disk file128to backup virtual-disk file124immediately after the data is captured in backup virtual-disk file128. In other embodiments, backup module112may copy data from backup virtual-disk file128to backup virtual-disk file124at a predetermined point in time.

In some embodiments, backup module112may not begin copying data stored in backup virtual-disk file128to backup virtual-disk file124until the capturing of the at least one change is complete. That way, if the capturing fails, backup virtual-disk file124may be used as the last successful backup. If the capturing succeeds, backup virtual-disk file128may be used as the last successful backup. If backup module112begins to copy data stored in backup virtual-disk file128to backup virtual-disk file124before the capturing is complete and the capturing fails then backup virtual-disk files124and128may no longer be valid backups of data-storage entity122.

FIG. 3shows another exemplary method for creating and managing backups using virtual disks. The steps shown inFIG. 3may be performed by any suitable computer executable code and/or computing system. In some embodiments, the steps shown inFIG. 3may be performed by one or more of backup module112and/or recovery module114. For example, at step305backup module112may, at a first point in time, back up at least a portion of data-storage entity122to backup virtual-disk file124.

At step310, backup module112may create empty virtual-disk file126, which may be an incremental virtual-disk file. At step315, backup module112may create a parent-child relationship between backup virtual-disk file124and empty virtual-disk file126, with backup virtual-disk file124being a parent of empty virtual-disk file126. In at least one embodiment, recovery module114may retarget empty virtual-disk file126to enable a virtual machine to boot from backup virtual-disk file124. Retargeting empty virtual-disk file126may include any action that enables a virtual machine to boot from backup virtual-disk file124. Examples of retargeting may include replacing, reconfiguring, and/or installing one or more of the Hardware Abstraction Layer (“HAL”), kernel, mass storage driver, and/or any other device drivers.

In certain embodiments, recovery module114may use empty virtual-disk file126to boot a virtual machine from backup virtual-disk file124. The virtual machine may redirect future writes to empty virtual-disk file126, allowing backup virtual-disk file124to remain unchanged. As long as backup virtual-disk file124remains unchanged, backup virtual-disk file124may be used as a base or parent for additional incremental backups.

At step320, backup module112may capture, in backup virtual-disk file128, at least one change made to data in data-storage entity122after the first point in time. At step325, backup module112may create a parent-child relationship between backup virtual-disk file124and backup virtual-disk file128, with backup virtual-disk file124being a parent of backup virtual-disk file128.

At step340, backup module112may copy data stored in backup virtual-disk file128to backup virtual-disk file124so that backup virtual-disk file124includes the at least one change made to data in data-storage entity122after the first point in time. After the data stored in backup virtual-disk file128is copied to backup virtual-disk file124, backup virtual-disk file124may no longer be a valid parent of empty virtual-disk file126. At the same time, backup virtual-disk file128may contain redundant information. Therefore at step345, backup module112may modify the parent-child relationship of empty virtual-disk file130such that empty virtual-disk file130is a child of backup virtual-disk file124instead of being a child of backup virtual-disk file128. At step350, backup module112may delete backup virtual-disk file128and empty virtual-disk file126.

FIG. 4is a timeline showing backup events of an exemplary system for creating and managing backups using virtual disks.FIG. 4shows timeline400containing point in time410, point in time412, and point in time414. Point in time410, point in time412, and point in time414may refer to points in time from steps described and/or illustrated herein. In some embodiments, backup module112may, at point in time410, backup at least a portion of data-storage entity122to backup virtual-disk file124. Backup module112may then create empty virtual-disk file126. Backup module112may associate empty virtual-disk file126with backup virtual-disk file124so that a virtual machine may boot backup virtual-disk file124and may access the at least a portion of data-storage entity122as it existed at point in time410without modifying virtual disk file124.

At point in time412, backup module112may capture, in backup virtual-disk file128, at least one change made to data in data-storage entity122. Backup module112may create a parent-child relationship between backup virtual-disk file128and backup virtual-disk file124, with backup virtual-disk file124being a parent to backup virtual-disk file128. Backup module112may also create empty virtual-disk file130and associate it with backup virtual-disk file128. Empty virtual-disk file130may then be used to enable a virtual machine to boot from backup virtual-disk file128. Therefore, the virtual machine may access the at least a portion of data-storage entity122as it existed at point in time412.

Backup module112may continue to make any number of additional backups of data-storage entity122in a similar manner. For example, backup module112may capture, in backup virtual-disk file132, at least one change made to data in data-storage entity122at point in time414. In some embodiments, the at least one change may include only the changes made to data in data-storage entity122since point in time412. In certain embodiments, backup module112may create a parent-child relationship between backup virtual-disk file132and backup virtual-disk file128, with backup virtual-disk file128being a parent to backup virtual-disk file132. Backup module112may also create empty virtual-disk file134and associate it with backup virtual-disk file132. Empty virtual-disk file134may then be used to enable a virtual machine to boot from backup virtual-disk file132. Therefore, a virtual machine may access the data stored in data-storage entity122as it existed at point in time414.

After point in time414, backup module112may roll the data in backup virtual-disk file132into backup virtual-disk file128. After the data is copied from backup virtual-disk file132to backup virtual-disk file128, backup module112may update the parent-child relationship between backup virtual-disk file132and empty virtual-disk file134such that backup virtual-disk file128is the parent of empty virtual-disk file134. Backup module112may then delete backup virtual-disk file132and empty virtual-disk file130. At this point, backup virtual-disk file128may be accessible as a backup that represents a state of data-storage entity122at point in time414.

Backup module112may also roll the data in backup virtual-disk file128into backup virtual-disk file124. After the data is copied, backup module112may update the parent-child relationship between backup virtual-disk file124and empty virtual-disk file126such that backup virtual-disk file124is the parent of empty virtual-disk file134. Backup module112may then delete backup virtual-disk file128and empty virtual-disk file126. At this point, backup virtual-disk file124may be accessible as a backup that represents a state of data-storage entity122at point in time414. If backup module112were to copy the data from virtual-disk file128to virtual-disk file124, without having previously copied the data in virtual-disk file132into virtual-disk file128, then before deleting virtual-disk file128, it would also need to update virtual-disk file132so that virtual-disk file132's parent becomes virtual-disk file124. Similarly, if virtual-disk file128is copied back into virtual-disk file124before virtual-disk file132is created, then virtual-disk file132would be created with virtual-disk file124as its parent.

In some embodiments, backup module112may, when creating parent-child relationships, define backup virtual-disk file124as the parent of every backup virtual-disk file created after point in time410. These additional backup virtual-disk files may be referred to as differential backups.

FIG. 5is a block diagram of an exemplary computing system510capable of implementing one or more of the embodiments described and/or illustrated herein. Computing system510broadly represents any single or multi-processor computing device or system capable of executing computer-readable instructions. Examples of computing system510include, without limitation, workstations, laptops, client-side terminals, servers, distributed computing systems, handheld devices, or any other computing system or device. In its most basic configuration, computing system510may comprise at least one processor514and system memory516.

Processor514generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. In certain embodiments, processor514may receive instructions from a software application or module. These instructions may cause processor514to perform the functions of one or more of the exemplary embodiments described and/or illustrated herein. For example, processor514may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps described herein. Processor514may also perform and/or be a means for performing any other steps, methods, or processes described and/or illustrated herein.

In certain embodiments, exemplary computing system510may also comprise one or more components or elements in addition to processor514and system memory516. For example, as illustrated inFIG. 5, computing system510may comprise a memory controller518, an Input/Output (I/O) controller520, and a communication interface522, each of which may be interconnected via a communication infrastructure512. Communication infrastructure512generally represents any type or form of infrastructure capable of facilitating communication between one or more components of a computing device. Examples of communication infrastructure512include, without limitation, a communication bus (such as an ISA, PCI, PCIe, or similar bus) and a network.

Memory controller518generally represents any type or form of device capable of handling memory or data or controlling communication between one or more components of computing system510. For example, in certain embodiments memory controller518may control communication between processor514, system memory516, and I/O controller520via communication infrastructure512. In certain embodiments, memory controller518may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the steps or features described and/or illustrated herein, such as backing up, capturing, creating, copying, retargeting, using, modifying, and deleting.

I/O controller520generally represents any type or form of module capable of coordinating and/or controlling the input and output functions of a computing device. For example, in certain embodiments I/O controller520may control or facilitate transfer of data between one or more elements of computing system510, such as processor514, system memory516, communication interface522, display adapter526, input interface530, and storage interface534. I/O controller520may be used, for example, to perform and/or be a means for backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps described herein. I/O controller520may also be used to perform and/or be a means for performing other steps and features set forth in the instant disclosure.

In certain embodiments, communication interface522may also represent a host adapter configured to facilitate communication between computing system510and one or more additional network or storage devices via an external bus or communications channel. Examples of host adapters include, without limitation, SCSI host adapters, USB host adapters, IEEE 1394 host adapters, SATA and eSATA host adapters, ATA and PATA host adapters, Fibre Channel interface adapters, Ethernet adapters, or the like. Communication interface522may also allow computing system510to engage in distributed or remote computing. For example, communication interface522may receive instructions from a remote device or send instructions to a remote device for execution. In certain embodiments, communication interface522may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps disclosed herein. Communication interface522may also be used to perform and/or be a means for performing other steps and features set forth in the instant disclosure.

As illustrated inFIG. 5, exemplary computing system510may also comprise at least one input device528coupled to communication infrastructure512via an input interface530. Input device528generally represents any type or form of input device capable of providing input, either computer or human generated, to exemplary computing system510. Examples of input device528include, without limitation, a keyboard, a pointing device, a speech recognition device, or any other input device. In at least one embodiment, input device528may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps disclosed herein. Input device528may also be used to perform and/or be a means for performing other steps and features set forth in the instant disclosure.

Storage devices532and533may also be used, for example, to perform and/or be a means for performing, either alone or in combination with other elements, one or more of the identifying, backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps disclosed herein. Storage devices532and533may also be used to perform and/or be a means for performing other steps and features set forth in the instant disclosure.

FIG. 6is a block diagram of an exemplary network architecture600in which client systems610,620, and630and servers640and645may be coupled to a network650. Client systems610,620, and630generally represent any type or form of computing device or system, such as exemplary computing system510inFIG. 5. Similarly, servers640and645generally represent computing devices or systems, such as application servers or database servers, configured to provide various database services and/or to run certain software applications. Network650generally represents any telecommunication or computer network; including, for example, an intranet, a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or the Internet.

As illustrated inFIG. 6, one or more storage devices660(1)-(N) may be directly attached to server640. Similarly, one or more storage devices670(1)-(N) may be directly attached to server645. Storage devices660(1)-(N) and storage devices670(1)-(N) generally represent any type or form of storage device or medium capable of storing data and/or other computer-readable instructions. In certain embodiments, storage devices660(1)-(N) and storage devices670(1)-(N) may represent network-attached storage (NAS) devices configured to communicate with servers640and645using various protocols, such as NFS, SMB, or CIFS.

In at least one embodiment, all or a portion of one or more of the exemplary embodiments disclosed herein may be encoded as a computer program and loaded onto and executed by server640, server645, storage devices660(1)-(N), storage devices670(1)-(N), storage devices690(1)-(N), intelligent storage array695, or any combination thereof. All or a portion of one or more of the exemplary embodiments disclosed herein may also be encoded as a computer program, stored in server640, run by server645, and distributed to client systems610,620, and630over network650. Accordingly, network architecture600may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the backing up, capturing, creating, copying, retargeting, using, modifying, and deleting steps disclosed herein. Network architecture600may also be used to perform and/or be a means for performing other steps and features set forth in the instant disclosure.

As detailed above, computing system510and/or one or more of components of network architecture600may perform and/or be a means of performing, either alone or in combination with other elements, one or more steps of the exemplary methods described and/or illustrated herein. For example, a computing system (e.g., computing system510and/or one or more of the components of network architecture600) may perform a computer-implemented method for creating and managing backups using virtual disks. For example, the computing system may at a first point in time, back up at least a portion of a data-storage entity to a first virtual-disk file. The computing system may capture, in a second virtual-disk file, at least one change made to data in the data-storage entity after the first point in time.

The computing system may also create a parent-child relationship between the first virtual-disk file and the second virtual-disk file, with the first virtual-disk file being a parent of the second virtual-disk file. The computing system may further copy data stored in the second virtual-disk file to the first virtual-disk file so that the first virtual-disk file includes the at least one change made to data in the data-storage entity after the first point in time. In some embodiments, the first virtual-disk file may include a full backup of the data-storage entity, and the second virtual-disk file may include an incremental backup of the data-storage entity. In other embodiments, the first virtual-disk file may include a first incremental backup of the data-storage entity. The second virtual-disk file may include a second incremental backup of the data-storage entity.

In various embodiments, the computing system may create a first empty virtual-disk file. The computing system may create a parent-child relationship between the first virtual-disk file and the first empty virtual-disk file, with the first virtual-disk file being a parent of the first empty virtual-disk file. In some embodiments, the computing system may retarget the first empty virtual-disk file to enable a virtual machine to boot from the first virtual-disk file. In at least one embodiment, the computing system may use the first empty virtual-disk file to boot a virtual machine from the first virtual-disk file.

In some embodiments, the computing system may create a second empty virtual-disk file. The computing system may also create a parent-child relationship between the second virtual-disk file and the second empty virtual-disk file, the second virtual-disk file being a parent of the second empty virtual-disk file. The computing system may, after copying data stored in the second virtual-disk file to the first virtual-disk file, modify the parent-child relationship of the second empty virtual-disk file such that the second empty virtual-disk file is a child of the first virtual-disk file instead being a child of the second virtual-disk file.

In various embodiments, the computing system may, after copying data stored in the second virtual-disk file to the first virtual-disk file, delete the second virtual-disk file and the first empty virtual-disk file. In other embodiments, the computing system may be triggered, by the completion of the capturing at least one change made to data in the data-storage entity, to copy the data stored in the second virtual-disk file to the first virtual-disk file. In some embodiments the virtual-disk file may include a virtual-machine-disk-format (“VMDK”) file or a virtual-hard-disk (“VHD”) file. In at least one embodiment, the data-storage entity may comprise a volume.

In some embodiments, the computing system may include a backup module. The backup module may, at a first point in time, back up at least a portion of a data-storage entity to a first virtual-disk file. The backup module may capture, in a second virtual-disk file, at least one change made to data in the data-storage entity after the first point in time. The backup module may also create a parent-child relationship between the first virtual-disk file and the second virtual-disk file, the first virtual-disk file being a parent of the second virtual-disk file. The backup module may further copy data stored in the second virtual-disk file to the first virtual-disk file so that the first virtual-disk file includes the at least one change made to data in the data-storage entity after the first point in time. The computing system may include a storage device in communication with the backup module. The storage device may store the first virtual-disk file and/or the second virtual-disk file. The computing system may also include a processor configured to execute the backup module.

In some embodiments, the first virtual-disk file may comprise a full backup of the data-storage entity. The second virtual-disk file may comprise an incremental backup of the data-storage entity. In other embodiments, the first virtual-disk file may comprise a first incremental backup of the data-storage entity, and the second virtual-disk file may comprise a second incremental backup of the data-storage entity. In various embodiments, the backup module may create a first empty virtual-disk file. The backup module may also create a parent-child relationship between the first virtual-disk file and the first empty virtual-disk file, with the first virtual-disk file being a parent of the first empty virtual-disk file.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments described herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. It is desired that the embodiments described herein be considered in all respects illustrative and not restrictive and that reference be made to the appended claims and their equivalents for determining the scope of the instant disclosure.