Networker

Re: [Networker] Are you sure your savepnpc backups are good?

2004-04-16 12:29:27
Subject: Re: [Networker] Are you sure your savepnpc backups are good?
From: Davina Treiber <Treiber AT HOTPOP DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Fri, 16 Apr 2004 17:27:41 +0100
David E. Nelson wrote:

Well, I don't think it's a bug .... IMHO, just a poor way of doing things -
especially not reporting what has occured.  My thoughts are that since NW is an
_enterprise_ product, it should act as one and take measures so that surprises
are encountered later on.

Agreed. savepnpc in general is a poor way of doing things.

I've worked with savepnpc for a long time, I implemented it for the
customer it was designed for. Even then it needed a lot of work to make
it do what it was supposed to do. It was even more buggy then than it is
now, and we had several workarounds in place.

Given a requirement to implement a pre and post processing function for
a backup, why would you choose to give the client the whole task of
handling this? I don't think I would. Would you design it so that you
had to edit files on the client to configure it? Neither would I. The
server knows where the backup is up to and what is completed, why should
the client have to continuously query the server to obtain this
information? The whole design is flaky to say the least.

Here is my idea of how it SHOULD have been designed:

* There would be two new attributes in the client resource on the
server, called precmd and pstcmd. The values in these would take the
same format as the backup command attribute, and would have the same
restrictions on naming and file location so that the commands specified
could be run using the nsrexec mechanism and with no NetWorker changes
necessary on the client. These fields would be incorporated into the GUI.

* When the group runs, these two commands (if present) are included as
save sets in the work list. There would need to be dependencies as
follows between save sets for any one client:

successful pre-command --> filesystems --> post command --> index,
however I would think this is possible since the functionality already
exists to handle special save sets that need to be done in order, e.g.
index and bootstrap.

* If the pre command fails, the rest of the save sets for that client
would be removed from the work list. This is easy to do from the server.
There is only one shot at the pre-processing, unlike with savepnpc where
if it fails it will be attempted as many times as the number of save
sets multiplied by client retries.

* The post command output would be sent to the normal group completion,
unlike with savepnpc where it is detached and goes down a black hole.

* A timeout could be incorporated as with savepnpc (another new field in
the client resource?). Personally I don't think it is essential but
customers like it. On timeout, savegrp could optionally kill running
saves and remove others for this client from the work list, this is
something that customers would like, and is difficult to do from the
client with savepnpc - much easier if controlled from the server.


There is obviously a strong requirement for pre and post processing with
backups, the amount of discussion on this list is evidence of this (or
is it just because savepnpc is so troublesome?). So I wonder why such a
poor job has been done of implementing this. What do others think?

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=