× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Let me say that every company will have different levels of DR and different
levels of acceptable risk & downtime. I'd add that within each company
those levels will differ from app to app and may differ given the time of
year. For instance an accounting company may be able to take a big hit in
July when things are relatively quiet but not so much during December &
January when they're closing the books & issuing employee tax forms with
legal deadlines.

We put apps in different tiers. Tier 1 apps have BC/DR criteria that are
more stringent than Tier 2 and Tier 3 apps. To keep app owners from just
saying everything is Tier 1, they know that higher Tiers have higher costs
associated with the services.

For our midrange environment we run 2 iSeries in geographically separated
data centers. There's a gigabit WAN connection between them and we use
MIMIX ha Lite for more-or-less real-time replication. If there's an outage,
cutover isn't instant as we will manually make the decision to execute based
on the nature of the outage. Downtime is minimal, though, and more
important there's very little chance of actual data loss occurring. My
employer is more concerned with data integrity than 100% availability.
Availability is something you'll have eventually, but if the integrity is
shot then there can be disastrous consequences for the firm and our clients.

For our Windows environments it varies all over the place. Some Tier 1 apps
use the SAN for storage and the SAN is replicated between data centers; BCDR
involves duplicate hardware and the ability to bring up systems (virtual
machines) in the DR data center as needed.

For Tier 2 apps, a tape-based recovery within 1-2 days is more likely
sufficient. Redundant hardware is available but not necessarily of the same
specs available in production; i.e. it may run but more slowly. For Tier 3
apps, they are generally non-critical and may not be recovered for days or
even weeks. No redundant hardware capacity will exist; it will be procured
if needed.

Another thing we do is balance the workload between the data centers;
there's no "production" and "DR" data centers; each is production for some
apps and DR for the others. By doing that, in a disaster scenario you don't
have to recover everything; just the portion of your app portfolio that was
served from the data center that went kaboom.

On Thu, Sep 16, 2010 at 9:50 AM, John Candidi
<jacandidi@xxxxxxxxxxxxxxxxx>wrote:

Throwing out a broad question here but just looking for some feedback. What
does you company do for disaster recovery keeping in mind that downtime
should be minimal to none and also that we are talking about not only the
Iseries but additional servers as well . Do you have your systems hosted
offsite with redundant hardware? Do you have a system in house with
redundant hardware offsite? Any of the other myriad of possibilities? I'm
just trying to get a high level view for the different solutions that are
out there.

John A. Candidi
American European Insurance Group
IT Systems, Application and Support Manager
Cell (609-922-3108)
Office (856-779-2274)
jacandidi@xxxxxxxxxxxxxxxxx




--
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.