Hi Gavin
the scheduler will only read the policy includes file every 10 mins by
default. you can change the timer, but it would spend excessive time
reading policies and looking for backups.
so, back to my original idea, do you have permission to write a file to
the NBU master ? if you you could write a flag file saiying 'ok to start
backup now'. your session_start script could sit and wait for the file.
that would help with scheduling, but doesn't help if you want to submit
different filelists to backup. are the lists variable, or could you setup
different policies to address the filelists ?
regards
mark
--
On Tue, 10 Feb 2004, Gregory, Gavin wrote:
> Thanks Mark,
>
> The main problem with scheduling from the Netbackup master is that it's
> under the control of a different team, (in fact they're from a different
> out-sourcing company altogether). I don't get much access to it and it's a
> bit of a headache to get work done in the time frame it's normally required
> in.
>
> The other problem is that I only want to kick off the backup under certain
> circumstances, and those circumstances occur in the Solaris world to which
> the NT server has no access.
>
> I can't see why I'd be able to kick off an immediate backup of data on the
> NAS filer using the -i option but not be able to do it this way.
>
> I thought I had a tricky workaround by updating the filelist for the
> netbackup class from the Solaris system, then submitting the immediate
> backup. That works fine for the first job, but if I then need to submit
> another job for the same class prior to the first one finishing, the second
> job submits as a duplicate of the first job, i.e. it ignores changes to the
> filelist and uses the information from the job already on the worklist.
>
> regards, Gavin
>
> -----Original Message-----
> From: mark [mailto:mark AT steelfamily DOT org]
> Sent: Tuesday, 10 February 2004 11:17
> To: Gregory, Gavin; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Remotely submitted NAS backup uses wrong
> client
>
>
> gavin
>
> one key to the user backup is the client name, which is bound to the host/ip
> of the calling machine ( otherwise big security loophole ). I don't think
> you can spoof this.
>
> why not just schedule from the netbackup master ? I assume there must be
> some co-ordination between the sun host and the filer, perhaps the filer
> stores a database ? you can use a session_start_notify script to run
> something on the master prior to running the ndmp backup, so you could use
> this for example to co-ordinate switching db to backup mode, then rsh to
> filer to take snapshot, then run the backup, then use session_end script to
> re-enable database.
>
> regards
> mark
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Gregory,
> Gavin
> Sent: 09 February 2004 00:52
> To: 'veritas-bu AT mailman.eng.auburn DOT edu'
> Subject: [Veritas-bu] Remotely submitted NAS backup uses wrong client
>
>
> We have a Windows NT 5.0 server acting as the Netbackup 3.4 master server, a
> Solaris 8 admin server (also 3.4) and a Netapp F840 NAS filer.
>
> I want to be able to submit a job from the Solaris server to initiate an
> NDMP backup from the NAS filer to a tape library directly attached to the
> filer.
>
> If I update the Netbackup filelist with the path to backup, I can submit the
> job successfully using the following command:
>
> # bpbackup -h aklns012 -c LONG_TERM -s FULL -L /tmp/lts_archive.log -t 19 -i
>
> however it I attempt to pass the backup path on the command line I get a
> status 239 error because Netbackup for some reason assumes my Solaris system
> is the backup client, i.e. it seems to ignore the -h option:
>
> # bpbackup -h aklns012 -c LONG_TERM -s FULL -L /tmp/lts_archive.log -t
> /vol/vol03/arpt/db/LTS
>
> # cat /tmp/lts_archive.log
> Backup started Mon Feb 09 10:06:04 2004
>
> 10:06:05 Initiating backup
> 10:06:11 INF - Backup by root on client aklss901 using class LONG_TERM,
> sched FULL: the specified client does not exist in the specified class.
>
> bpsched log file:
>
> 10:07:11 [3736.2704] <4> bpsched: INITIATING...
> 10:07:11 [3736.2704] <2> logparams: E:\Veritas\NetBackup\bin\bpsched.exe -ru
> root -rg other -ct 19 -client aklss901 -class LONG_TERM -sched FULL -keyword
> arpt LTS Archive -cv -pl /tmp/lts_archive.log -UB -clnt_lc_messages C
> -clnt_lc_time C -clnt_lc_ctype C -clnt_lc_collate C -clnt_lc_numeric C
> 10:07:11 [3736.2704] <4> bpsched_main: wait_on_que=0, timeout_in_que=36000,
> reread_interval=300,queue_on_error=0, bptm_query_timeout=480, scheduler_mode
> =3
> 10:07:11 [3736.2704] <2> LOCAL CLASS_ATT_DEFS: Product ID = 6
> 10:07:11 [3736.2704] <4> bpsched_main: VSMInit () failed: 2d
> 10:07:11 [3736.2704] <4> ?: post process images: yes
> 10:07:11 [3736.2704] <4> ?: keep tir: yes
> 10:07:12 [3736.2704] <4> get_db_info: Searching for class <LONG_TERM> sched
> <FULL>
> 10:07:12 [3736.2704] <4> get_db_info: found
> 10:07:14 [3736.2704] <16> log_in_errorDB: backup by root on client aklss901
> using class LONG_TERM, sched FULL: the specified client does not exist in
> the specified class
> 10:07:14 [3736.2704] <16> bpsched: backup by root on client aklss901 using
> class LONG_TERM, sched FULL: the specified client does not exist in the
> specified class
>
> Class config:
>
> Class Name: LONG_TERM
> Options: 0x0
> template: FALSE
> c_unused3/2/1: 0 0 ?
> Names: (none)
> Class Type: NDMP (19)
> Active: yes
> Mult. Data Stream: no
> Class Priority: 20
> Max Jobs/Class: 4
> Disaster Recovery: 0
> Keyword: ARP Archive
> Client Encrypt: no
> Residence: aklns011 - - - - - - - - -
> Volume Pool: CPA_Unix_Longterm - - - - - - - - -
> Client/HW/OS/Pri: aklns012 NDMP NDMP 0 0 0 0 ?
> Client/HW/OS/Pri: aklns013 NDMP NDMP 0 0 0 0 ?
> Client/HW/OS/Pri: aklns011 NDMP NDMP 0 0 0 0 ?
> Client/HW/OS/Pri: aklns015 NDMP NDMP 0 0 0 0 ?
> Client/HW/OS/Pri: aklns010 NDMP NDMP 0 0 0 0 ?
> Include: /vol/vol03/arpt/db/LTS
> Exclude: (none defined)
> Schedule: FULL
> Type: FULL (0)
> Frequency: 7 day(s) (604800 seconds)
> Maximum MPX: 1
> Retention Level: 9 (infinity)
> u-wind/o/d: 0 0
> Incr Type: DELTA (0)
> Incr Depends: (none defined)
> Max Frag Size: 0 MB (unlimited)
> Residence: (specific storage unit not required)
> Volume Pool: (same as class volume pool)
> Daily Windows:
> Day Open Close W-Open W-Close
> Sunday 000:00:00 000:00:00
> Monday 000:00:00 000:00:00
> Tuesday 000:00:00 000:00:00
> Wednesday 000:00:00 000:00:00
> Thursday 000:00:00 000:00:00
> Friday 000:00:00 000:00:00
> Saturday 000:00:00 000:00:00
>
>
> Any ideas? Anh help will be greatly appreciated.
>
> Cheers, Gavin
>
>
>
>
> ____________________________________________________________________
> CAUTION - This message may contain privileged and confidential
> information intended only for the use of the addressee named above.
> If you are not the intended recipient of this message you are hereby
> notified that any use, dissemination, distribution or reproduction
> of this message is prohibited. If you have received this message in
> error please notify Air New Zealand immediately. Any views expressed
> in this message are those of the individual sender and may not
> necessarily reflect the views of Air New Zealand.
> _____________________________________________________________________
> For more information on the Air New Zealand Group, visit us online
> at http://www.airnewzealand.com
> _____________________________________________________________________
>
|
