Point-in-time copy Yesterday, today and tomorrow.pdfVIP

259 Point-in-Time Copy: Yesterday, Today and Tomorrow Alain Azagury, Michael E. Factor and Julian Satran IBM Research Lab in Haifa MATAM, Haifa 31905, Israel {azagury, factor, satran}@ Phone: +972 4 829-6211, Fax: +972 4 829-6116 William Micka IBM Storage Systems Group 9000 S RITA ROAD, Tucson, AZ, USA micka@ Phone: +1 520 799-4132 1. Introduction Making copies of large sets of data is a common activity. These copies can provide a consistent image for a backup, a checkpoint for restoring the state of an application, a source for data mining, real data to test a new version of an application, and so on. One characteristic all of these uses have in common is that it is important that the copy appear to occur atomically, i.e., any updates to the data source being copied either occur before or after the copy. In this work, we examine the history, the state-of-the art, and possible future of mechanisms for copying large quantities of data via storage subsystem facilities for providing point-in-time (PiT) copies. The Storage Networking Industry Association (SNIA) defines a point-in-time copy as: A fully usable copy of a defined collection of data that contains an image of the data as it appeared at a single point-in-time. The copy is considered to have logically occurred at that point-in-time, but implementations may perform part or all of the copy at other times (e.g., via database log replay or rollback) as long as the result is a consistent copy of the data as it appeared at that point-in-time. Implementations may restrict point-in-time copies to be read-only or may permit subsequent writes to the copy. Three important classes of point-in-time copies are split mirror, changed block, and concurrent. Pointer remapping and copy on write are implementation techniques often used for the latter two classes. cf. snapshot [1] As hinted at by the above definition a range of point-in-time copy facilities exist. Some of these facilitie