NetWorker 9 introduced a new, pure HTML5 web interface for the File Level Recovery interface for VBA, which works much the same way as the v8.x FLR, just without Flash.
However, it also introduced nsrvbaflr, a command line utility that comes with the base NetWorker client install, which can be used on Linux or Windows virtual machines to execute file level recovery from VMware image level backups.
Hang on, I hear you say – VMware image level backups are meant to be clientless, so does that mean I have to start installing the client software just for FLR? Well, actually – no.
A NetWorker Linux client install will include the nsrvbaflr utility in /usr/sbin, and this is a standalone binary. It doesn’t rely on any other binaries or libraries, so in order to use it on a Linux VMware instance, all you have to do is copy the binary across from a compatible client install. Since my NetWorker server (orilla) is a Linux host itself, that’s as simple as:
[Mon Jun 27 14:23:16] [• ~ •] pmdg@ganymede $ ssh root@orilla root@orilla's password: <<password>> Last login: Mon Jun 27 12:25:45 2016 from krynn.turbamentis.int [root@orilla ~]# scp /usr/sbin/nsrvbaflr root@krell:/root root@krell's password: nsrvbaflr 100% 5655KB 5.5MB/s 00:00
With the binary copied across FLR is only a step away.
The nsrvbaflr utility can be run in interactive or non-interactive mode. I wanted to try it out in interactive mode, so the session started off like this:
[root@krell tmp]# nsrvbaflr -bash: nsrvbaflr: command not found [root@krell tmp]# /root/nsrvbaflr VBA hostname|IP: archon.turbamentis.int Successfully connected to VBA: (archon.turbamentis.int) vmware-flr> locallogin Username: root Password: <<password>>
I then had a bit of an exercise in debugging. You see, I’d finally rebuilt my home lab recently and part of that involved spinning up a whole bunch of individual virtual machines running CentOS 6.x to takeover functions previously collapsed to a single machine. So I’ve got independent Mail, Wiki and DNS/DHCP servers, and of course I accepted the defaults on most of those systems leaving me with ext4 filesystems, which the base VBA appliance can’t handle. This, of course, I’d forgotten. So of course, when I then tried out any command that would access the filesystem of a backup, I had this happen:
vmware-flr> cd root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup browse request failed. Reason: (Unknown) vmware-flr> pwd Backup working folder: Backup root vmware-flr> ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup browse request failed. Reason: (Unknown)
After a little while wearing a thinking cap again, I remembered the ext4 limitation, so I quickly provisioned a VBA Proxy within my home lab. (If you review the documentation for NetWorker VMware Integration, this is fairly clearly spelt out. Dolt that I was, I forgot.) Once that proxy was deployed, things went a whole lot more smoothly:
[root@krell tmp]# /root/nsrvbaflr VBA hostname|IP: archon.turbamentis.int Successfully connected to VBA: (archon.turbamentis.int) vmware-flr> locallogin Username: root Password: <<password>> Successfully logged into client: (/caprica.turbamentis.int/VirtualMachines/krell) vmware-flr> backups Backups for client: /caprica.turbamentis.int/VirtualMachines/krell Backup number: 54 Date: 2016/06/27 01:56 PM Backup number: 53 Date: 2016/06/27 02:00 AM Backup number: 52 Date: 2016/06/26 02:00 AM Backup number: 51 Date: 2016/06/25 02:01 AM Backup number: 50 Date: 2016/06/24 02:00 AM Backup number: 49 Date: 2016/06/23 02:01 AM Backup number: 48 Date: 2016/06/22 02:00 AM Backup number: 47 Date: 2016/06/21 02:01 AM Backup number: 46 Date: 2016/06/20 02:01 AM Backup number: 45 Date: 2016/06/19 02:01 AM Backup number: 44 Date: 2016/06/18 02:01 AM Backup number: 43 Date: 2016/06/17 02:01 AM Backup number: 42 Date: 2016/06/16 02:01 AM Backup number: 41 Date: 2016/06/15 02:01 AM Backup number: 40 Date: 2016/06/14 02:00 AM Backup number: 39 Date: 2016/06/13 02:01 AM Backup number: 38 Date: 2016/06/12 02:01 AM Backup number: 37 Date: 2016/06/11 02:01 AM Backup number: 36 Date: 2016/06/10 02:00 AM Backup number: 35 Date: 2016/06/09 02:01 AM Backup number: 34 Date: 2016/06/08 02:01 AM Backup number: 33 Date: 2016/06/07 02:01 AM Backup number: 32 Date: 2016/06/06 02:01 AM Backup number: 31 Date: 2016/06/05 02:01 AM Backup number: 30 Date: 2016/06/04 02:01 AM Backup number: 29 Date: 2016/06/03 02:01 AM Backup number: 28 Date: 2016/06/02 09:05 AM Backup number: 27 Date: 2016/06/02 02:01 AM Backup number: 26 Date: 2016/06/01 02:01 AM Backup number: 25 Date: 2016/05/31 02:01 AM Backup number: 24 Date: 2016/05/30 02:01 AM Backup number: 23 Date: 2016/05/29 02:01 AM Backup number: 22 Date: 2016/05/28 03:08 PM Backup number: 21 Date: 2016/05/28 02:00 AM vmware-flr> backup 53 Backup: (53) selected. vmware-flr> cd root . . . . . . . . . . . . . . . . . . vmware-flr> ls Folder: root Folder: .ssh 4 KB 2016/06/02 09:08 PM Folder: bin 4 KB 2016/06/07 11:09 PM File: .bash_history 4.9 KB 2016/07/20 07:58 AM File: .bash_logout 18 B 2009/06/20 10:45 AM File: .bash_profile 176 B 2009/06/20 10:45 AM File: .bashrc 176 B 2004/10/23 03:59 AM File: .cshrc 100 B 2004/10/23 03:59 AM File: .tcshrc 129 B 2005/01/03 09:42 PM File: anaconda-ks.cfg 1.5 KB 2016/06/02 08:25 PM File: install.log 26.7 KB 2016/06/02 08:25 PM File: install.log.syslog 7.4 KB 2016/06/02 08:24 PM 2 Folder(s) 9 File(s) vmware-flr> add install.log Path: (root/install.log) successfully added to the recover queue. vmware-flr> targetpath Enter "." to set working folder: () as the target path or enter an absoulte path. path: tmp Target path successfully set to: (/tmp) vmware-flr> queue Recover queue: root/install.log vmware-flr> status VBA host: archon.turbamentis.int VBA version: 1.5.0.159_7.2.60.20_2.5.0.719 Local user: root Source client FQN: /caprica.turbamentis.int/VirtualMachines/krell Selected backup: Backup #: 53 Date: 2016/06/27 02:00 AM Backup working folder: /root Recover queue: root/install.log Target client FQN: /caprica.turbamentis.int/VirtualMachines/krell Target working folder: Client root Target path: /tmp vmware-flr> recover . The restore request has been successfully issued to the VBA. vmware-flr> quit [root@krell tmp]# ls /tmp/install.log /tmp/install.log
That’s how simple FLR is from VMware image level backups under NetWorker 9. The same limitations for FLR in terms of the number of files and folders, etc., apply to command line as much as they do the web interface, so keep that in mind when you’re using it. Beyond that, this makes it straight-forward to perform FLR for Linux hosts without needing to launch X11.
Hi Preston,
thank you for this great review, what do you think is the reason for the missing ext4 support?
Is it the SLES version emc uses in the VBA which may has no ext4 support in the kernel?
Best Regards
Andy