RE: Doing remote journals to the cloud -- MIDRANGE-L

I was talking about dual receivers. One local copy one remote. For non-disaster stuff I would still use the local copy. Single file restore or journal analysis or roolbacks or the "tell me who changed this record" requests. The remote copy would only be needed in the event of a disaster that took our the database and receivers at the same time. Like two drives failing in one raid set or the system catches fire or the roof opens during a rain storm or termites eat the floor away and the system falls to the floor below. (that last one I bet the system would survive)

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Kingsley
Sent: Tuesday, July 26, 2011 1:38 PM
To: Midrange Systems Technical Discussion
Subject: Re: Doing remote journals to the cloud

If your sending these journal receivers to a cloud or FTP backend server, how much time might this add to your DR situation to get a system back or a database possibly.

On Tue, Jul 26, 2011 at 11:46 AM, Mike Cunningham
<mike.cunningham@xxxxxxx>wrote:

Main Campus Parking use to use an AS/400 but I don't think they do anymore.
Nice idea. Main Campus uses a VM machine which all the other branches
also use for most admin work. We are a bit of a different beast in the
Penn State world being a totally independent college. I think I might
ask their IT office if anyone does or if I go the hourly FTP route
just give me some disk space on one of their huge Sharks

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bryce Martin
Sent: Tuesday, July 26, 2011 9:37 AM
To: Midrange Systems Technical Discussion
Subject: RE: Doing remote journals to the cloud

Hey Mike,
Are there any IBM i's at main campus or the dozen or so other
satellites that you could get a small lpar on for your remote
journals? Wouldn't staying in the system be cheaper than using a 3rd
party? I'm guessing Main has a real nice trunk ;)

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

Mike Cunningham <mike.cunningham@xxxxxxx> Sent by:
midrange-l-bounces@xxxxxxxxxxxx
07/26/2011 08:52 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

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

Subject
RE: Doing remote journals to the cloud

All good points and all very hard to determine. Students love to suck
up bandwidth. When sending journals I would think it would only take a
small portion of this since the data is spread out over all day. And
in a disaster mode we could force everyone off and give the full pipe
to pulling down a days worth of journals or do it at 3:00 am. Always
going to depending on when the disaster would hit, time of year, needs
to get back up and up-to-date.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, July 26, 2011 8:28 AM
To: Midrange Systems Technical Discussion
Subject: RE: Doing remote journals to the cloud

Does anyone ever get full use of their 250MB pipe? Or are there
"class of service" limitations? Like the voice I mentioned earlier.
We can't have voice transactions getting whacked because of a file download.

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Mike Cunningham <mike.cunningham@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 07/26/2011 08:17 AM
Subject: RE: Doing remote journals to the cloud
Sent by: midrange-l-bounces@xxxxxxxxxxxx

100 minutes on full use of a 250MB pipe (I think- it is early in the
day and my math brain may still be groggy)

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, July 26, 2011 7:55 AM
To: Midrange Systems Technical Discussion
Subject: RE: Doing remote journals to the cloud

Probably faster to overnight them. How fast could you download this?

DSPOBJD OBJ(#MXJRN/*ALL) OBJTYPE(*JRNRCV)
OUTPUT(*OUTFILE) OUTFILE(QTEMP/JRNRCV)

SELECT sum(ODOBSZ)
FROM qtemp/jrnrcv
WHERE ODCDAT in('072511', '072611')

SUM ( ODOBSZ )
23,999,713,280

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 07/25/2011 06:19 PM
Subject: RE: Doing remote journals to the cloud
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Why couldn't you download the remote journals as opposed to express
mailing tapes?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Monday, July 25, 2011 4:57 PM
To: Midrange Systems Technical Discussion
Subject: Re: Doing remote journals to the cloud

How big are the journals and how many transactions/hour. That will
tell us how big a pipe needs to be available to the remote site.

This concept is easy but would most likely require 24 hours to back up
the

remote journals, express overnight delivery (or faster airline
package, but way more money), restore, and roll forward. Is that
inside your recovery window? (Recovery time)

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 7/25/2011 4:24 PM, Mike Cunningham wrote:

My thought was to dual journal local and remote. In the case of a

disaster that destroyed all data - fix the local system, restore last
backup, copy remote journals local and apply them. Not looking for a
hot swap site, just a place to keep journals so as not to lose a day's
work if

this were to happen. We backup nightly and take that off-site both
database and journals but journals are on the same system so if the
disaster where to happen at the end of the next work day I would lose
that

days transactions.

-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Ofrob@xxxxxxxxx
Sent: Monday, July 25, 2011 1:10 PM
To: Midrange Systems Technical Discussion
Subject: Re: Doing remote journals to the cloud

We use Mimix.

I haven't heard if any of the offsite backup places like Vault/400
allow

you to remote journal to their locations.

I know of one person on this list who is offering cloud services for
the

i. Maybe that could be done that way. Unless your transactions are
rather small, wouldn't that take a pretty good pipe?

Are your plans to restore on your home server, move the remote
journal

changes back and then apply them? Or restore on the backup, Apply the
remote changes on the backup and then save and send the data back to
primary?

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Mike Cunningham<mike.cunningham@xxxxxxx>
To:"midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Date: 07/25/2011 12:40 PM
Subject: Doing remote journals to the cloud
Sent by:midrange-l-bounces@xxxxxxxxxxxx

Does anyone on this list know if and 3rd party or IBM is talking
about an offering for iSeries customers to do remote journaling to
the cloud? Keep one copy local and send another to a remote server farm.
That would give is almost up to the second recovery capabilities in
case of disaster. We use the last backup and the journals form the

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