Re: [foxboro] Backup strategies - Best Practices?

Your batch file shows  $OPT/opt/Saveall, but your email says you are saving 
them to /opt/Save_all.

----- Original Message ----- 
From: "Chaiket, Thom" <tchaiket@xxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Wednesday, November 26, 2008 12:46 PM
Subject: Re: [foxboro] Backup strategies - Best Practices?


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