Well, i guess the "cannot map" stems from us not backing it up in a Veeam job (with Snapshot/SnapVault), but only run it on Netapps side and then for restores just select a Storage Snapshot that Veeam scanned.
Technically, sure, this could easily be mapped, but i did not really expect Veeam to do it because we don't use Veeam itself for the backup process in this case.
Indexing and mlocate: Yes this does work with SLES/OES! I had it running, indexing worked - but that requires a "Veeam Backup Job" without storage integration (so doing real copies
As soon as you configure the Snapshot/SnapVault/use SnapVault as Source, in the next job-config sections you can not select "guest file indexing" anymore.
-> And Veeam Backup jobs are soooo much less efficient than just a Netapp SnapVault, so we decided to completely ditch Veeam for this part.
To get mlocate running with SLES11 SP3/OES11, i did this:
- Code: Select all
downloaded mlocate-0.26-64.1.x86_64.rpm from http://download.opensuse.org/repositories/server:/search/SLE_11_SP3/x86_64/
rpm -i mlocate-0.26-64.1.x86_64.rpm
UPDATEDB_PRUNEPATHS -> had to remove /media, because our NSS Volumes are mounted below /media/nss/
Now, that works for Veeam, but as we don't use Veeam for this, i run a cronjob just for the NSS Volume with /usr/bin/updatedb --localpaths=/media/nss/VOLUME/
I then harvest the resulting /var/lib/locatedb to a central repository (sorted by OES server, with date/timestamps), se we can search for files manually.