the archive business.
Continuity of operations (COOP) is a Corps policy requiring the District to continue to
pursue its mission despite unforeseen events, which may go so far as to render its office
space and computers, including onsite backups, unusable. A near miss by hurricanes Ber-
tha and Fran during the 1996 hurricane season brought this possibility to the fore. COOP
depends on off-site storage of essential backup data, as well as the possibility of finding
a compatible computing plant to employ the stored data. Not long ago (1990), this meant
sending a set of full monthly or quarterly backup tapes to Savannah District and receiving
the same from them. The networked, distributed, heterogeneous computing environment
we have migrated to since then has complicated any potential COOP solution. The soft-
ware we use now (COTS) cannot generally be restored from backup, but must be installed
where it is used. A variety of servers--Unix, NT, Novell--must be supplied to provide
for system support and applications, and these vary widely from District to District. A
bewildering variety of networking paraphernalia is required to establish the LAN and
WAN connectivity we can no longer live without. These are difficult problems affecting
the computing plant portion of the COOP equation. Of interest here is what COOP has in
common with data management and archiving: the requirement for a secure, structured,
catalogued, and documented collection of the data needed to get on with business.
The following is a draft of a plan to implement such a collection applied to the online
digital geospatial data holdings of the Jacksonville District.
Data management for GD&S: The goal
The goal of GD&S data management is to identify, collect, organize, document, pre-
serve, and make accessible the District's spatial data.
1. In consultation with project managers and technical staff, the GD&S committee,
and possibly others, identify the locally developed spatial data (and related techni-
cal, scientific, and engineering data, if any) central to the District's projects.
2. Collect that data, as much as possible, on one of the District's GD&S servers.
3. Organize the data to maximize their utility and availability to the project team pri-
marily, but also to facilitate their discovery and use by others. Intuitive file names
and directory structures are important. Consultation with CADD and GIS staff will
be necessary to preserve (or migrate in an orderly fashion) existing applications.
4. Produce, or otherwise obtain, FGDC-compliant metadata to document the col-
lected and organized datasets, and post this to the USACE node of the NSDI. Main-
tain an online catalog to facilitate local access to this data.
5. Make offline archival copies of these data and their documentation so they are pre-
served for disaster recovery or for duplication and use by others. Arrange with IMO
for a suitable backup schedule for the online data and a rewriting schedule for the
archived data.
6. Respond to requests for data from the public and other agencies. Make data and
its documentation accessible via Web-indexed files on the public FTP site (where
that is appropriate), by providing the data on tape or CD-ROM, or by referring the
requestor to the proponent or OC, if necessary.
Data management for GD&S: The plan
The primary unit of data management will be the volume. A volume consists of related
datasets, exclusively occupying a compact disk store, along with their documentation,
symbol sets, saved views, extensions, macros, and other programs operating on them.
All these objects will be contained in a single subtree of the operating system directory
structure. Thus they can be archived to a minimal saveset and restored with minimal loss
of functionality due to dependence on other savesets. Each volume will be indexed by
a "catalog" consisting of a brief description of each dataset and containing a pointer to
detailed metadata for that dataset.
35
35
Previous Page
