Backing up data from an NFS mount-point is not ideal, but sometimes we don’t have a choice.
There’s a few reasons you might end up in this situation – you might need to backup data on a particularly old system that no longer has a NetWorker client available (or perhaps never did), or you might need to backup a consumer-grade NAS that doesn’t support NDMP.
In this case, it’s the latter I’m doing having rejigged my home test lab. Having real data to test with is always good, and rather than using my filesystem generator tool I decided to backup my Synology NAS over NFS, with the fileshares directly mounted on the backup server. A backup is all well and good, but being able to recover the data is always important. While I’m not worried about ACLs/etc, I did want to know I was successfully backing up the data, so I ran a recovery test and was reminded of an old chestnut in how recoveries work.
[root@orilla Documents]# recover -s orilla 4181:recover: Path /synology/pmdg/Documents is within othalla:/volume1/pmdg 53362:recover: Cannot start session with server orilla: Client 'othalla.turbamentis.int' is not properly configured on the NetWorker Server or 'othalla.turbamentis.int'(if not a virtual host) is not in the aliases list for client 'orilla.turbamentis.int'. 88866:nsrd: Client 'othalla.turbamentis.int' is not properly configured on the NetWorker Server or 'othalla.turbamentis.int'(if not a virtual host) is not in the aliases list for client 'orilla.turbamentis.int'.
Basically what the recovery error is saying that NetWorker has detected the path we’re sitting on/trying to recover from actually resides on a different host, and that host doesn’t appear to be a valid NetWorker client. Luckily, there’s a simple solution. (While the best solution might be a budget request with the home change board to buy a small Unity system, I’d just spent my remaining budget on home lab server upgrades, so I felt it best not to file that request.)
In this case the NFS mount was on the NetWorker server itself, so all I had to do was to tell NetWorker I wanted to recover from the NetWorker client:
root@orilla Documents]# recover -s orilla -c orilla Current working directory is /synology/pmdg/Documents/ recover> add "Stop, Collaborate and Listen.pdf" /synology/pmdg/Documents 1 file(s) marked for recovery recover> relocate /tmp recover> recover Recovering 1 file from /synology/pmdg/Documents/ into /tmp Volumes needed (all on-line): Backup.01 at Backup_01 Total estimated disk space needed for recover is 1532 KB. Requesting 1 file(s), this may take a while... Recover start time: Sun 08 May 2016 18:28:46 AEST Requesting 1 recover session(s) from server. 129290:recover: Successfully established direct file retrieve session for save-set ID '2922310001' with adv_file volume 'Backup.01'. ./Stop, Collaborate and Listen.pdf Received 1 file(s) from NSR server `orilla' Recover completion time: Sun 08 May 2016 18:28:46 AEST recover> quit
And that’s how simple the process is.
While ideally we shouldn’t be doing this sort of backup – a double network transfer is hardly bandwidth efficient, it’s always good to keep it in your repertoire just in case you need it.
I just came across this today also. In our case, this is a NetApp share which has been getting NMDP backups thus far, however there is a securiy requirement to implement encryption in these backups since this is sensitive data and the cloning target is offsite storage across the Internet. So the share is NFS mounting not on the backup server but another host in the protected network with Networker client installed.
The next issue for us is the admin of the host/NFS mount wants to use autofs/automount for this NFS mount at time of access during the backup (as a further security measure). Our test run shows Networker was smart enough to go one layer deep into the designated path for the saveset as expected, but no actual data gets pulled just empty directories. Could be an NFS option, not sure if this could even work?
Hi Joe,
Apologies – I hadn’t noticed your question come in.
IIRC NetWorker doesn’t work with automounts as you’re describing – the data really needs to be mounted up front first.
Cheers,
Preston.