ADSM-L

FW: Client DAS

1996-01-11 04:50:24
Subject: FW: Client DAS
From: "SVEN-OLOF KNAPASJ. TEL 67408" <vd.sok AT MEMO.VOLVO DOT SE>
Date: Thu, 11 Jan 1996 10:50:24 +0100
--- Received from VD.SOK  031-667408                96-01-11 10:49
  -> VD.LD                 LARS DANIELSSON   (0)31-667479 2510
  -> VD.LD                 LARS DANIELSSON   (0)31-667479 2510
I svaret finns det en del intressanta saker som var nytt fvr mig.
Kan det vara negot fvr oss tro? Fvr NetWare dr vdl negot som skall in?
                               H/Knapis



  -> IN=ADSM-L(a)VM.MARIST.EDU
Kevin Balmer puts forth:

========== Forwarded letter follows ==========
This is targeted at Novell servers but would apply for other platforms as
well.
I'm looking for feedback concerning logical volume size and configuration
of the
DASD for file placement.

The problem I'm running into is our Novell guys have kept adding to SYS and
 we
have some 18GB SYS volumes. I've recommended keeping just system data on a
SYS
volume and having multiple DATA and PROGRAM volumes no larger than 4GB each
 to
facilitate backup and recovery. Since ADSM locks at the filespace (logical
volume), multiple restores could be threaded in the event of a full server
restore. I'm meeting resistance to that suggestion. For Novell we average
about
800 MB/hour with ADSM and these 18GB servers take way too long for a
recovery
the way they're currently configured. How are others handling very large
single
volumes with ADSM?
========== Forwarded letter ends ==========

<insert $0.02 here> In general, I am of the opinion that before
implementing any kind of system, the ability to back it up and restore it
within the required time frames should be part of the planning.
Unfortunately storage management
issues, in general, are almost always overlooked when planning new systems.

I've run into problems doing multiple recoveries with ADSM; in particular
when both iterations of the ADSM NLM want to access data on the same tape,
whichever got their last has to wait for the first iteration to free it up.
 So
sometimes multiple recoveries aren't as efficient as they might seem (it
would be nice if ADSM could detect the tape volume is in use, go on to the
next tape, then go after the first tape later).

The foregoing notwithstanding, 18GB is huge for a single volume, even by
mainframe standards. So the idea of breaking it down to more workably-sized
 volumes makes some sense.

In the case where you have to be able to restore large volumes very
quickly, you might want to consider complementing ADSM with LANRES/MVS or
LANRES/VM (another IBM product). With LANRES, you can create NetWare disk
images out of
mainframe 3390 DASD. Assuming you channel-attach the NetWare server to the
mainframe, performance of the 3390 NetWare disk images is virtually
indistinguishable from "real" NetWare disks. But the advantage is that you
can use mainframe
utilities (i.e. DFSMS/dss) to back up and restore the NetWare disk images.
DFSMS/dss is a high-speed datamover that can back up and restore several
gigabytes of data in a matter of minutes (i.e. under an hour). So whereas
it might take
ADSM 5 hours to restore 2 GB of data (these numbers depend on your
installation), DFSMS/dss can do it in around 30 - 45 minutes.

Such a solution would not replace ADSM, but enhance it. The LANRES solution
 would give you fast full-volume recovery capability in the case of a
hardware failure. You'd still want to use ADSM for incremental backup and
restore, however.

Andy Raibeck
<Prev in Thread] Current Thread [Next in Thread>
  • FW: Client DAS, SVEN-OLOF KNAPASJ. TEL 67408 <=