Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

flashbackup fails invalid snapshot method

Created: 06 Sep 2012 • Updated: 06 Sep 2012 | 7 comments
This issue has been solved. See solution.

Hi all,

We've been kicking the tires on flashbackup for a few weeks now trying to get it running on a RHEL5 media server which is also the client in this case. None of the methods appear to be valid - tried nbu_snap, vxfs, vxvm, auto, and none work. The master is running 6.5.6 - and no, we cannot upgrade to 7 today. We used to use flashbackup under 6.x using the nbu_snap method so I basically copied one of those old policies to a new one, set the client to the media server, configured up a cache volume on a dedicated disk, as well as set the directive to the correct /dev/vx/rdsk volume. The logs in bptm,bpfis and bppfi don't seem to have the missing clue. I installed the snapshot client option on this media server and rebooted. I see these in bpfis:

 06:06:50.029 [4386] <2> bpfis main: received FIM as [48] nbu_snap:cache=/dev/vx/rdsk/vx_cache/vx_cachevol
06:06:50.030 [4386] <4> bpfis: INF - BACKUP START 4386
06:06:50.030 [4386] <2> bpfis main: receive filelist:<NEW_STREAM>
06:06:50.030 [4386] <2> bpfis main: receive filelist:</dev/vx/rdsk/lrstesting/lrsdata>
06:06:50.031 [4386] <2> bpfis main: receive filelist:<CONTINUE>
06:06:50.034 [4386] <2> onlfi_vfms_logf: INF - TimeFinder FIM $Revision: 1.54 $
06:06:50.041 [4386] <2> vnet_connect_to_vnetd_extra: vnet_vnetd.c.182: msg: VNETD CONNECT FROM x.x.x.x.52689 TO x.x.x.x.13724 fd = 6
06:06:50.072 [4386] <2> vnet_vnetd_service_socket: vnet_vnetd.c.2048: VN_REQUEST_SERVICE_SOCKET: 6 0x00000006
06:06:50.072 [4386] <2> vnet_vnetd_service_socket: vnet_vnetd.c.2062: service: bprd
06:06:50.074 [4386] <2> logconnections: BPRD CONNECT FROM x.x.x.x.52689 TO x.x.x.x.13724
06:06:50.283 [4386] <2> get_long: (2) premature end of file (byte 1)
06:06:50.283 [4386] <2> bprd_read_text_file: get_string() failed, Input/output error (5), premature end of file encountered
06:06:50.288 [4386] <4> bpfis: INF - FIS_ID=backup104_1346929608
06:06:50.288 [4386] <32> onlfi_process_fs_list_dev_entry: FTL - Invalid snapshot method nbu_snap
06:06:50.288 [4386] <16> bpfis: FTL - process_fs_list() failed, status 20
06:06:50.288 [4386] <4> bpfis: INF - EXIT STATUS 20: invalid command parameter
06:06:51.852 [4402] <2> logparams: bpfis delete -nbu -id backup104_1346929608 -bpstart_to 300 -bpend_to 300 -clnt backup104 -S master
06:06:51.853 [4402] <4> bpfis: INF - BACKUP START 4402
06:06:51.853 [4402] <32> fis_rebuild_from_db: FTL - cannot open /usr/openv/netbackup/online_util/fi_cntl/bpfis.fim.backup104_1346929608.0
06:06:51.853 [4402] <4> bpfis: INF - EXIT STATUS 0: the requested operation was successfully completed
 

I can't tell what the invalid command parameter is since the "validation" never displays what the issue is, other than of course none of the methods seem to be valid.

And, I have these open and are trying to decrypt the secret decoder phrase all along:

Vertias NetBackup Snapshot Client Quick Start Guide

Vertias NetBackup Snapshot Client Admistrator's Guide

NetBackup Snapshot Client Configuration

thanks!

Comments 7 CommentsJump to latest comment

Mark_Solutions's picture

Have you tried setting the snapshot method to auto - increase your logging levels on the media server and then try it again and see what bpfis logs as it tries each method

I am surprised that the policy validation did not fail when you saved it but the actual backup does - is the Media Server on the same version as the Master? Have you installed the Enterprise Client license on the media server itself? (use the license utility on the Media Server)

Hope this helps - post the results (as text file attachments please)

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

schrammd's picture

Yeah, I should have made it more clear. The auto setting does try all the methods, but it does fail the validation (I simply tried ignoring the validation test to get the logs). I turned up the logging on the client (which is the media server with the local Vx disks). The media and master are both 6.5.6. Now, as far as the media server license - I thought the licenses only go to the master. We have an enterprise client in the master already, and I assumed that without it, selecting flashbackup from the list would not be possible. Maybe I'm missing something.

thanks

Mark_Solutions's picture

My thinking is that this is running on the Media Server so it may want the license - Enterprise Disk is similar and needs the key on the Media Server - usually, as it is a normal client doing it it doesn't expect a key as you cannot put one on a client - it was just a thought that as the client is the media server it may be having a "moment" as NBU sometimes does.

Please post some screen shots of your policy so that we can see the attributes and snapshots options sections

Thanks

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

schrammd's picture

Linux land (open office). Hopefully you can open the attachment.

thanks

AttachmentSize
screenshots.odt 65.97 KB
Mark_Solutions's picture

I know you have read the guide but i just clocked that this is on RHEL and the snapshot guide does say:

The nbu_snap snapshot method is for Solaris clients only. It is for making
copy-on-write snapshots for UFS or VxFS file systems.

I think only the vx_fs or vx_vm will be available - if you are using Veritas filesystem / volume manager on the media server

Hope this clears it up - even if it doesn't help!

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

SOLUTION
schrammd's picture

Dang, missed that. I set it to vx_fs and configured in the vx cache path and it passed the validation check. Sweet. Thanks Mark. I guess the "auto" isn't so auto is it? 70MB/sec is far better than the 2-4MB/sec it was getting without FlashBackup. We will be upgrading real soon, but at least we have a basis to start from.

Thanks for the rapid replies - I really appreciate these forums.

 

Mark_Solutions's picture

Great stuff - and yes, something specific is always better than auto!

Glad to have helped

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.