CA2071346A1 - Method and means for time zero backup copy of data - Google Patents

Abstract

METHOD AND MEANS FOR TIME ZERO BACKUP COPYING OF DATA

Abstract of the Disclosure Backup copying of designated datasets representing point in time consistency may be performed in a CPU on an DASD storage subsystem concurrent with CPU application execution by suspending execution only long enough to form a a logical to physical address concordance and thereafter physically backing up the datasets on the storage subsystem on a scheduled or opportunistic basis. Application initiated updates to the uncopied designated datasets are first buffered, sidefiles made of the affected datasets, the updates written through to the storage subsystem, and the sidefiles written to storage in backup copy order as controlled by the concordance.

Description

2~7~3~

METHOD AND ME~NS FOR TINE ZERO BACKUP COPYING OF DATA

Field o~ the Invention This invention re].ates t.o maintaining continued avai.labillty of datasets in external storage to accessing computer ~ystems (CPU). More particularly, it relates to backup copying of records in external storage concurrent with a dramatically shortened suspension of CPU application execution occasioned by said copying.

Description of Related Art A data processing system must be prepared to recover, not only from corruptions of stored data such as to noise bursts, software bugs9 media defects, and write path errors, but from global events such as CPU power failure. The most common technique to ensure continued availability of data is to make one or more copies of CP~ datasets and put them in a safe place. This "backup" process occurs within contexts of storage systems of increasing function.

Applications have executed on CPU s in either a batch (streamed) or interactive (transactional) mode. In batch mode, usually one application at a time executes without interruption. Interactive mode is characterized by interrupt driven multiplicity of applications or transactions.
, Backup policies are policies of scheduling. They have a space and a time dimension e~emplified by a range of datasets and by frequency of occurrence. A FULL backup imports copying the entire range whether updated or not. An INCREMENTAL backup copies only that portion of the dataset that has changed since the last backup (either full or incremental). The backup copy represents a consistent view of the data as of the time the copy or snap-shot was made.

The higher the backup fre~uency, the closer -the backup copy mirrors the current copy of the data. Considering the large volumes of data, backing up is not a trivial maintenance operation. Thus, the opportuni-ty cost of backing 3 ~ ~

up can be high on a large multiprocessing, multiprogramming facility relative to other processing.

The Backup Window and Effect Upon Batch and Transactional Processing When a CPU backs up data in a streamed or batch mode system, ever~ process, task, or application listens. By this it is meant that pxocesses supporting streamed or batch mode operatio~s are suspended for the duration of the copying.
The coined term for this event is "backup window". In contrast to batch mode, log based or transaction management applications are processed in the interactive mode. They practically eliminate the "backup window" by concurrently updatiny an on- line dataset and logging the change.
However, the latter is a form of backup copying whose consistency is "fuzzy". That is, it is not a snapshot of the state of a dataset/database at a single point in time.
Rather, a log is an event file requiring further processing against said database.

~ s mentioned above, to establish a prior point of consistency in a log based system, it is necessary to "repeat history" by replaying the log from the last checkpoint over the datasets or database of interest. The distinction between batch mode and log based backup is that the backup copy is consistent and speaks as of the time of its last recordation, whereas the log and database require further processing in the event of fault in order to exhibit po~nt in time consistency.
', ~awlick et al, US Pat. 4,507,751, "Method and Apparatus ~. ~
~ for Logging Journal Data Using a Write Ahead Dataset", -~ issued 3/26/19~5 exemplifies a transaction management system where all transactions are recorded on a log on a write-ahead- dataset basis. In this patent, a unit of work is first recorded on the backup medium (log) and then written to its external storage address.

Summary of the Invention It is an object of this invention to devise a method and means for consistent backup copying of records to external storage, and that such copying be concurrent with a drastically shortened suspension of CPU application execution occasioned by said copying.

It is a related object to devise a backup copying method and means susceptible of supporting full, incremental, or mixed backup scheduling policies.

The above objects are satisfied by a method and means that rely upon mapping data to be copied onto the backup copy medium atomically and using sidefiles for buffering any data subset affected by a concurrent update. This allows updates to be concurrently written through to external storage while preserving both the consistency and copyback order.

The method of the invention is implemented by backup copying designated datasets in a uniquely identified session. Each session includes session registration and initialization and concurrent copying of the state of the designated datasets as of a predetermined time (tO) while writing through all updates after tO to the external store.
The method includes the steps of (1) writing sidefiles of the affected uncopied portion of the dataset, (2) updatiny the original data in place on said external store, and (3) copying the sidefiles to the medium in backup copy order.

Advantageously, the integrity of the copied dataset is maintained while the period of process suspension is nearly eliminated. Also unlike the aformentioned Anglin reference, the method and means of this invention is directed to a new use of sidefile generation. That is, the difference resides in the use of generation of sidefiles of the uncopied portion of a dataset where the sidefile use facilitates both backing up datasets in ordinary copy order and overlapping of backing up and updating.

Brief Description of the Drawing 2 ~

Figure 1 exhibits a typical mul-ti-processing multi-programming environment according to the prior art where executing processes and applications randomly or se~uentially access data .~rom external storage.

Figure 2 shows a timeline depictiorl of the backup window among batch or streaming processes according to the prior art.

Figure 3 depicts the near elimination of the backup window as a consequence of the method and means of the invention.

Figure 4 sets forth a conceptual flow of the tO backup copy method of the invention.

` Figures 5 and 6 represents the control flow at the externalstorage control and the CPU operating system levels respectively.

~` Description o:E the Preferred Embodiment Illustrative CPU Environment for Executing the Method of the Invention The invention can be conveniently practiced in a configuration in which each CPU in a system may be of an IBM/360 or 370 architected CPU type having as an example an IBM MVS operating system. An IBM/360 architected CPU is fully described in Amdahl et al, USP 3,400,~71~ "Data Processing System", issued on September 3, 1968. A
configuration involving CPU s sharing access to external storage is set forth in Luiz et al! USP 4!207!609! "Path Independent Device Reservation and Reconnection in a Multi-CPU and Shared Device Access System" ! issued June 10 1980.
An MVS operating system is also described in IBM
publication GC28-1150! "MVS/Extended Architecture System Programming Library: System Macros and Facilities" ! Volume 1. Details of standard MVS or other operating system services such as local loc~ mana~ement! sub-system invocation by interrupt or monitor! and the posting and ~7~

waiting of tasks is omitted. These OS services are believed well appreciated by those skilled in the art.

Path to Data, Batch and Int~ractive Modes, and Backup Copying Referring now to fig~lre 1, there is depicted a multi-processing, multiprogramming system according to the prior art. Such systems including a plurality of processors (1,3) accessing external storage (21,23,25,27,29) over redundant channel demand/response interfaces (5,7,93. ~s described in Luiz et al, a CPU process establishes a path to externally stored data in an IBM System 370 and the like through an MVS
or other operating system by invoking a START I/O, transferring control to a channel subsystem which reserves a path to the data over which transfers are made. Typically, applications have data dependences and may briefly suspend operations until a fetch or update is completed. During the transfer, the path is locked until the transfer is completed.

Reerring now to figure 2, there is shown a timeline depiction of the backup window among batch or streaming processes according to the prior art. That is, at a time just prior to backup, applications are suspended or shut down. The suspension persists until the bac~up process is completed. Backup termination signifies completion and commitment.~By completion i-t is meant that all the data that was to have been copied was in fact read from the source. By commitment it is meant that all the data to be copied was in fact written to the output media.

Separating Logical Completion from Physical Comple-tion Referring now to fi~ure 3, there is depicted the near elimination of the backup window as a consequence of the method and means of the invention. Once the backup method of the invention (tO copy) process starts, the data (as far as the copy is concerned) is "frozen" at that point in time. At that point in time, the copy is said to be "Logically 3 ~ ~

Complete". The committed state, or "Physically Complete"
state will not occur until later~
At the "Iogically Complete" point in time, the data is completely usable again by the applications. The time from when the t0 bac}cup is lssued and the data being available a~ain is in the low sub-second`range. In other words, the total application data outage (backup window) can be measured in milliseconds. Abnormal Termination ;

I~ the t0 backup process abnormally terminates between the point of logical completion and the point of physical completion, then the backup copy is useless and the process needs to be restarted. In this respect the method and means of the invention is vulnerable in a manner similar to the prior art. That is, all backup must be rerun. One limitation is that is that the time criticality of the snapshot is lost.
.', Conceptual Aspects :..
Referring now to figures 4 and 5, there is set forth a ` conceptual flow of the method of the invention. It should be noted that each backup session is assigned a unique session identification (ID) and comprises an initialization and a backup processing component. While multiple backup sessions may be run concurrently, each session ID and whence "snapshot" is unique.

Each CPU includes an operating system having a storage manager component. Typically, an IBM System 370 type CPU
running under the MVS operating system would include a storage manager of the data acilities data set services (DFDSS) type as described in Ferro et al, U.S.Pat.

4,855,907, issued Aug. 8, 1989, "Method for Moving VSAM Base Clusters While Maintaining Alternate Indices into the Cluster". DFDSS is also described in the IBM publication GC26-4388, "Data Facility Data Set Services: User s Guide".

Data is logically organized into records and datasets.
The real address of the data in external storage is in terms of DASDs volumes, tracks, and cylinders. The virtual address SA9-91-017 7 2 ~ 7 ~

of the same is couched in terms of base addresses + offsets and /or extents.

A record may be of the count-key-data format. It may occupy one or more units of real storage. A dataset as a logical collection of multiple records may be stored on contiguous units of real storage or may be dispersed. It follows that if backup proceeds on the dataset level then, it is necessary to perform multiple sorts to form inverted indices into real storage.

For purposes of this invention, backup processing is managed at two levels, namely, at the CPU OS resource manager level (fig.l - 1, 3) and at the storage control unit level (fig.~ - 21, 23).

Initialization Referring again to figures 4 and 5, the initialization process comprises three broad steps responsive to a resource manager (e.g.DFDSS) receiving a request to copy or backup particular data. These steps include sorting datasets, building one or more bit maps, and signalling logical completion to an invoking process at the CPU. The listed or identified datasets are sorted according to the access path elements down to DASD track granularity. Next, bit maps are constructed which correlate the data set and the access path insofar as any one of them is included or excluded from a given copy session. Lastly, the resource manager signals logical completion meaning that updates will be processed against the dataset after only a short delay.

More particularly, the resource manager for storage ~DFDSS) receives a request to copy or hackup up data.
Normally, this request is in the form of a list of data sets or a filtered list of data sets. DFDSS maps the request into a list of physical extents by DASD storage volume and by storage control unit (SCU). Next, DFDSS registers the request with each par-ticipating SCU. At this point, the session ID is determined and the session is established.

~r~ ~3~$

It should be appreciated that DFDSS initializes the session with each SCU by passing all the extents being copied for each volume for each SCU. Each SCU will then build a bltmap for each volume participating in the session.
This bitmap wil.l indicate which tracks are part of the tO
copy session. Control .is returned to DFDSS. This is the "Logically Complete" po.l.nt at which the data is again available or use. DFDSS notifies the operating system component such as a scheduler in sys-tem managed storage accordingly.

Backup Processing Following initialization, DFDSS begins reading the tracks requested. While the t0 copy session is active, each SCU monitors all updates. If an update is received, the SCU
executes a predetermined algorithm which takes the update ` into account.

` If the update is for a volume NOT in the t0 session, then the update completes normally. On the other hand, if the update is on a volume that is part of the session, then the bitmap is checked to see if that t.rack is protected. If the bit is off (assume this imports a binary 0), it indicates the track is not currently in the copy session and the update completes normally. Slgnificantly, if the track is protected (bit is on) it indicates the track is part of a the copy session and it has not as yet been read by DFDSS.
In this case, the SCU

(1) Holds the update.

(2) Stages the track from the device into a separate cache partition (This track contains the data as it existed at the point in time the t0 backup process started).

(3) Allows the update to continue.

2 ~ ~ ~ 3 ~

(4) If any tracks are contained in a separate cache partition~ DFDSS prompt].y reads those tracks to minimize the effect of normal cache operations.

~ eerring again to fi~ure 4s the steps of the method are depicted. In this i~ure, the updates to tracks 4 and 7 cause the unchanged -tracks to be staged into the separate cache partition prio~ to the update completing. DFDSS
subsequently reads the tracks from the separate cache partition. Trac}~s read by DFDSS -that are not yet ready to be merged onto the output media are temporarily stored in a host side.~ile.

Attention processing is used to ensure that separate cache partitions do not consume inordinate amounts of cache.
When an attention is surfaced to the host, the operating system notifies a DFDSS task which then empties the separate cache partition.

In figure 4, random application updates of the data copied by tO copy process occur at "A". The original images of these tracks are copied into the separate cache partition. DFDSS reads unchanged tracks from the DASD device at "B". If any track has been changed after the tO process started, they are not returned to DFDSS. When tracks are moved at "C" into the separate cache partition as a result of updates, a threshold attention interrupt is surfaced to the host. These interrupts are serviced by the operating system. The operating system issues the appropriate command to the SCU to obtain the reason for the interrupt. If the interrupt is for a specific tO process, that indicatiGn is passed onto DFDSS.

Once DFDSS receives the interrupt, it begins emptyin~
the tracks that had accumulated in the separate cache partition. Any tracks read that are not y0t ready to be placed onto the output media are considered "out of sequence" and are stored temporarily in a host-memory sidefile.

~7~ J

As a last measure, data ls read directly rom the DASD
device and data stored in the host sidefile are ultimately merged onto the ou-tput media in the proper sequence at step "D".

Illustrative Example Reerring again to figures 4 and 5, assume that a process invoking the tO process desires to backup copy the datasets stored on 100 predetermined DASD tracks. If none of those tracks are changed during the copy process, DFDSS
could simply read tracks 1-100 and place them on the output media. In order to permit concurrent updating of external store while backup copying, it must also be assumed that data stored on one or more of the predetermined tracks has a reasonable expectation of being altered.

Give~ that. the process has already begun and that DFDSS
has already copied tracks 1-20. This means it has yet to copy tracks 21-100. If an application or process tries to change track 7, that would be allowed to complete "as usual"
since track 7 has already been copied. If, however, an attempt was made to change track 44, that change could not complete "as usual" since track 44 has not yet been copied.
It is necessary to ensure that track 44 is preserved in its original state for the copy. So prior to updating an uncopied track, a temporary copy of track 44 is retained in a sidefile before the change is allowed -to complete. This temporary copy of txack 44 is located in a separate cache partition for subse~uent retrieval by DFDSS. DFDSS retrieves this track and, at the proper time, places track 44 on the output media.

The backup process ca~lses DFDSS to obtain data stored on predetermined tracks from two sources:

~1) Tracks read directly from DASD. These are tracks that have not been changed (by an application) after the tO copy process began.

~r~

(2) Tracks read from the cache partition. These are the original images of tracks that have been changed after the tO process began.

Si~ce one objective is to minimize the impac-t on normal cache operations, as soon as tracks are read into the separate cache partition then they are available to be read by DFDSS.

Detail Logic Flow of Backup Processing Referring now to figures 5 and 6, there are shown several flow diagrams. Figure 5 covers initialization and SCU backup processing while figure 6 depicts CPU OS
processing o~ sidefiles (asynch processing) and CPU OS
managemen~ of copy session data transfers (synchronous processing) from the SCU to the output medium. These presentations are supplemented in this section by more detailed ~low of control listings for purposes of completeness. These listings are a many -to one mapping to the ~low diagrams depicted in figures 5 and 6.

Initialization Flow Listing The i~itialization process starts wi~h the CPU
operating s~stem (OS) receiving a request to backup or copy some amount of data. This re~uest is processed acco~ding to the following logic:

1. BUILD LIST OF DATA SETS TO BE BACKED UP.
.
~. SORT LIST OF D~TA SETS BY THE DASD VOLUMES THAT THEY
RESIDE ON.

3. FIND OUT WHICH VOLUMES BELONG TO WHICH SCUs.

4. NOTIFY EACH SCU IN THE SESSION AND ESTABLISH A

5. FOR EACH VOLUME ON EACH SCU, NOTIFY WHICH TRACKS ARE
PART OF THE TO COPY SESSION.

., SA9-91-017 12 2 ~ 4 ~
.
A. THE SCU THEN BUILDS A BIT MAP FOR EACH VOLUME
IN THE SESSION

B. IN THE BIT MAP, A "0" INDICATES THAT TRACK IS
NOT PART OF THE T0 COPY SESSION. A "1" INDICATES
THAT CORRESPONDING TRACK IS PART OF THE TO COPY
SESSION.

6. CPU OS RETURNS AN INDICATION TO THE INVOKING PROCESS
THAT THE "LOGICAL COMPLETE" POINT HAS BEEN REACHED AND
THAT THE APPLICATION IS FREE TO USE THE DATA AGAIN.

SCU Flow Listing This phase includes two processes being performed simultaneously, one by the SCU and one by the CPU Operating System. SCU

1. FOR EVERY UPDATE TE~AT OCCURS, A CHECK IS MADE TO SEE

COPY SESSION.

2. IF THE ANSWER TO ~1 IS NO, THE UPDATE COMPLETES
NORMALLY.

3. IF THE ANSWER TO #l IS YES, A CHECK IS MADE AGAINST
rrHE CORRESPONDING BITMAP TO SEE IF THE UPDATE IS TO A
TRACK THAT IS PART OF THE T0 COPY SESSION.

4. IF THE ANSWER TO #3 IS NO, THE UPDATE COMPLETES
NORMALLY.

5. IF THE ANSWER TO #3 IS YES, THE FOLLOWING STEPS TAKE
PLACE:

A. THE UPDATE IS TEMPORARILY HELD

B. THE TRACK THAT IS ABOUT TO BE UPDATED IS COPIED
INTO A SIDEFILE AREA IN THE SCU CACHE.

C. THE UPDATE IS ALLOWED TO COMPLETE

D. THE BITMAP ENTRY FOR THAT TRACK IS TURNED OFF
INDICATING THAT THE TRACK IS NO LONGER PART OF THE
T0 COPY SESSION. FUTURE UPDATES, THEREFORE ARE NOT
IMPACTED.

E. CHECK IF THE NUMBER OF TRACKS CURRENTLY
CONTAINED IN THE SIDEFILE E.XCEED A PREDEFINED
THRESHOL,D

(1) IF IT DOES NOT EXCEED THE THRESHOLD, CONTINUE

(2) IF IT DOES EXCEED THE THRESHOI.D, SURFACE
AN ATTENTION TO THE CPU OS INDICATING THAT
THE SIDEFILE MUST BE READ (EMPTIED) IMMEDIATELY.

6. ANY READS (FROM DASD) WHICH OCCUR ONLY FROM THE TO
COPY PROCESS IN CPU OS RESULT IN THE FOLLOWING STEPS
BEING TAKEN:

A. THE DATA TRACKS REQUESTED ARE TRANSFERRED TO
THE CPU OS TO COPY PROCESS.

B. THE CORRESPONDING BIT IN THE BITMAP IS TURNED
OFF INDICATING THAT THE TRACK IS NO LONGER PART OF

CONCERNED.

7. WHEN ALL THE BITS IN ALL THE BITMAPS IN A SCU
:(BELONGING TO A SINGLE SESSION) ARE TURNED OFF, THAT
SESSION HAS ESSENTIALLY COMPLETED FOR THAT SCU.

CPU OS Flow Listing :~ The CPU OS flow consists of an asynchronous process and a synchronous process.

ASYNCHRONOUS PROCESS

SA9-91-017 14 ~ 7 ~ 3 ~ ~

1. LISTEN FOR AN ATTENTION (any "signal" sent from an SCU to the CPU OS indicative of the occurrence of a predefined event~.

2. WHEN ATTENTION OCCURS ON A SCU, START READING DATA
FROM THE SCU SIDEFILE UNTIL THAT SIDEFILE IS EMPTY.

3. EACH TRACK READ FROM THE SIDEFILE IS AN "OUT OF
SEQUENCE" TRACK AND IS STORED IN A HOST WORKFILE UNTIL
IT IS READY TO BE PUT ONTO THE OUTPUT MEDIUM.

4. GOTO #l SYNCHRONOUS PROCESS

Recall that the t0 Copy process starts reading the data track~ in a designated order.

1. THE T0 COPY PROCESS DETERMINES WHICH TRACKS ARE TO
BE READ IN A SINGLE I/O REQUEST

2. THE HOST WORKFILE IS QUERIED TO SEE IF ANY OF THE
TRACKS TO BE READ ARE ALREADY IN THE WORKFILE

A. IF THE ANSWER TO #2 IS NO, THE TRACK IS STILL
ASSUMED TO EXIST ON THE DASD DEVICE IN AN
UNCHANGED STATE

B. IF THE ANSWER TO #2 IS YES, THE READ COMMAND IS
ALTERED SO AS TO AVOID READING A TRACK ALREADY
READ. THAT IS, THE TRACK HAD BEEN PREVIOUSLY
UPDATED AND THE ORIGINAL TRACK WAS STAGED INTO THE
SIDEFILE AND SUBSEQUENTI.Y MOVED TO THE HOST
WORKFILE

3. THE SESSION READ IS ISSUED FOR SOME NUMBER OF TRACKS

:
A. IF THE SCU INDICATES A SESSION READ WAS
ATTEMPTED ON A TRACK NOT CURRENTLY IN THE SESSION, CPU OS ASSUMES THE TRACK RESIDES IN THE SCU

SA9-91-017 15 ~7~34~

SIDEFILE OR THE HOST WORKFILE AND THE TRACK IS
RECOVERED FROM THERE.

4. DATA OBTAINED FROM #3 IS WRITTEN ONTO THE OUTPUT
MEDIUM AFTER BEING MERGED WITH ANY DATA TRACKS OBTAINED
FROM STEP ~2B

5. IF THERE ~RE MORE TRACRS TO READ, GOTO #l 6. ELSE, WHEN ALL TRACKS HAVE BEEN READ AND WRITTEN TO
THE OUTPUT MEDIUM:

A. TERMINATE THE SESSION WITH ALL PARTICIPATING
SCUS

B. RETURN A "PHYSICAL COMPLETE" SIGNAL TO THE
INVOKING PROCESS. THIS INDICATES THAT THE DATA TO
BE BACKED UP HAS IN FACT BEEN WRITTEN TO THE
OUTPUT MEDIUM

Extensions Although the invention has been described within the context of an IBM~ MVS operating system, it may likewise be practiced within any commercially available general purpos~
operating system such as VM, OS/2~ and the like. Also, although DFDSS has been identified as an illustrative external storage resource manager, the invention i8 operable with any equivalent manager without undue experimentation by the ordinary skilled artisan.

These and other extensions of the invention may be made without departing from the spirit and scope thereof as recited in the appended claims.

Claims (8)

1. A CPU implemented method for backup copying of designated datasets representing point in time data consistency on an storage subsystem attaching said CPU, said backup copying being concurrent with CPU application execution, comprising the steps of:

(a) suspending application execution and forming a dataset logical-to-physical storage subsystem address concordance, and resuming application execution thereafter;

(b) physically backing up the designated datasets on the storage subsystem on a scheduled or opportunistic basis by causing them to be copied from the storage subsystem to the CPU and by the CPU writing them to other storage subsystem locations; and (c) processing at the storage subsystem any application initiated updates to the uncopied designated datasets by buffering said updates, writing sidefiles of the datasets or portions thereof affected by the updates, writing the updates through to the storage subsystem, and copying the sidefiles to the CPU and at the CPU writing the designated datasets to storage in backup copy order defined by the by the concordance in the manner of step (b).

2. A CPU implemented method for minimizing the suspension of operations against datasets located on an external store attaching a CPU while said data sets are subject to backup copying, comprising the steps of:

(a) atomically copying a predetermined dataset extent from a first to a second range of locations on said external store so as to creating a backup copy on said second range;
and (b) processing any concurrent updates against any uncopied portion of the predetermined dataset extent located on the first range by (1) writing the uncopied portion affected by the updates to side files, (2) processing the updates over the first range of locations, and (3) copying the sidefiles to the second range in ordinary backup copy order.

3. The method according to claim 2, wherein said method further comprises the step of (c) processing updates to the dataset extent in the first range unexceptionally if the update affects that portion of the dataset extent already copied.

4. A method for managing backup copying of datasets concurrent with application execution on a CPU
communicatively coupling an external subsystem of tracked cyclic storage devices over at least one defined access path, comprising the steps of:

(a) suspending application execution at said CPU and designating at least one dataset for backup copying and requesting a copy of said designated datasets from the storage subsystem;

(b) forming dataset and device track concordances at the storage subsystem and signalling the CPU of the logical completion of backup copying;

(c) resuming application execution at said CPU responsive to said logical completion signal;

(d) copying designated datasets from the storage subsystem to the CPU on a scheduled or opportunistic basis;

(e) processing any application updates to datasets within the storage subsystem by writing them through unless they are addressed to a portion of a designated dataset uncopied to the CPU, otherwise, buffering the update, writing a sidefile of the uncopied portion of the designated dataset, then writing the update through, and copying the sidefile to the CPU; and (f) writing accumulated designated datasets and sidefiles by the CPU to other storage subsystem locations asynchronous to steps (d) and (e) in copy order.

5. The method according to claim 4, wherein the concordances of dataset and track locations are manifest in the form of bit maps in which the uncopied designated datasets are attributed a first Boolean value while copied and undesignated datasets are attributed a second Boolean value;
and wherein each time a designated dataset as represented by its device track contents is copied to the CPU, the step of changing the counterpart bitmap attribute from a first to a second Boolean value.

6. The method according to claim 4, wherein the method further comprises the step of:

(g) signalling physical completion of backup copying only when all of the designated datasets and sidefiles have been written to said other storage subsystem locations.

7. The method according to claim 4, wherein step (e) may be modified such that sidefiles are accumulated at the storage subsystem and copied to the CPU only upon the occurrence of a threshhold number.

8. In a system formed from a CPU referencing datasets or portions thereof from locations in an external subsystem of tracked cyclic storage devices attaching said CPU, wherein the improvement comprises:

(a) means for atomically copying a predetermined dataset extent from a first to a second range of locations (backup copy) on said external storage subsystem; and (b) means for processing any concurrent updates against any uncopied portion of the predetermined dataset extent located on the first range by (1) writing the uncopied portion affected by the updates to side files, (2) processing the updates over the first range of locations, and (3) copying the sidefiles to the second range in ordinary backup copy order.