Start a Conversation

Unsolved

This post is more than 5 years old

D

1042

January 17th, 2007 12:00

Inaccurate "unsuccessful save set" notifications and "failure" on report?

Hi - we have an issue with Legato/NW considering warnings as "unsuccessful save set"s on the notification, which consequently show as "failures" on reports which are mailed to users via crontab - this is causing us unending grief as the users think their backups have failed - We have a ticket open on this, and no one at EMC can seem to help - this is a root problem with the product -
(Keep in mind that these appear to be WARNINGS and not failures)
here are a few examples:

NetWorker savegroup: (alert) DPH_APP_FS0400 completed, total 5 client(s), 0 Hostname(s) Unresolved, 1 Failed, 4 Succeeded. (dph-app-fs-02 Failed)
Start time: Sun Jan 14 19:00:00 2007
End time: Sun Jan 14 21:13:26 2007

--- Unsuccessful Save Sets ---

* dph-app-fs-02:F:\ Cannot determine status of the backup process. Use mminfo to determine job status.

--- Successful Save Sets ---

dph-app-fs-01: F:\ level=incr, 0 KB 00:00:24 0 files
nsrha: index:dph-app-fs-01 level=9, 0 KB 00:00:09 0 files

dph-app-fs-02: C:\ level=incr, 472 MB 00:05:01 242 files
dph-app-fs-02: E:\ level=incr, 0 KB 00:00:42 0 files
dph-app-fs-02: SYSTEM STATE:\ level=full, 14 MB 00:00:27 15 files
dph-app-fs-02: SYSTEM DB:\ level=full, 992 KB 00:00:24 11 files
dph-app-fs-02: SYSTEM FILES:\ level=skip, 0 KB 00:00:04 0 files
nsrha: index:dph-app-fs-02 level=9, 201 KB 00:00:05 10 files


NetWorker savegroup: (alert) DB0000 completed, total 2 client(s), 0 Hostname(s) Unresolved, 1 Failed, 1 Succeeded. (dph-app-dr-01 Failed)
Start time: Wed Jan 17 02:00:00 2007
End time: Wed Jan 17 04:12:22 2007

--- Unsuccessful Save Sets ---

* dph-app-dr-01:MSSQL: [3316]
01/17/07 02:07:30 Backing up of Northwind succeeded.
* dph-app-dr-01:MSSQL:
* dph-app-dr-01:MSSQL:
* dph-app-dr-01:MSSQL:livedb Cannot determine status of the backup process. Use mminfo to determine job status.

--- Successful Save Sets ---

* dph-app-dr-01:MSSQL:testdb [3468]
01/17/07 02:12:56 Backing up of testdb succeeded.
* dph-app-dr-01:MSSQL:testdb
* dph-app-dr-01:MSSQL:testdb
dph-app-dr-01: MSSQL:testdb level=full, 1631 MB 00:06:47 1 file(s)
* dph-app-dr-01:MSSQL:testdb [3468]
01/17/07 02:12:58 Skip building named instance directory because there are no named instances installed or running on this machine.
nsrha: index:dph-app-dr-01 level=full, 77 MB 00:00:17 602 files

NetWorker savegroup: (alert) UNIX1_2000 completed, total 39 client(s), 0 Hostname(s) Unresolved, 1 Failed, 38 Succeeded. (mmisah01.ehs.state.ma.us Failed)
Start time: Tue Jan 16 21:00:00 2007
End time: Wed Jan 17 02:59:26 2007

--- Unsuccessful Save Sets ---

* mmisah01.ehs.state.ma.us:/u02 save: Warning - `/u02/oradata/MAMISA1/mamisa1_system.dbf' changed during save
* mmisah01.ehs.state.ma.us:/u02 save: Warning - `/u02/oradata/MAMIST2/mamist2_undo01a.dbf' changed during save

--- Successful Save Sets ---

ss-03 Failed)
Start time: Wed Jan 17 00:00:00 2007
End time: Wed Jan 17 00:35:43 2007

--- Unsuccessful Save Sets ---

* dmr-ss-03:all 1 retry attempted
dmr-ss-03:all : No full backups of this save set were found in the media database; performing a full backup
* dmr-ss-03:all save: all : No such file or directory

--- Successful Save Sets ---

* dcam-csg-web-1.es.govt.state.ma.us:C:\ save: File C:\Program Files\Common Files\Symantec Shared\VirusDefs\lulock.dat could not be opened and was not backed up. (The process cannot access the file because it is being used by another

NetWorker savegroup: (alert) DPH_APP_FS0400 completed, total 5 client(s), 0 Hostname(s) Unresolved, 2 Failed, 3 Succeeded. (dph-app-fs-01, dph-app-fs-02 Failed) Restart time: Tue Jan 16 07:51:01 2007
End time: Tue Jan 16 10:03:11 2007

--- Unsuccessful Save Sets ---

* dph-app-fs-01:F:\ Cannot determine status of the backup process. Use mminfo to determine job status.

* dph-app-fs-02:F:\ Cannot determine status of the backup process. Use mminfo to determine job status.

--- Successful Save Sets ---

nsrha: index:dph-app-fs-01 level=9, 228 KB 00:00:06 8 files

nsrha: index:dph-app-fs-02 level=9, 469 KB 00:00:07 15 files

* dph-app-fs-03:C:\ save: File C:\Program Files\UMS\Director\data\esntevt.dat could not be opened and was not backed up. (The process cannot access the file because it is being used by another process.)
dph-app-fs-03: C:\ level=incr, 433 MB 00:05:58 109 files
dph-app-fs-03: E:\ level=incr, 0 KB 00:00:55 0 files
dph-app-fs-03: F:\ level=incr, 26 GB 00:54:42 664 files
dph-app-fs-03: SYSTEM STATE:\ level=full, 14 MB 00:00:20 15 files
dph-app-fs-03: SYSTEM DB:\ level=full, 974 KB 00:00:18 11 files
dph-app-fs-03: SYSTEM FILES:\ level=skip, 0 KB 00:00:01 0 files
nsrha: index:dph-app-fs-03 level=9, 329 KB 00:00:06 13 files

dph-app-fs-04: C:\ level=incr, 359 MB 00:05:24 99 files
dph-app-fs-04: E:\ level=incr, 0 KB 00:01:07 0 files
dph-app-fs-04: F:\ level=incr, 8406 MB 00:19:33 352 files
dph-app-fs-04: SYSTEM STATE:\ level=full, 14 MB 00:00:19 15 files
dph-app-fs-04: SYSTEM DB:\ level=full, 992 KB 00:00:15 11 files
dph-app-fs-04: SYSTEM FILES:\ level=skip, 0 KB 00:00:03 0 files
nsrha: index:dph-app-fs-04 level=9, 221 KB 00:00:06 14 files

dph-app-fs-05: C:\ level=incr, 431 MB 00:04:57 105 files
dph-app-fs-05: E:\ level=incr, 6531 MB 01:11:15 3961 files
dph-app-fs-05: SYSTEM STATE:\ level=full, 14 MB 00:00:18 15 files
dph-app-fs-05: SYSTEM DB:\ level=full, 989 KB 00:00:13 10 files
dph-app-fs-05: SYSTEM FILES:\ level=skip, 0 KB 00:00:03 0 files
nsrha: index:dph-app-fs-05 level=9, 1579 KB 00:00:04 13 files

128 Posts

January 17th, 2007 20:00

What mminfo is showing for that particular saveset?

2 Intern

 • 

14.3K Posts

January 18th, 2007 00:00

This sort of thing was fixed in recent jumbo - what is your version?

33 Posts

January 18th, 2007 05:00

We have version 7.2 - the save sets are FINE, the problem is that these are WARNINGS but they show as FAILURES on reports and "UNSUCCESSFUL SAVE SETS" on notifications. This is a huge problem with this product, this is NOT due to our configurations. Warnings should NOT show as failures. EMC tech support has been unable to address this, and we are exploring other non-EMC backup options and getting rid of NETWORKER as a result of this. :(

2 Intern

 • 

14.3K Posts

January 18th, 2007 06:00

In 7.3.x you can make difference between those, but even earlier that was not a problem. Certain recent versions had an issue like yours which has been sorted out by patch. I Find difficult to believe that you have 7.2 and no one told you to upgrade. If you really have 7.2 then upgrading would be first step.

2 Intern

 • 

14.3K Posts

January 18th, 2007 06:00

To add, for some reason (which needs to be investigated) savegrp was not able to obtain status of backup of your saveset. In that case savegrp doesn't know if that is faulty or not saveset and it will simply assume the worst (which is much better that saying something is ok when it's not).

33 Posts

January 18th, 2007 09:00

We have investigated, and the save sets are OK - we don't mind getting warning diagnostics, we like that - BUT they cause the entire group to be listed as "failed"in reports that we send off to our customers/clients, and they go nuts EVERY DAY and we have to waste time EVERY DAY to prove over and over that their backups are OK, they keep these reports for auditors. - this is the prob - we are slated to upgrade soon, but there is a lot of red tape here before we do that.
Are y'all saying that 7.3.2 can generate a warning msg without flagging the backups as "failed" and listing it under the "unsuccessful save set" category in the notification?

2 Intern

 • 

14.3K Posts

January 18th, 2007 13:00

What I'm saying is that what you get with your version is not normal NetWorker behavior. Why savegrp can't find status of saveset is something that support and you should focus.

In 7.3.x you can choose to have savegrp marked successful with warning (default and how it should be in all previous versions) and without warning (meaning warning would cause group to fail).

2 Intern

 • 

14.3K Posts

January 18th, 2007 13:00

Try to ping them again. This error has been known (cannot determine status of backup) and it has been seen for some customers for different reasons (and to be honest in some cases cause was rather specific). With debug option they can see what and where is causing the problem so escalate it to support.

I have another question (and perhaps hint): does this error (determine status) happens only with Windows clients?

And nevertheless, get 7.2.2 jumbo (it's free and it's good and it's recommended and...) asap and update your environment unless you did that already.

33 Posts

January 18th, 2007 13:00

THX, but we have had a ticket open since October, and support has mentioned nothing at all about this... (Service Request 1636118)
No Events found!

Top