Forum Discussion

Raek's avatar
Raek
Level 3
4 years ago

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 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.

  • 1st, I think this method not so pretty. Why didn't NetBackup just store these file attibutes in one single file?
  • 2nd, with these millions of small files I got my root directory saturated in inodes, even it still have gigabytes of free space, so no more /.SeCuRiTy.<num> files could be created anymore, and I wonder if this issue has any impact on my restore (e.g.: some files may have wrong attributes).
  • 3rd, is there any way we can configure NetBackup to store these /.SeCuRiTy.<num> files in other partition? Or can we just disable the creation of these files?

Thanks in advance

 

7.7
Solaris

8 Replies

Sort By
  • davidmoline's avatar
    davidmoline
    Level 6
    4 years ago

    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

    • Raek's avatar
      Raek
      Level 3
      4 years ago

      Hello David

      Here are the requested info:

      • The backup type is standard
      • Backup client: Solaris 10 SPARC
      • Restore client: to master server, Solaris 10 SPARC
      • Backed up from NFS (v3 or v4)
      • Restored to other NFS (v3)
      • Backup from GUI with no special options
      • Restore from GUI with no special options but restore in different path
      • /.SeCuRiTy.nnn are generated on restore client which is the master server in my case
      • File content sample:
        cat /.SeCuRiTy.800000
          user::rw-
          group::r--
          other::r--

      Hope this helps

       

  • Nicolai's avatar
    Nicolai
    Moderator
    4 years ago

    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. 

    • Raek's avatar
      Raek
      Level 3
      4 years ago

      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.

      • Nicolai's avatar
        Nicolai
        Moderator
        4 years ago

        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.