[Info-vax] Real Usenet clients, was: Re: backups and compaction or nocompaction might be better

[Stephen Hoffman]

On 2013-02-02 14:22:55 +0000, Phillip Helbig---undress to reply said:

> In article <kej70u$i85$1 at dont-email.me>, Stephen Hoffman
> <seaohveh at hoffmanlabs.invalid> writes:
> 
>> The other question that should be asked when a particular feature is >
> being discussed is whether a different approach or different solution >
> can satisfy your more general requirements.  For instance, might a >
> completely automated, effective and transparent backup mechanism avoid >
> the requirements for RAID - whether software or hardware - various >
> installations?
> 
> Maybe.  Why do I have it?  To protect against disk failure and to keep
> data available if a node goes down (intentionally or not).  (At home, I
> don't have a multi-site cluster, though for some folks this is an
> additional reason to have HBVS as opposed to some other sort of RAID.)
> So, any solution would have to have some sort of raid to guard against
> disk failure and would also have to be accessible from all machines
> simultaneously.  Also, with SBB bricks, I can remove one and have a
> copy, for safe-keeping or for upgrading.

That's a series of VMS solutions aligned to your more general problems.

Yes, I'm familiar with why you're going through such hassles with the 
VMS and Alpha gear you're using, too.

Your general requirements are probably fairly typical of a low-end 
intermittant-use configuration.  You probably want to get the boxes 
back online fairly quickly, but you don't necessarily need to have 
continuous access, and you're operating with a low budget for hardware, 
and without a support contract or support staff.  With the pile of gear 
you have, probably a small or maybe medium business, with either 
in-house or custom applications.

But I'd expect you're probably willing to accept a way to get your data 
back on quickly and easily after a disk failure, either with a 
replacement disk or by rolling that data into a new box.   That HBVS 
isn't a central requirement.   Imagine, for instance, you could get 
incremental backups made hourly, and with no added effort on your part, 
and with an easy restoration path.  Would that be sufficient to avoid 
the need for HBVS?

The more general requirements then become items such as avoiding data 
loss, and around outages and potentially continuous uptime.  With 
uptime, there's also usually some determination of how much an outage 
can cost.  In your case, outages probably aren't at all costly, barring 
cases of complete data loss.

Why general requirements?  Because using specific requirements can be 
how a request for quotation (RFQ) is wired to a specific product and 
specific vendor.  You list off a series of unique features, and get 
what you want.  That doesn't mean that there are no alternatives, just 
that the RFQ was written to eliminate those.  It also doesn't mean 
you're getting the best deal for your {time, effort, budget} investment.

Consider that — given your current low-end configuration — you could 
probably scrounge a hardware RAID solution on your core host, and avoid 
the need for HBVS and related within the configuration.  Given you're 
currently getting clustering and HBVS "for free" for as long as there 
are free hobbyist licenses available, sure, use those products, too.  
But you're still making backups, since volume corruptions are volume 
corruptions, and bugs in VMS tools that delete system directories are 
still deletions, and you're probably not swapping a dozen disks through 
HBVS hourly or daily to get some depth to those backups, either...

With other platforms, you might well have far more automatic backups.   
That can mean having fewer disks around, and less hardware.   Even 
after you've gotten HBVS or a RAID controller paid for and configured, 
RAID still isn't ever a "freebie"; those extra disks are still going to 
fail, and the more disks you have, the more failure's you'll get, and 
the more power and space you'll need and use.

Put another way, a chunk of the specific requirements you're 
encountering here are because of the hardware and software limitations 
of the platform you've chosen.  OpenVMS is not geared for home use, it 
tends to be arcane to configure and manage, and it also tends to be 
cryptic.   OpenVMS has been targeted at features that hobbyist users 
and small businesses don't usually need, too.  Features that can 
involve FC SAN (or a multi-host SCSI configuration) and potentially 
rather more hardware than most hobbyists really want to run.  And 
OpenVMS is not aimed at features hobbyists might want, such as easier 
backups and restores, smaller boxes, commodity hardware, ease-of-use, 
and lower-power systems.

Can VMS be used here?  Sure.  But if you didn't have those free 
licenses and if you didn't have the time necessary to keep this stuff 
going, you probably wouldn't choose VMS.


-- 
Pure Personal Opinion | HoffmanLabs LLC