In <1994Dec1.224153.26286 AT draper DOT com>, MAINT%PUCC.BITNET AT vm.marist 
DOT edu (Melinda Varian) writes:
>I am very glad to see this discussion of backing up ADSM, as I have
>been struggling with this myself.
>
>Our goal is to be able to recover from a disaster that would destroy
>the building that contains the ADSM server.  We are willing to treat
>the clients that are not in this building as themselves being "offsite"
>backups of their ADSM data, except for their archive data.  All archive
>data, all current data for clients in this building, and all server
>information required to get the server going again must be backed up
>and moved offsite on a regular basis.
>
>Does anybody see any holes in this plan:
>
>1.  On Monday through Friday mornings, do a DUMP DB; move those tapes
>    offsite during the day.
>
If you say 'consistent=yes', the server will be internally quiesced
and unavailable to your users.  But you should say 'consistent=yes' to
avoid an audit after the reload.  Audit is a DOG, as in St. Bernard.
>
>2.  On Monday through Friday mornings, do an EXPORT NODE FILEDATA=
>    ARCHIVE for all nodes; move those tapes offsite during the day.
>
>3.  On Saturday/Sunday do an EXPORT NODE FILEDATA=BACKUP for all nodes
>    in the domain defined for nodes in this building; move those tapes
>    offsite on Monday.
>
Export runs forever.  I estimate the elapsed time for 8.3m entries to
be in months.  Also it uses free database pages as a sort work area,
so to do your whole database you must start with a database less than
50% full.  Export does a sort so that it can read tapes in order.
But is a very poor sort algorithm.  If you double the sort input you
quadruple the time.
>
>The hope then would be that restoring all those tapes would get us to
>the point where all clients would be registered, but the ones not in
>this building would all need to do full incremental backups the first
>time they connected to the server.
>
>One question I have is whether there is any advantage to doing an
>EXPORT SERVER rather than an EXPORT NODE for the daily backup of the
>archive data?
>
>I was also somewhat surprised by Greg's suggestion 2:
>
>> 2. use existing backup utilities to backup online storage pool
>> volumes and tape copy tape stg pool volumes.  This works fine for
>> the disk volumes but is extremely cumbersome for the tape volumes.
>> Mgt of the copies and recovery will be challenging.
>
>I had been assuming that simply copying the storage pool tapes and
>disks would produce an inconsistent enough copy of the data that it
>would not be of much use.  Is there any point in, for example, making
>DDR copies of the storage pool disks while the server is running?
>
>I was also interested in Greg's comment that export runs extremely
>slowly for large amounts of server data.  We currently have 225 clients
>and 8,340,000 database entries.  We are expecting those numbers to grow
>a lot (probably ten-fold).  Would I be wiser to break the load up into
>separate ADSM servers, e.g., one for clients in this building and one
>for others?  (Many of the largest clients are here.)
>
>Melinda Varian,
>Princeton University

I take the server down twice a week and dump the server volumes and
disk bitfiles to tape (MVS server, FDR dump program, 5.0 million DB
entries, 20 3380k volumes, under 2hr elapsed time).  Tape bitfiles
are copied whenever a tape is written.

I have used the Database and disk bitfiles to do a full restore and it
worked like a charm.  Since no tapes had been written in the interval
between the dump and the restore, everything was consistent.

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550