automated backup

[Carla Breuer]

Hello all!
I am running HP-UX 11.0 on an rp5400. I have set up my nightly backup via sam. I am receiving the following errors daily in root mail:
To: root
Subject: see /var/sam/log/br_log
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Full backup failed on sys#### : Wed 17 00:24:43 PDT 2003.
For more information, see the log file /var/sam/log/br_log.

Output from fbackup:

br_backup: Invoking fbackup. See /var/sam/log/br_log for details.
fbackup(1004): session begins on Tue Sep 16 23:59:01 2003
fbackup(3203): volume 1 has been used 1 time(s)
fbackup(3024): writing volume 1 to the output file /dev/rmt/3m
fbackup(1102): WARNING: unable to stat file /var/spool/sockets/pwgr/client663
fbackup(1102): WARNING: unable to stat file /var/spool/sockets/pwgr/client739
fbackup(3005): WARNING: file number 129122 was not backed up
fbackup(3005): WARNING: file number 129124 was not backed up
fbackup(3055): total file blocks read for backup: 8144611
fbackup(3056): total blocks written to output file /dev/rmt/3m: 8557288
fbackup(1030): warnings encountered during backup

OK, I read br_log and don't see anything ugly in there.
These /var/spool/sockets/pwger/client### files seem to be garbage. They contain no data and there is never the exact client### in there.
This server was in test environment until 3 weeks ago we went live. I have not had one backup complete successfully since then. br_index looks good also. I really think my backups are good and will test this by restoring some files. My real question is what are these client### files and how do I find out where are they coming from? They seem to be multiplying daily, but there is nothing in any of them.
ll shows:

total 0
srwxrwxrwx 1 root root 0 Sep 17 07:13 client 11241 (sorry about the text wrap) etc.. about 60 or 70 of them today.

the only thing that changes is some are username printername instead of root root and the numbers on the end of the filename.

Good points to all for help with this long winded question!

Thanx,

Carla

[Steven E. Protter · Accepted solution]

fbackup(1102): WARNING: unable to stat file /var/spool/sockets/pwgr/client739

These errors usually occur when a file goes away between the time its selected for backup and actually gets backed up to tape.

Its a common occurrance, not to be worried about.

Though some portions of /var are important for audit purposes it is not as important as /usr or /etc



SEP

[Elena Leontieva]

Carla,

If in your /var/sam/log/br_log you have Full backup failed with Exit code = 4, you need to apply a patch, then it will say Full backup completed with warnings on ...

Elena.

[Patrick Wallek]

Don't worry about these messages. They are warnings only. I'm almost 100% certain your backups are fine.

The /var/spool/sockets/pwgr directory related to the pwgrd daemon, which is the password and group caching daemon. Do a 'man pwgrd' for more information.

[Sundar_7]

Hi Carla,

As mentined above, pwgr is the passwd & group caching daemon to increase the authetication speed while logging in.

Those are the sockets created by the pwgr daemon. They are selected by fbackup for backup but the socket was closed (and thus the special file was not available) when fbackup attempted to back it up.

So you can safely ignore the messages here.

A better practise woule be not to include /var/tmp & /var/spool/sockets directories in the backup.


Sundar.

[Carla Breuer]

Just a couple of questions before I dole out the points.

Elena, do know what patch(es) I might need? We installed the latest patch bundle here 1 month ago before we went into production on this server.

Can I just remove these files??? The system seems to clear them out itself with a reboot. But I would like to dump them before the backup and see if get a clean one. If that works maybe put this in a script to launch just prior to the nightly scheduled backup. Or is this just wasted work as they really are just garbage?

I agree with Patrick and Steven that the backups are indeed good. Thank you Patrick for explaining where they were coming from and Thank you Steven for explaining why they cause the error.

Carla

[Carla Breuer]

Ok, While I spent all that time typing my latest questions, It would seem that Sundar was reading my mind. Thank you, I will exclude this directory from my backup. The obvious solution was just too easy... Those points are coming now.

Thanx,

Carla

[Patrick Wallek]

Carla,

I don't know that you would gain much by deleting those sockets prior to the backup.

Granted thos files wouldn't be there when the backup started, but if anyone logged during the backup then another socket could get created, thus generating a warning because there was a new file that was seen during the backup.

Sundara's solution would probably be better. Just exclude that dir from your backup. That's pretty easy to do through SAM.

[Steven E. Protter]

I'm quite anal.

I would like my backups to include no messages.

I would like HP to use slightly better language, or show judgement. A critical file in /stand or /usr is much more important than a file in /var

Losing log files is not the end of the world.

It is not a good idea to spend time searching for ways to make this informational message disappear. Any reasonable manager or audit would except these explanations.

Want to spend some time, review your backup strategy.

If you are backing up rdbms databses with fbackup, are the databases down? Otherwise the backups are next to useless.

Are you running regular make_tape_recovery backups so that you can restore vg00 from any kind of problem in a couple of hours? Or restore to an new machine in a DR center in a matter of days?

Thats a good place to invest some time.

Good Luck,

I've enjoyed reading and participating in this thread.

SEP

[Elena Leontieva]

Carla,

For me this problem was due to the fact that the fbackup generated an exit code 4,
and the br_backup script fails because it could not handle the exit code 4. So, the message 'fbackup failed ' was actually misleading, but the backups were successfull.
I applied a quarterly custom patches, so I can not tell which patch fixed this, but that was back in 2000.

So, if you have all the recent patches installed, my advice does not pertain to your problem.