|
Larry,
All of your concerns are valid, but I am limited on what I can do.
The point of my questions was to determine if it was possible to do a Option#22 to a windows server.
Since no one mentioned this I am assuming it is not possible.
You do mention RVX, not sure what this does, can you explain?
I will discuss with management your encryption option, but I guess that would require either hardware or software costs.
Whatever option I selected it will be tested to insure it can be recovered at the remote site.
Thanks for your input.
Rogers
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Sunday, August 31, 2014 4:41 PM
To: Midrange Systems Technical Discussion
Subject: Re: SYSSAV(Option 21) Media Options
Well you raise valid questions for sure.
As Paul mentioned for the system only part an option 22 save is a great choice. This omits most customer data but does still include user profiles and passwords if that's an issue for you. Of course you could get some customer data if you place it poorly in IBM libraries or in IBM Folders in the IFS.
You can direct this backup either to Tape or Optical. This could be LTO, DVD, or RVX. Also any of the VTLs out there are useful here. Remember though that DVD-RAM is *FABULOUSLY* slow.
Then you would do your regular backups however that is set up to catch customer data.
Now understand that what you likely are doing here is adding layers of complication to your recovery. Whenever you think about recovery you must be able to put 'humpty dumpty' back together. If you complicate this backup by breaking it up into many places then you must, MUST,
**MUST** practice this re-assembly when there is no stress to prove that it will work as you intend it too.
Here's another option to consider, what if the tape is encrypted and sent off site as it is today. But hold back the encryption keys and send them only if a recovery is needed.
Another option is to send the tapes in a combination locked box and hold back the combination unless a recovery is needed.
- Larry "DrFranken" Bolhuis
www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
On 8/31/2014 10:06 AM, Laine, Rogers wrote:
Hello,--
We are running V6.1.0 and have been backing up our system using Option #21 to physical tape media.
The tape is sent offsite each day for use at our remote disaster recovery site(Sungard).
This tape is used to recovery our full system at Sungard when a disaster is declared.
Now management has decided that they no longer want to send this tape offsite for recovery.
One reason is this backup tape has customer data from the application.
Here are options I think may be possible...
Option #1
Continue my daily option#21 but direct my backup to a Windows Server path on our network. If this is possible?
At remote site recover system reading the backup from the Windows Server. May need to FTP backup file to remote site before starting recovery. If this is possible?
Option#2
Modify option#21 to not include any application data that has customer information.
Run backup directing it to either tape or DVD if it will fit.
This backup would go off site just once until changes to AS400 are made and would be used to recovery base system.
Along with the backup we would backup the security information daily using a Save File and FTP to remote site to be restored after the base restore is finished. This should provide a working system with all updates as it is being done now.
So what are the Pros/Cons for each option and are they doable?
Any other suggestions without spending money for hardware or software?
Thanks,
Rogers
************************************************
This E-Mail transmission (and/or the documents accompanying it) may
contain information belonging to the sender which is confidential,
privileged and/or exempt from disclosure under applicable law. The
information is intended only for the use of the individual(s) or
entity named above. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or the
taking of any action in reliance on the contents of this information
is strictly prohibited. If you have received this E-Mail transmission
in error, please immediately notify us by return E-Mail or telephone
to arrange for return of its contents including any documents.
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 E-Mail transmission (and/or the documents accompanying it)
may contain information belonging to the sender which is confidential,
privileged and/or exempt from disclosure under applicable law. The
information is intended only for the use of the individual(s) or entity
named above. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this E-Mail transmission in error,
please immediately notify us by return E-Mail or telephone to arrange
for return of its contents including any documents.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
