2/7/2024 0 Comments Novell filr account![]() "Cannot map VM files to any existing VM in the virtual infrastructure"Īnother tradeoff to using storage snapshots: We can not run guest file indexing, instead i had to script our own guest file indexing with updatedb/locate.Īgain, as noted in other threads, this is a shame, as all the processing can also happen when taking storage snapshots! And I think I even saw the "guest file indexing" work being done when using snapshot orchestration, just the updatedb/locate-files are not saved anywhere for later use.īecause of the tradeoffs, using "Veeam Storage Snapshot Orchestration" was dropped, we simply run Netapp Snapshot/SnapVault like before.Īll controllers are added to Veeam and Volumes/Snapshots get scanned, so we can just select individual Snapshots to run restores from. If i try to restore from a from secondary storage snapshot (SnapVault target), the error is: Why? Because we use (Netapp) storage snapshots of our Novell OES Fileserver datastores (each fileserver has its own VMware Datastore/Volume on Netapp). Sadly we can not use the "Restore" function but must use the copy-to-workaround. I'll see what I can dig up on exactly how we're copying the data back to the OES server and see if it would be possible to leverage xattr to eventually get permissions restored, too. Permissions still aren't restored, but since restore to original location is working, that's one step closer to possibly getting permissions restored someday. I'm not sure why you didn't see your restored data appear immediately so that may be worth troubleshooting.Īt any rate, no need to send a movie as I definitely believe you. And using the OES client from a workstation, after I restored anything once I hit F5 to refresh my Windows Explorer window I saw the restored files/folders show up immediately. In my testing I restored individual files and entire folders. We need to remove the line stating "You also cannot restore files directly to the original location from NSS filesystems." I will ask to get the documentation updated. I was surprised to see I could use the restore option in VBR to restore to the original location! This is new behavior from how it used to be. Everything was done with 9.5u1 and OES 2015 SP1 with three different volumes (32-bit non-AD-enabled, 32-bit AD-enabled, 64-bit AD-enabled). With the support, the NSS volume shows up.īut to what you've been mentioning, I did some testing again in my lab. If you were to try FLR with 9.5 (before Update 1) against OES 2015 SP1 where that feature had been enabled, the Backup Browser window wouldn't even display the NSS volume. ![]() What that's referring to is the ability to do any FLR activity at all on a volume with Trustee Index enabled. I helped put the wording together for the OES 2015 bullet point in the release notes. ![]() Oh trust me I know what's in the 9.5u1 release notes. ![]() There should be an "easy" solutions allready as other backup vendors can use the novell advanced file attributes when backing up such machines with normal Linux agents.įor my understanding, when Veeam would "restore" the "tadata" correctly back to the nss volumes, oes should recognize the permissions and other settings again! I only get the restored folders and inherit the permission from the parent, no special permission (trustee index) or special parameters like "rename locked" etc. I do want to restore permissions, attributes and quotas too! this doesn't look like to work! with OES2013 i got some cryptic error when dooing file-level recovery. Veeam 9.5 update 1 release notes indicate that file-level recovery from NSS volumes with Trustee Index enabled, works with OES 2015SP1, i do have tested this now and it looks somehow good. I'm currently evaluating Veeam B&R (9.5u1) so recover Files from Novell NSS volumes!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |