Problem with Legato 6.1.4 vs savedt command SQLBT

[Sharuco]

I finish installing the 6,1,4 of Legato and the Oracle backups that use SqlBacktrack
(savedt command) was appearing:

NetWorker savegroup alert) Group completed, total 1 client(s), 0 hostname(s) Unresolved,
1 failed, 0 Succeeded (client Failed)


At level of SqlBacktrack finishes with return code 0 (Ok.)

Thanks beforehand for the support

 

[605]

This is a standard error message that appears for any scheduled backup.
So what is specific to the database?

Run "savegrp -v -G group_name" from the command line and investigate the result.

 

[Sharuco]

Dear 605, this is the exit :

NetWorker savegroup: (alert) SOLARIS-BD-FULL-sun4d7-siva completed, total 1 client(s), 0 Hostname(s) Unresolved, 1 Failed, 0 Succeeded. (sun4d7 Failed)
Start time: Tue Feb 10 12:09:36 2004
End time: Tue Feb 10 15:50:59 2004

--- Unsuccessful Save Sets ---

* sun4d7:/home1/sqlback/sqlf_siva_new rcmd sun4d7, user root: `savedt -s backup-srv -g SOLARIS-BD-FULL-sun4d7-siva -LL -m sun4d7 -l full -W 78 -N /home1/sqlback/sqlf_siva_new /home1/sqlback/sqlf_siva_new'
* sun4d7:/home1/sqlback/sqlf_siva_new

--- Successful Save Sets ---

* sun4d7:index savegrp: suppressed 6467 lines of output -
check daemon.log for details.
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c56a.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c58e.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c5b2.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c5e4.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c607.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c69e.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c6e2.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c740.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c7f6.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c827.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c84c.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0c86e.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0cece.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0cfc7.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/3ff0cfed.rec
* sun4d7:index /usr/nsr/index/sun4d7/db6/
* sun4d7:index /usr/nsr/index/sun4d7/
* sun4d7:index
backup-srv: index:sun4d7 level=full, 2026 MB 00:09:03 6502 files

 

[605]

It looks like you just show the group details but this is not sufficient.

What you see are just the successful index backups - nothing indicates
why the backup fails. If you run the command i told you, you should see more
info due to the "-v" option. You do not have this option when starting the
group from the GUI.

Also, are there logfiles in the /nsr/applogs directory ?

 

[Sharuco]

Dear 605,
in the Legato index backup is Ok.
in the SqlBacktrack RC=0 (Ok.)

this is additional info :


# savegrp -v -G SOLARIS-BD-FULL-sun4d7-siva
override match on 2/12/2004 for level full
sun4d7:/home1/sqlback/sqlf_siva_new level=full
02/12/04 12:25:06 savegrp: Run up to 192 clients in parallel
02/12/04 12:25:08 savegrp: sun4d7robe started
savefs -s backup-srv -c sun4d7 -g SOLARIS-BD-FULL-sun4d7-siva -p -l full -R -v -F /home1/sqlback/sqlf_siva_new
02/12/04 12:25:12 savegrp: sun4d7robe succeeded.
rcmd sun4d7, user root: `savefs -s backup-srv -c sun4d7 -g SOLARIS-BD-FULL-sun4d7-siva -p -l full -R -v -F /home1/sqlback/sqlf_siva_
new'
nsrexec: authtype nsrexec
type: NSR client description;
pools supported: Yes;
migration supported: Yes;
browse time supported: Yes;
remote user: root;
groups: other;
arch: sparc;
client OS type: Solaris;
CPU type: sun4u;
CPUs: 8;
IP address: 10.4.8.44, 10.4.3.201, 10.24.7.200, 10.24.6.74;
kernel arch: sun4u;
machine type: workstation;
MB used: 137584;
NetWorker version: 6.1.4.Build.562;
OS: SunOS 5.6;
version: 6.1.4.Build.562;
save set: path=/home1/sqlback/sqlf_siva_new, arg=/home1/sqlback/sqlf_siva_new, level=full, diskno=0, max_sessions=1, stype=save ;
parallelism: 8
sun4d7:/home1/sqlback/sqlf_siva_new level=full, dn=0, mx=1, vers=ssbrowse, p=6
02/12/04 12:25:12 savegrp: sun4d7:/home1/sqlback/sqlf_siva_new started
savedt -s backup-srv -g SOLARIS-BD-FULL-sun4d7-siva -LL -m sun4d7 -l full -W 78 -N /home1/sqlback/sqlf_siva_new /home1/sqlback/sqlf_
siva_new

and then, the backup finished Ok.

but even when schedulle this in skip in the section messages of the console of Legato appears:
NetWorker savegroup: (alert) SOLARIS-BD-FULL-sun4d7-siva level skip, total 1 client(s), 0 Hostname(s) Unresolved, 1 Failed, 0 Succeeded. (sun4d7 Failed)

thanks for the aid

 

[Sharuco]

I believe that the problem this in this new functionality of 6.1.4 :

LGTpa57832
The NetWorker Administrator did not report if a savegroup had a unresolved hostname.

as I can clear it ??

 

[605]

I do not think that there is a hostname resolution problem as the probe (savefs) before
the backup runs fine. Unfortunately, i do not know SQL Backtrack.

First it is important to figure out whether a normal file backup works. Then i would
stop the database and see whether it can be backed up this way. If successful,
the only problem i may think of is the database backup. You should run
"savegrp -v -G SOLARIS-BD-FULL-sun4d7-siva" and investigate the additional messages.

 

[Sharuco]

Dear 605

the message even appears to several clients for example:

Tue 03:00:24 PM savegroup notice: OVMS-Facturacion-C18F completed, total 2 client(s),
0 Hostname(s) Unresolved, 0 Failed, 2 Succeeded.

Discarded that originates it SqlBacktrack...
As I can clear the LGTpa57832 ??

I want to prove with this operation (if it is possible.)

thanks in advance

 

[Sharuco]

Hello Masters !!
Please help me eeeee......

As i can clear the LGTpa57832 ?
is possible?
this package is part of 6.1.4 release..
I hope can help me.

605 Thanks for your ideas...

 

[605]

Hi Sharuco,

unfortunately, your statements are not very clear.

Let's forget SQL backtrack for the moment and to a tiny file backup (Save set: /etc ,
for example). Then verify whether all files have been really backed up and that
the size matches?

With respect to the skip level backup: What you see may really happen.
Actually, NW will go through each phase of the automatic backup process -
it will just not backup any data.

Please also look whether you may have information in the file /nst/logs/daemon.log.