Too many /.SeCuRiTy.xxxxxx files
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 rest...
Forum Discussion
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.
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.
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.
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.
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.
