RE: Alternatives to Iron Mountain -- MIDRANGE-L

Why wouldn't you install the machine from the backup site tape?
--
Sean Porterfield
________________________________________
From: midrange-l-bounces@xxxxxxxxxxxx [midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx [rob@xxxxxxxxx]
Sent: Friday, October 02, 2009 17:46
To: Midrange Systems Technical Discussion
Subject: Re: Alternatives to Iron Mountain

Good point on the vendor keys and new hardware required. They're tough
machines but a fire enough to require a fail over, and damage the tapes,
will probably trash the machine.

Actually, should you have to touch routings or anything when you fail
over? Couldn't that be controlled by your DNS? For example,
GDISYS1, GDISYS2 are primary and HA. But everyone connects to GDISYS,
which the DNS controls. Flushing DNS cache and whatnot becomes a concern.
So maybe you do have to manipulate to really guarantee.

Yes, you have to keep ptf's at the same level, or reasonably close. But
again, if you try to install the new machine from DVD and not use any
tapes won't it take you quite some additional time to sync back up the
ptf's?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
BMay@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 05:30 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

I'm not saying that the HA software has to do it all, and this is not what

we use in our shop. Ours is actually even more complicated. And I'm not
an admin, just a highly involved developer.

As for the rest:

- IP Addresses, network attributes, routing: You were going to have to
touch this anyway when you failed over to your HA box, weren't you?
- WRKRDBDIRE: don't use it except for our actual HA software, but it
shouldn't it be part of your DR process to change these on the HA box if
you change your production machine?
- PTF's: Of course you have to keep both boxes at the same level.
- Vendor Keys: Yes, you will need keys, but if your machine is down and
your tapes that are in the fireproof safe are gone, I'm willing to bet you

had a pretty big disaster and will be replacing the whole machine anyway.
In which case you've been running on the DR box for a good while, so tapes

you sent to Iron Mountain or wherever are probably already too stale to be

used. So you were going to have to restore data from tapes taken at your
second location anyway.

I'm always intrigued by good discussions such as this. Don't take it as
picking an argument. Too bad we're not discussing it over a couple of
rounds of beer.

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi

Young i Professionals
http://www.youngiprofessionals.com

rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/02/2009 03:51 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Alternatives to Iron Mountain

The HA process does NOT keep both boxes identical. Think about it. Would

they have the same
- IP addresses
- Same system name
- same WRKRDBDIRE
- same network attributes
- same routing

They also will not have the same vendor keys. These are often tied into
serial number, processor and what not. Many times a vendor will have a
technote that says to omit data area x in library y from your HA software.

Do you really expect a change to WRKRDBDIRE on one system to be propagated

over to the other system? No. User profiles, user libraries and so on,
yes. I don't even expect a HA solution to keep DSPPTF in sync. How would

you expect it to?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
BMay@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 04:28 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

Rob, I think you are missing what he is saying. If your HA process keeps
both boxes IDENTICAL and you back both up to tape every night, there is no

need for offsite storage for either set of tapes because they are already
in separate locations and should be identical.

So if something happened to your tapes in your primary location, you would

have an identical set of tapes you could retrieve from the other location.

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi

Young i Professionals
http://www.youngiprofessionals.com

rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/02/2009 03:00 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Alternatives to Iron Mountain

Tell you what, you sound very confident of your HA process. Next time you

do a switch, do a full system backup of your primary machine. Then use
the I_BASE CD to format the disk drives. Then see if you can bring it
back without touching a backup tape. Are you game?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
rob@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 03:40 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

No, those do not have to be done regardless of HA or not. You can do a
complete system restore and get this done. However, if you have no backup

other than your HA machine you will miss vendor software keys,
configurations, ptfs, and a host of other data.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
Bryce Martin <BMartin@xxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 01:12 PM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

If you have a data backup at the HA site and a data backup at the
production site then you have offsite storage built into the plan,
correct? Its the same data and same libraries.

As far as loading up lic keys and PTF's... those have to be done
regardless of HA or not. So there is no gain by having offsite data tape
backups. That really has nothing to do with it. The fact is that don't
have to send tapes out to a seperate location if they are already being
backed up from the HA machine that is in another location. Unless both
facilities are in areas where the same natural disaster could wipe out
both place I would think you are ok. But in the vast majority of cases I
think it would be overkill.

Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777

rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/02/2009 12:31 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Alternatives to Iron Mountain

Actually on the early part (before discussing short comings of the HA
machine) let me throw another wrinkle into the mix, fire. Backup tapes
are destroyed from the primary machine. They weren't sent offsite.

Do you really think that after you have the lic and os loaded from DVD
it's really only an hour or two to get your PTF's up to snuff, license
keys, configuration, system values, edit codes, what not, HA config, and
then start replicating data?

I still think you need to store backups off site and relying on data
replication from your HA machine for everything is a mistake.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
Bryce Martin <BMartin@xxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
10/02/2009 11:40 AM
Subject:
Re: Alternatives to Iron Mountain
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

Yes the machine has an HA backup. Let me ask you this, if your primary
lost several drives (perhaps you were on vacation and no one else noticed
the errors piling up) how long would it take you to get it back up and
running? I bet I could get mine up and running in 24 hours. How long
would it take you?

-----Only as long as it takes to get drives in house and get everything
back in order.

- Have to order keys for machine: HA software, ERP software, barcode
software, and so on.

-----Already have SWMA with vendors. In disaster its as simple as a phone

call

- Have to reconfigure all the comm: Gee, who remembers how to configure a

Schowler route?
-----Comm is set up so it only takes a flush of the DNS to switch us to
the back up machine.

Meanwhile you're running on a machine you've only did swap tests on during

the occasional weekend, and while running live for a week you discover:
- There were several libraries that people thought were static and didn't
need HA replication. They were wrong.

-----All our production programs and data are replicated. Even user
libraries and our programming libraries.

- How come all the vendor fixes we put on the primary machine are not on
the HA machine?

-----Like I said, all production code and objects already synched.

- What clown thought we could do without certain applications during a
crisis and people should just "cowboy up" until the crisis is over?

-----That's why its not a true HA system if this is the case.

- Oh, and you really thought we could go from running on a 570-MMA to a
9408-M25 actually running more lpars and the users wouldn't start talking
about how the director of IS should now become a eunuch for letting
performance get this bad?

-----Your HA machine should ALWAYS be as big as your production, otherwise

what's the point? If your main facility burns to the ground and you need
to run on the HA box for a while then you'd be in bad shape. That is a
major mistake made by many HA implementors. They go cheap instead of
reliable.

- And the BOFH is pitching a fit about having to back up on a single
cartridge tape drive instead of a 6 drive tape loader capable of holding
over a 100 cartridges.

-----Why not have the redunant set up like production?

- Oh and that was a clever idea to offload query processing to our HA
machine. However now that the primary is down and the undersized HA
machine is not only running the primary load but also the query processing

the users are saying "them's that die are the lucky ones...".
-----Mistake.

If you aren't going to set up your HA disaster recovery plan to include
everything that you do in production its really not much of an HA disater
recovery plan. Its just a "little" better than your nightly backup
solution. Most of these issues shouldn't be issues if HA disaster
recovery is set up properly. Its not cheap or easy to test, that's why
you need to practice fail overs and roll overs a few times a year and have

people run production on the backup system to make sure all the pieces are

there.

just .02

Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
--- This message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and

exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--- This message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and

exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.