Re: ABC problem with disk

From: John Santos (john_at_egh.com)
Date: 05/28/05 

Date: Sat, 28 May 2005 06:26:20 GMT

David J Dachtera wrote:
> Joe Sewell wrote:
>
>>David J Dachtera wrote:
>>
>>>Joe Sewell wrote:
>>>
>>>>>Archive backup client, eh? Haven't heard of that since about 1998 or so.
>>>>>Not recommended then, either.
>>>>>
>>>>>Use VMS BACKUP to backup VMS disks, or risk losing your data and/or your
>>>>>ability to perform disaster recovery expediently.
>>>>
>>>>Not an option.
>>>
>>>Protecting your company's data by doing proper backups is not an option?
>>>
>>>That's *GOTTA* be a first!
>>
>>Oh, they do "proper backups" to the shared computer resources.
>
>
> If it's not VMS BACKUP, it's not "proper" (or "supported"). Your
> company's data is at risk.
>
> ...but don't take my word for it. contact your OpenVSM support channels
> and solicit their "official" position.
>
>
>>The
>>Alpha workstations used for development purposes, however, aren't as
>>important, it seems; the standard is what we find in the labs, where
>>the system disk is routinely INITIALIZEd for a VMS upgrade. (We're
>>talking about hundreds of machines, and nobody has the time to run
>>through the standard upgrade procedure.)
>
>
> The install and upgrade both take the same amount of time (unless
> someone is judging by an out-dated standard).
>
>
>>>>This was installed by the system administrator (not me).
>>>>The only reason I even noticed its existence on my machine is due to
>>>>some system slowdown that I tracked down to this thing chewing up about
>>>>5% CPU time in kernel mode.
>>>
>>>...and the reason management continues to tolerate this is ... ?
>>
>>... because "management" doesn't know about it. This is all under the
>>auspices of IT, which is under a separate sector, which makes
>>accountability more than a little difficult.
>>
>>But enough of this. ABC is what we're stuck with for now. Help, not
>>criticism of policies that are out of my hands, would be appreciated.
>
>
> Your data is at risk. Period - end of statement.
>
> If this ABC thing is malfunctioning, it hardly qualifies as either safe,
> proper or supported (by OpenVMS Engineering). If the vendor can't
> support it either, well, does the word "pray" mean anything to you?

"Not Supported" and "Not supported by HP" are two entirely distinct
concepts. Everyone is always complaining about lack of third party
software on VMS, and here you are saying "if it's not VMS Engineering,
it's gotta go!"

There are several different things called "ABC". The one I'm
familiar with is

$ abc
Archive Backup Client for ADSM on OpenVMS, Version V1.2-9
Copyright 1996-2000, Storage Solutions Specialists, Inc.

This is the VMS client for Tivoli Storage Manager (formerly IBM's
ADSTAR Distributed Storage Manager, aka ADSM.)

We use it at one customer site (mandated by their IT people).
Seems to work okay, given that we are pumping all the data through
a 10Mb VAX ethernet connection (half-duplex.) Performance was
sporadicly variable for a long time, but then they did some
tuning on the server side and since then things have been as
fast as we could reasonably expect.

It's an ancient version, but they are running VMS 7.1 ... ;-)

(Due to migrate to an Alpha cluster in a few months.)

They have a shadowed system disk, but if they ever need to do
a disaster recovery, they'll have to build a new temp system
disk, minimally with VMS, TCP/IP and ADSM, recover the system disk
backup to the new real system disk, and then restore everything
else. (They make the ABC equivalent of "BACKUP/IMAGE/IGNORE=INTERLOCK"
every few days at least, and we can manually fix anything that gets
dinged (queue manager files seem most likely, users don't get added
that often, so we can go back a few versions of SYSUAF, etc. if the
latest backup has a bad one.) Not ideal, but doable.

Our app is careful about backups and snapshots things with appropriate
context so the application and database backups are all clean.

I don't know if any of this is at all useful to the OP.

BTW, ABC's web site is at www.storserver.com. Look for "STORServer
Clients" in the menus. 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Quantcast