Re: [Veritas-bu] Migrate master server to new hardware
I would install all the packages like a new install then rsync your entire nbu install/data from the old server :) On Fri, Aug 21, 2009 at 10:02 PM, fredriklindgren wrote: > > We are about to migrate our NetBackup master server from old hardware to a > new and at the same time upgrade from SLES9 to SLES10 and do a hostname > change. The server is a pure master and have no connections to disk or tape. > It is connected to 5 media servers. > > Is there a best practice for these kind of migration? Can it be done with a > DR? > > Did some googling and found a post over at the official Symantec forum that > Symantec support can not assist in these kind of operations and you should > contact Syamantec Consulting Service. > > These kind of migrations must be done frequently around NetBackup customers > so I am hoping there are some NetBackup gurus out there that's been through > this before that could give me some good advices? > > Regards > Fredrik Lindgren > > +-- > |This was sent by fredrik.lindg...@rps.police.se via Backup Central. > |Forward SPAM to ab...@backupcentral.com. > +-- > > > ___ > Veritas-bu maillist - veritas...@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Linux slowly dropping drives.
Has anyone placed a call with redhat support? I'm sure they would want this solved as much as anyone On Fri, Jan 30, 2009 at 6:30 AM, Rosenkoetter, Gabriel < gabriel.rosenkoet...@radian.biz> wrote: > One drive may easily have needed cleaning for longer... or are you saying > the two that advertise that are a disjoint set from the one that's down? > > What do you see in /var/log/messages when you try to up the drives? > > What do you see in /usr/openv/netbackup/logs/bptm/log.MMDDYY and in > /var/log/messages when the drives are downed of their own accord? (Turn > VERBOSE=5 on in bp.conf if you haven't already.) > > Also, please describe your environment in more detail: > > Are these drives in a tape library? If so, does that tape library perform > automatic cleaning of the drives? > > Do you have the /usr/openv/volmgr/database/NO_TAPEALERT touch file in > place? (Does that file even still get used under 6.5? I don't see a parallel > setting in nbemmcmd yet...) > > (I have something of a vested interest here... I'm about to migrate from > HP-UX 11iv2 to RHEL 5 for our NetBackup servers, so if there's a fundamental > flaw in the Linux ST driver or NetBackup's use of it, I'd like to know > sooner...) > > -- > gabriel rosenkoetter > Radian Group Inc, Senior Systems Engineer > gabriel.rosenkoet...@radian.biz, 215 231 1556 > > > -Original Message- > From: Donaldson, Mark [mailto:mark.donald...@staples.com] > Sent: Wednesday, January 28, 2009 2:34 PM > To: Justin Piszcz > Cc: veritas-bu@mailman.eng.auburn.edu > Subject: Re: [Veritas-bu] Linux slowly dropping drives. > > Interesting - I never thought of tpclean. > > tpclean shows two in "need cleaning" status but, as I have one drive > down now, there's no correlation with the down drive. > > lto2 are scsi drives connected via fc through fiber bridges. > > I've had this problem through multiple version of this OS but it's the > only Linux media server in my environment. (We're using the native lto2 > drive, too - supposed to be part of this OS). > > -M > > -Original Message- > From: Justin Piszcz [mailto:jpis...@lucidpixels.com] > Sent: Wednesday, January 28, 2009 11:33 AM > To: Donaldson, Mark > Cc: veritas-bu@mailman.eng.auburn.edu > Subject: Re: [Veritas-bu] Linux slowly dropping drives. > > > > On Wed, 28 Jan 2009, Donaldson, Mark wrote: > > > We have a dedicated media server built on an AMD box running RHEL 5.2 > > (2.6.18-92.1.13.el5 #1 SMP Thu Sep 4 03:51:21 EDT 2008 x86_64). > > > > Over time, our LTO2 drives will go down one by one. A "scan" doesn't > > seem to show any issues but if I "vmoprcmd -up" them, they'll just go > > down again. After I collect a half-dozen down drives, I reboot the > > server and they'll be fine again for while. > > > > Anybody else having this trouble? Have you solved it? > > > > -M > > > > ___ > > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > > What does tpclean -L say? > > Have they ever stayed up in the past? > > Do you have a fiber switched environment? > > Justin. > > > > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] How to plan out policy(schedules), [...]
On Sat, Dec 13, 2008 at 10:31 AM, Curtis Preston wrote: > Suit!?!?! Them's fightin' words! > > > > I need to do a blog on this, as I answer this question a lot. > > > > If you want to do weekly backups using frequency based schedules, here are > your choices. > > > >1. Leave the window open only on the night you want the backup to run. >Schedules that succeed that night will be fine. BUT if it fails that > night, >it won't retry until next week. Yuck. >2. Leave all nights' windows open. When the backup that's supposed to >run Monday fails and then runs on Tuesday, it will always run on Tuesday >from then on because that will be when it meets the frequency of 7 days. >Full backups end up creeping around and bunching together. I HATE this one >as it's unpredictable over time. I've seen it where over time all my full >backups were running on the same night. (I like to spread them out.) >3. Leave a few days' windows open (say, 3), and set a frequency of 4 >days. This causes NBU to try on the first day with an open window, then >retry on the second/third if it fails. You have the retry feature that >calendar-based backups have without the schedule creep problem because you >have a frequency of four days. (This is the best of the three, IMHO.) > > > The schedule-creep problem is compounded by manual backups. If you ever do > a manual backup, the frequency will be calculated from that day. Suppose > you chose option three above and opened the windows for Friday, Saturday, > and Sunday night, and put a frequency of four days. If you happened to run > a manual full backup on Thursday night, your regular full backup won't run > that weekend. > > > I agree 100% with Curtis on this. If you have a large environment with drives/resources being super utilised schedule creep can and is disastrous. Not to mention client X expected his full to run on day Y and needed to backout from a change based on the full backup - woops! > _*I*_ like to do monthly full backups and weekly cumulative incremental > backups. The above problems are compounded when you want to do this. You > can't reliably predict what night the fulls are going to run, and can't > easily spread them out across the month (which I like to do). It's much > easier to spread them out using calendar based schedules. You take some > clients and tell them to do their full on the 1st Friday of the month, and > their cumulative incremental every Friday. When the two "clash" on the 1 > st Friday, the full takes precedence and runs. Every other Friday it will > run a cumulative incremental. As for the failed backup problem, you just > check "allow after run day," and it will retry the backups until they > succeed, and this won't mess in any way with when they'll run the next > time. Also, running manual full backups won't mess with the schedule > either. > > > > The manual tells you not to mix calendar and frequency backups. I don't > like calendar backups for daily backups, so some see this as a problem. BUT > I've found that if you monthly full, weekly cumulative, and daily (frequency > based) incremental all have the same windows, the frequency-based schedule > will take precedence and run when the others aren't running and the calendar > backups will take precedence when it's time for them to run. You just have > to keep the windows the same. > > > > The only goofy thing about calendar-based schedules (and it really annoys > me) is that most people use a 6 PM to 6 AM clock (or some evening hour to > some morning hour). If you tell NBU to do the full on the 1st Friday of > the month and leave all windows open, it will actually run the backup at > just after midnight on Friday (Thursday night). That's probably not what > you wanted. So you have to delete the window for the night before (in this > case, Thursday). I hate it, but I've learned to live with it. > > > > Both methods have issues. I prefer the predictability of the > calendar-based method. > > > > > *Curtis Preston | VP Data Protection** > *GlassHouse Technologies, Inc. > > T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009 > cpres...@glasshouse.com | www.glasshouse.com > *Infrastructure :: Optimized* > > > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas
Re: [Veritas-bu] NOM 6.5.
Thanks Ed, I'm interested if anyone is using it in a large site and if so, it what capabilities, what server configuration and how is it performing for them :) By large, I mean tens of thousands of jobs and thousands of clients... Cheers Andrew On Mon, Nov 10, 2008 at 9:57 AM, Ed Wilts <[EMAIL PROTECTED]> wrote: > On Sun, Nov 9, 2008 at 3:27 PM, Andrew White <[EMAIL PROTECTED]> wrote: > >> >> I'm just wondering what are peoples thoughts on NOM 6.5? In what capacity >> are you using NOM (reporting and/or alerting (snmp/email)) and has anyone >> got it configured in a cluster? > > > After the Customer Forum in Roseville at the end of October, Erica > convinced me to put it up. Although I generally like NOM, we haven't had > much success with it and the we've got an open case where it seems to > contribute to tipping over our master server (and yes, it's a separate > server). Right now, we've got NOM turned off. > > YMMV, obviously. > > .../Ed > > Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE > [EMAIL PROTECTED] > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] NOM 6.5.
NOM is free... aptare isnt. On Mon, Nov 10, 2008 at 2:08 PM, Scott Jacobson <[EMAIL PROTECTED]> wrote: > And so it may be time again to have NOM and Aptare discussion. > > Could those who've been a supporter and user of each now chime in give us > their current comparative opinions? > > Thanks, > -sj > > >>> Dean <[EMAIL PROTECTED]> 11/9/2008 7:01 PM >>> > > Ed, > > I'm interested to know how you think NOM contributed to problems on your > master. Can you elaborate? > > Our master is RHEL4, NOM running on a Win2003 box. NOM is kinda helpful, > but, if there is any chance of it causing problems on the master, I will > shut down NOM immediately. > > Thanks, > Dean > > On Mon, Nov 10, 2008 at 9:57 AM, Ed Wilts <[EMAIL PROTECTED]> wrote: > >> On Sun, Nov 9, 2008 at 3:27 PM, Andrew White <[EMAIL PROTECTED]> wrote: >> >>> >>> I'm just wondering what are peoples thoughts on NOM 6.5? In what >>> capacity are you using NOM (reporting and/or alerting (snmp/email)) and has >>> anyone got it configured in a cluster? >> >> >> After the Customer Forum in Roseville at the end of October, Erica >> convinced me to put it up. Although I generally like NOM, we haven't had >> much success with it and the we've got an open case where it seems to >> contribute to tipping over our master server (and yes, it's a separate >> server). Right now, we've got NOM turned off. >> >> YMMV, obviously. >> >> .../Ed >> >> Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE >> [EMAIL PROTECTED] >> >> >> ___ >> Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu >> >> > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] NOM 6.5.
G'day, I'm just wondering what are peoples thoughts on NOM 6.5? In what capacity are you using NOM (reporting and/or alerting (snmp/email)) and has anyone got it configured in a cluster? Cheers Andrew ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Duplicating Image
errr, the "oracle" job means you can use the netbackup scheduler to perform the duplicate rather than using cron. On Fri, Oct 17, 2008 at 11:10 PM, Jeff Lightner <[EMAIL PROTECTED]> wrote: > You can just write a shell script that runs the bpduplicate. Not sure > why anyone would think this would require an "Oracle" backup. > > > > Another option with that short a window is to simply do in line backup copy > where you actually write the backup twice as it is running. We do that > with our multi-terabyte DBs that would take far too long to duplicate after > the fact. > > > -- > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Andrew White > *Sent:* Friday, October 17, 2008 3:12 AM > *To:* [EMAIL PROTECTED] > *Cc:* veritas-bu@mailman.eng.auburn.edu > *Subject:* Re: [Veritas-bu] Duplicating Image > > > > Hi, > > You could setup an "oracle" backup which executes a script which performs > bpduplicate :) > > cheers > > > On Fri, Oct 17, 2008 at 1:33 PM, Roedy boy <[EMAIL PROTECTED]> wrote: > > Hi All, > Is there any change to duplicate image on tape to another tape using > schedule/policy (not using vault). for exp : I want to run backup on 8pm and > the duplicate the image on 10pm. > > Thanks > Roed > > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > -- > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential > information and is for the sole use of the intended recipient(s). If you are > not the intended recipient, any disclosure, copying, distribution, or use of > the contents of this information is prohibited and may be unlawful. If you > have received this electronic transmission in error, please reply > immediately to the sender that you have received the message in error, and > delete it. Thank you. > -- > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Duplicating Image
Hi, You could setup an "oracle" backup which executes a script which performs bpduplicate :) cheers On Fri, Oct 17, 2008 at 1:33 PM, Roedy boy <[EMAIL PROTECTED]> wrote: > Hi All, > Is there any change to duplicate image on tape to another tape using > schedule/policy (not using vault). for exp : I want to run backup on 8pm and > the duplicate the image on 10pm. > > Thanks > Roed > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] NBU cross-site
Howdy, Likewise (depending on the environment) we have clustered masters locally and the replicated to another site as well or for the non-highly available we just have a single master and deal with a 4 hour outage to rebuild the machine. Multiple masters is just a pain in the backside. On Wed, Oct 8, 2008 at 9:04 AM, Clausen, Matt R [EQ] < [EMAIL PROTECTED]> wrote: > I'm curious though…. From a Disaster Recovery perspective, are you > replicating a master across sites to avoid the master server being the > single point of failure? If so, what are you using to do it? > > > -- > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Andrew White > *Sent:* Tuesday, October 07, 2008 5:44 PM > *To:* Ed Wilts > *Cc:* VERITAS-BU@mailman.eng.auburn.edu > *Subject:* Re: [Veritas-bu] NBU cross-site > > > > I agree with Ed, > > I have media servers scattered around the entire country without any > issues. > > On Fri, Oct 3, 2008 at 10:19 AM, Ed Wilts <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 2, 2008 at 3:56 PM, spaldam <[EMAIL PROTECTED]> > wrote: > > Second, I wouldn't run master/media servers across a WAN; especially since > NOM has the ability to manage multiple Master servers from a centralized > console. If you lose the WAN, you done and all you backups fail. > > > I disagree - we have media servers scattered in multiple locations > connected to our main master and it's been working fine for a long time. > Simply put, don't lose the WAN - we have redundant paths to all of our > locations with media servers. If we lose WAN connectivity to our remote > offices, they're in a world of hurt anyway and backups are the least of > their problems. > > -- > > .../Ed > > Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE > [EMAIL PROTECTED] > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] NBU cross-site
I agree with Ed, I have media servers scattered around the entire country without any issues. On Fri, Oct 3, 2008 at 10:19 AM, Ed Wilts <[EMAIL PROTECTED]> wrote: > On Thu, Oct 2, 2008 at 3:56 PM, spaldam <[EMAIL PROTECTED] > > wrote: > >> Second, I wouldn't run master/media servers across a WAN; especially since >> NOM has the ability to manage multiple Master servers from a centralized >> console. If you lose the WAN, you done and all you backups fail. > > > I disagree - we have media servers scattered in multiple locations > connected to our main master and it's been working fine for a long time. > Simply put, don't lose the WAN - we have redundant paths to all of our > locations with media servers. If we lose WAN connectivity to our remote > offices, they're in a world of hurt anyway and backups are the least of > their problems. > > > -- > > .../Ed > > Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE > [EMAIL PROTECTED] > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] ACSLS 7.1 to 7.2
G'day, I am also looking at upgrading to 7.2 on a few environments and would be interested in how people go... Cheers > We recently upgraded to ACSLS 7.2. It was very simple with no DB issues. > Of course we did not migrate the database. We did a fresh install and a > library audit populated the new database... > > Harry S. > Atlanta > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hudson, > Steve > Sent: Monday, April 14, 2008 1:21 PM > To: Scott Jacobson; nbu > Subject: Re: [Veritas-bu] ACSLS 7.1 to 7.2 > > > > I will be doing this soon as well so I am also interested in real world > experiences. > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Scott > Jacobson > Sent: Monday, April 14, 2008 11:41 AM > To: nbu > Subject: [Veritas-bu] ACSLS 7.1 to 7.2 > > > > Has anyone upgraded their ACSLS 7.1 to 7.2? > > > > Just curious if there were any issues with database migration from > Informix to Postgres? > > > > I didn't see anything on the topic at Backup Central. > > > > The instructions from the StorageTek 7.2 ICAG look straight forward, but > looks can be deceiving. > > > > Any experiences, suggestions or guidelines would be appreciated. > > > > Thanks, > > Scott > > > > The information contained in this email message and its attachments is > intended only for the private and confidential use of the recipient(s) > named above, unless the sender expressly agrees otherwise. Transmission > of email over the Internet is not a secure communications medium. If you > are requesting or have requested the transmittal of personal data, as > defined in applicable privacy laws by means of email or in an attachment > to email you must select a more secure alternate means of transmittal > that supports your obligations to protect such personal data. If the > reader of this message is not the intended recipient and/or you have > received this email in error, you must take no action based on the > information in this email and you are hereby notified that any > dissemination, misuse, copying, or disclosure of this communication is > strictly prohibited. If you have received this communication in error, > please notify us immediately by email and delete the original message. > > > > !DSPAM:4804c0d1135711403745939! > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > !DSPAM:4804c0d1135711403745939! > -- http://systems-u.org ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
