Hi Mark,
That sounds very similar to what we have MIMIX doing at the moment - we
currently have two boxes Live and Backup - the live system is replicated
to Backup using MIMIXHA and then we currently backup the backup system
every night (BRMS option 20) and finally a BRMS Option 21 on Sunday.
We're using probably at least 40 3590's a night and even more on a full
backup.
What I want to do now is replace the tape backups of the backup system
with an FTP server (which would be located externally to our business
and wouldn't necessarily run AS400 (probably not if we need cheap disks)
and would no doubt be connected on it's own gigabit crossover cable.
I will definitely look into some journaling scenarios as it might be an
answer to a problem but it does sound to me like you're asking me to buy
another ISeries (and buy more disks for that system which is one of the
biggest issues atm - especially for backups).
Regards
Mike
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: 03 April 2009 18:19
To: Midrange Systems Technical Discussion
Subject: Re: SAVLIB to FTP where files > 1tb
Hi, Michael:
If your files are that large, why are you copying the entire file(s)
over to another system, over and over again? Is this for "disaster
recovery" purposes?
Investigate the remote Journaling support in i5/OS -- once you establish
an identical copy of the file(s) on the back-up system, you journal the
file(s) on the primary system to the remote journal, and the changes are
automatically sent to the back-up system (via TCP/IP) and automatically
applied to the copy of the file(s) on the remote system. So, you send
only the changes, not the whole file(s).
Or, you could "roll your own" approach to sending only the changes;
instead of remote journaling, journal the files to a local journal and
journal receiver, and then periodically, (perhaps once a day), issue the
CHGJRN command to start a new journal receiver, then save the existing
journal receivers into a save file, send the save file over to the
back-up system, then restore the journal receivers and issue the
APYJRNCHG command to apply the changes to the copy of the database
file(s) on the back-up system. (A kind of "poor man's High
Availability.) You could also write a program that reads the journal
entries on the back-up system, after restore, and then applies the
changes directly.
Otherwise, you will be pumping terabytes of essentially the same data
across the communications channel, over and over again.... :-o Consider
the impact on other network traffic and bandwidth issues, etc..
HTH,
Mark S. Waterbury
Michael Bolland wrote:
Having some issues here,
I would love to FTP my data on a nightly basis to another FTP server
but
this doesn't seem to be possible...
It appears that this is no issue what so ever if you are able to
backup
to a SAV file and then FTP the sav file over.
Unfortunately my files are > 1tb and so I need double the amount of
disk
space to do the backup.
My questions:
1) Why do I need to dupe my data to achieve this, why can't I stream
it
straight over ftp?
2) Can I somehow split it up into many smaller files that can be sent
individually as the backup is processing and then cleared down?
3) How can I get cheap temporary disk space (preferably something like
IDE?) that's not going to cost me an arm and a leg just for this?
Cheers guys, appreciate your time
Mike
This electronic message contains information that is confidential and
may be privileged. This electronic message is intended for the use of
the addressee(s) only. If you are not the intended addressee, any
disclosure, copying, distribution or use of the contents of this message
is prohibited and may be unlawful. Disclosure to any party other than
the addressee, whether inadvertent or otherwise is not intended to waive
privilege or confidentiality.
Although this electronic message and any attachments are believed to
be free from any virus or other defect which might affect any system
into which they are received or upon which they are opened, it is the
responsibility of the recipient to ensure that they are virus free and
to check that they will not adversely affect its systems and data. No
responsibility is accepted by Northern Foods PLC (or any member of its
group) for any loss or damage arising in any way from their receipt,
opening or use.
Northern Foods Plc is registered in England with company number
471864. Registered office: 2180 Century Way, Thorpe Park, Leeds LS15
8ZB.
midrange.com
