Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Incremental Snapshot after Reboot

IP.com Disclosure Number: IPCOM000193791D
Publication Date: 2010-Mar-09
Document File: 5 page(s) / 178K

Publishing Venue

The IP.com Prior Art Database


This publication describes the "Incremental snapshot after Reboot" functionality. The purpose of this functionality is enabling the continuance of the incremental snapshot process after a reboot of the client server with no IO monitoring misses or Delta Block functionality.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 5

A snapshot of data is a record that reflects the state of the data at a particular point

in time.

before time t and does not record any updates after time t.

    Full Snapshot - Record that contains all data. These snapshots typically run a long time, and require a lot of storage.

    Incremental Snapshot - Record that contains only the changed data since the last snapshot.

An incremental snapshot is based on a list of changes that were

recorded since the last snapshot. These snapshots typically run in a short amount of time, and require small amounts of storage. This is favorable way to take snapshots of data.

    Differential Snapshot - Record that contains changed data since the last snapshot. These snapshots are based on comparison between last snapshot and current state of data. These snapshots typically run a long time, but require small amounts of storage. Usually differential snapshot is created when list of changes since the last snapshot is unavailable (e.g. after computer reboot).

Snapshot is created by user mode application (client)

with help of filter driver,

                         and to report them to the client. Upon receiving report from driver, client backs up the original data, and then allows the intercepted write to be continued.

    Our invention solves the issue of continuance of the incremental snapshot process after a graceful reboot of the client server (instead of differential snapshot).

    Differential snapshot process is expensive and its price is paid by the customer production server: the entire content of the volume is read, CRC is computed for each block and network resources are used. This procedure may be very lengthy and production data I/O performance is degraded dramatically for the entire duration.

There are several design points that need to be fulfilled by this invention:
· There will be incremental forever snapshots for volumes, even when the protected server is restarted. Our invention handles a scenario of the server machine rebooting gracefully. In case of a sudden power shutdown, differential snapshot will be initiated.

· Consistency: The monitoring backup process should not miss any writes. Loosing writes in unacceptable - the user would notice writes are missing long time after the problem occurred (only when the user restores the data).

Detailed solution

Note: The current implementation is specific for Windows operating system.

The filter driver maintains a monitoring bitmap in memory. It stores the bitmap as a file on a disk.
1. The file is created by the filter driver for each disk that contains an extent of a monitored volume. The file is stored and restored by the driver.

2. The file is created when the first extent for this disk is monitored. The file is never deleted. The file should not be fragm...