01-24-2021 10:24 AM
Hello
We have Veritas NetBackup 7.7.3 on Solaris 10.
When trying to restore a directory containing millions of files, NetBackup creates extra millions of /.SeCuRiTy.<num> files (as many as the restored files) in the root directory, they are very small files containing just file attributes of the restored files, and they seems to be used by NetBackup to change file attributes after restore.
Thanks in advance
01-24-2021 01:52 PM
Hi @Raek
This seems strange behaviour and I have not seen this before (but may have missed this before).
If noone else can suggest a fix, can you supply the follwing information.
What is the backup type you are restoring and where is it being restored to - what other options have you set in the GUI or the command line? What are the file system types for the original backup and the restore destination also? Is the restore client also Solaris 10?
Are the /.SeCuRiTy.nnn files being generated on the restore host or the master server?
Cheers
David
01-24-2021 10:42 PM
Hello David
Here are the requested info:
Hope this helps
01-25-2021 02:48 AM - edited 01-25-2021 04:34 AM
Hi @Raek
I had a faint memory of this from past times, and found this thread
https://vox.veritas.com/t5/NetBackup/restore-by-bprestore-command-fails-with-status-2826/m-p/418353
To me this does look like a issues with different file systems types and owners.
If Netbackup cannot find/set a user during restore, I have some memory about Netbackup restoring those files as belonging to the root user for maximum security. This could explain why files are being written to root directory.
01-25-2021 04:57 AM
Hello Nicolai
Thanks for your feedback.
Yes the /.SeCuRiTy.nnn files seem to be related to ACLs as mentioned in your article, and I guess they are stored by NetBackup when it can't set destination file's ACL. Below output from user_ops logs.
08:59:29 (4310795.001) Changed /SrcNFS/file1.tar.gz to /DstNFS/file1.tar.gz
08:59:29 (4310795.001) Unknown file type ''' for .SeCuRiTy.9, extracted as normal file
08:59:29 (4310795.001) ACLs of /DstNFS/file1.tar.gz restored to .SeCuRiTy.9
My restore completed successfully and with the right files' user/group id even if there were no more inodes for NetBackup to create the /.SeCuRiTy.nnn files.
So my probleme is just the fact that NetBackup eats all inodes of my root directory and leaving the system in a bad situation, so I have to manually cleanup these millions of files all time during restore operation.
I hope to find a good explanation of this strange behavior and a solution or workaround to fix it.
01-25-2021 06:35 AM - edited 01-25-2021 06:47 AM
Hi @Raek
Unknown file type ''' for .SeCuRiTy.9, extracted as normal file
A idea to explain what you are seing, if the backup source is a normal file system, but exported as NFS, then the file system ACL's are recorded by Netbackup during backup operation, becuase the file system is considered a normal file systems and not NFS. But when the data is then restored to a NFS share, then the ACL cannot be applied and you will see the extracted ACL files in the root folder.
As a workaround, set root home directory temporary to a file system large enough to handle the SeCuRiTy files ( I don't know if that is possible on Solaris).
On the backup source, try running the Netbackup command bpmount, to see what file system type Netbackup think it is.
01-25-2021 06:55 AM
Hello Nicolai
Thanks for your feedback.
I confirm the source FS that was backed up from source client is a NFS. It is not a local filesystem exported as NFS.
When I run bpmount the output doesn't show my source mountpoint since it is NFS. The command shows local FS only.
I think the workaround of increasing root FS may work but it is too heavy operation as workaround, since my root FS is UFS and can't be extended online. It must be backed up, recreate volume/FS then restore.
Deleting the /.SeCuRiTy.nnn files with a cronjob is lighter workaround. I'll still search for a better solution however.
01-25-2021 08:47 AM
Hi Nicolai
Sorry for my mistake but after doublecheck I found that source client is Red Hat.
That explains the incompatibility with ACLs and the generation of /.SeCuRiTy.nnnn files.
01-25-2021 08:53 AM
Hi @Raek
That is the cause, cross OS restore is not supported, even though both clients are using policy type "standard".
Glad I could help :)
Best Regards
Nicolai