Re: [foxboro] Backup strategies - Best Practices?

>>Sorry folks. I do not know what happened but my reply got messed up with the 
worng originating messages.
>>Here is the retry so it will archive properly

Hi Thom,

I missed your message for a moment since it does not adress save_all's at 
first sight.

There is a "save_all.sh" script on Cassandra that some of my friends and I 
wrote (we all work for IPS). This is completely useful for our ICC users out 
there.

We did serious testing on all platforms up to Solaris 8 (I think we even did 
Server 2003 too).
It does work on both UNIX and Windows platforms. I would suggest that youkick 
the tires and have a look at that. It is supported to some extend (time is 
limited) but on the other hand is completely free ("in speech" as "in beer") 
for you to tinker as you feel fit to do.
I consider this well documented too but I'm reasonable biased I must warn you 
since I wrote the manual.
Give it a try, I think you will appreciate it.

Good luck with your task to come up with a good backup strategy.

Kindest regardsOn Wednesday 26 November 2008 19:46:01 Chaiket, Thom wrote:
> I wanted to automate the creation of save_all files on my P91 (XP, 2003
> server).  What I had in mind was writing a batch file to execute
> save_all.ksh on every Sunday at 2 AM and have the save_alls saved to
> opt/Save_all folder.
>
> I'm good on using Scheduler to automate the 2 AM Sunday execution.
> However, the file itself is kicking me.
>
> My batch file looks like this:
>
> D:
> ncenv
> sh
> cd opt/fox/ciocfg/api
> save_all <STN> $OPT/opt/Saveall/<STN>
>
> I've spent a couple days looking for ways to correct the syntax, but I
> still can't get it to work.  I would greatly appreciate assistance.
>
> Thanks and happy T-giving to all.
>
> t
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Ellis, Jeff
> Sent: Monday, July 14, 2008 9:13 am
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Backup strategies - Best Practices?
>
> I would love to get a copy of the script for backups mentioned below (by
> Ian Sweetman).  This would be a great script for the site.
>
> I too have setup the CassandraProject site save_all.sh. (BTW...My hat
> goes off for whoever did the documentation for the save_all.sh!!!  Great
> Job!!!)  To prevent weekend call-outs, if there is a problem, I have set
> the crontab timing for early on weekday mornings starting on Monday at
> 1:00 am.  And I have used the -s option to group which CPs get uploaded
> and when (to prevent a full day of uploads on the system).  As well, I
> am creating an ICCPRT file at the same time.  (The ICCPRT file is
> primarily to assist in documenting WHAT changed and WHEN...another great
> little scripting opportunity). =20
>
> However, I love the thought of evaluating which CP configuration has
> changed and doing a backup on that CP immediately.  PROACTIVE...Steven
> Covey would love it!
>
> Is there any other "Best Practices" implemented by the group?  The
> questions that have been posed to me are as follows:
>
> (1)  What should you back up on an AW (Is there different files required
> for the Unix and Windows boxes)?
> (2)  How often should you make a FULL Tape Backup (Monthly, Quarterly,
> Yearly)? =20
> (3)  What files should be backed up more frequently than a tape backup
> to ensure system integrity (cfgpts, CSA_save,Duc's "Tar Ball" of
> /opt/fox/ciocfg directories, etc.)?
> (3)  How and where do you copy the backup files in the event of a HD
> failure?  (Do you Push or Pull these files via a FTP script to an IT
> network that is backed up nightly??  I've heard FTP is not secure over
> IT networks...so how do you transfer these files?)
> (4)  Are the Ghost Images that are being utilized by the Windows boxes
> sufficient for recovery?=20
> (5)  And finally...How do you organize all this "STUFF" so that you can
> find it when you need it?
>
> I have my opinions but I do not want my Customer's relying on "MY
> OPINION" alone.  I would love to see a "Best Practices" reference file
> for this idea and others somewhere on THECASSANDRAPROJECT site.  Your
> thoughts?
>
> Thanks,
> Jeff Ellis
> jeff.ellis@xxxxxxxxxxxxxxxxxx
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Sweetman, Ian F
> Sent: Wednesday, July 09, 2008 11:08 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Backup strategies (was: Gremlins in Conversion)
>
> I use an unattended scripted backup strategy to do our routine CP
> backups.
>
> Rather than trying to do every device every day I set a priority system
> where the script checks to see if a control database was changed today,
> if it has it adds it to a list. Second priority is databases that are
> approaching two weeks without being done, Foxboro used to recommend this
> as a maximum period in SAR reports. This way even if no changes are made
> it is routinely backed up.
>
> Once a list is generated the script starts a routine of doing an upload,
> checkpoint and shrink of the device followed by a saveall to the
> harddrive.
>
> The number of devices allowed in the list is configured with a variable
> in the script so that you can control what's going on.
> The scripts checks for locks on the control database so doesn't try and
> perform any operations on a device that someone is working on or has
> gone home and left an ICC session running, this is then captured for
> inclusion in the e-mail reporting the status of the scripts operations.
>
> The script runs on each of our hosts at 0100hrs, the updated files are
> then captured in our daily incremental backups and copied off to another
> machine for safe keeping.
>
> This has been running now for quite a few years and the only problems
> I've experienced have been with earlier versions of ACM modules
> (Triconex interface). Software upgrades and unloading the ACM's have
> since fixed this.
>
> I have monitored the Nodebus using sniffer software for traffic issues
> with these types of operations and never seen an issue of course it's a
> bit difficult to check that there isn't a network problem that will
> impact your script operations, but you can't have everything.
>
> Hope that is useful background.
>
> Regards
> Ian Sweetman
> BP Oil=3D20
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: