stan wrote:
> On 02 4, 2010, at 2:21 AM, tkimball wrote:
> 
> > 
> > Yes, recover *should* have given me back a garbage file (when not running 
> > under -p), but it did not.
> > 
> > I had a Sun engineer on the phone yesterday, and through a webex stepped 
> > him through my test case (below) on a 'fresh' client.  The test file (in 
> > the webex, /etc/inet/hosts) did not recover as garbage when the passphrase 
> > was left out.
> > 
> > Their guess (from the wording in manual) is that aes asm only works for a 
> > server-started (savegrp) backup.  Since we're using a client-started backup 
> > (save) its not really happening, even though 'save -v' shows the aes asm 
> > being used.
> > 
> > I've asked them to confirm this behavior with EMC.  My personal feeling 
> > about this is that its a bug, one that normally does not affect many 
> > people.  In our case though, this is a serious problem - over 2/3 of our 
> > data backups are client-run.
> > 
> > The test client used in the webex is group-run, so I left the below 
> > /etc/.nsr in place for testing during his next Full backup (over the 
> > weekend).
> > 
> > For now, I'm exploring other options, including pre-crypting the files 
> > through our backup script (before save is run). 
> > 
> 
> 
> NetWorker's aes encryption is good only as a last resort. If you can, why not 
> push out your client initiated backups to your NetWorker server via savegrp 
> in a shell script. This should get you what you want.
> 


This has been resolved.  Recover does not need a passphrase if you're 
recovering a backup that matches what the server is using currently.  Once you 
change it, and run recover for an older instance of a passphrase, the 'correct' 
behavior occurs (you have to enter it).

There is the problem of Networker not giving any feedback (during a backup) 
that the AES asm was in use.  There is an RFE already open for this, which is 
LGTpa37197.  EMC's workaround (forwarded by Sun) is to test this periodically 
by changing the passphrase and attempting a recovery with no phrase; Empty 
files should be recovered.

---

Side note...

In order to implement Stan's suggestion above, I'd have to have a separate 
group for each Sybase server, running a probe-style backup (actually two groups 
for each server, due to how our Sybase dumps work and the retention for each 
type of dump).

This sounds OK in theory.  But, we have over 30 of these systems to manage (at 
one point it was over 40), and the backup times on each vary wildly each night, 
over an 8-hour period.

I can now imagine several folks on the list turning white at the above, and 
would not blame them.  :)  Manual backups are actually the easier way to handle 
the problem, compared to this, and is doing the same thing really.

--TSK

+----------------------------------------------------------------------
|This was sent by t.s.kimball AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER