Because the limits database can be a sparse file, be careful when copying it. The file will most likely consume a lot of disk space if it is written by a utility that does not support sparse files, since the empty regions of the file will read as sequences of zeros and be written back out as real blocks instead of empty regions. This could happen if the file were being copied, backed up, or restored by a utility such as tar(1), cpio(1), or cp(1), although programs such as ufsdump(1M) and ufsrestore(1M) will preserve holes.
You can also back up and restore the limits database by using limreport to generate an ASCII version of the file and using limadm to re-create the original file from that saved ASCII version. For example, the command:
# limreport 'flag.real' - lname preserve > /var/tmp/savelnodes
will create /var/tmp/savelnodes as an ASCII representation of the lnodes for each user in the password map. Note that this will not save lnodes for which there is no corresponding password map entry. At most, lnodes should exist for the set of all UIDs in the password map.
# limadm set -f - < /var/tmp/savelnodes
recreates the lnodes for which data was saved. This command will not delete lnodes that were not saved, so these techniques can also be used to save and restore selections of lnodes rather than the whole limits database.
The limreport and limadm Commands describes the use of the limreport and limadm commands in more detail. It is helpful for the administrator to be familiar with using these commands to save and restore lnodes, since it may be necessary to use them when a change to the interpretation of the lnode structure (as defined by the limits database) is made.
Because the contents of the limits database are changing regularly during normal system operation, perform backup operations while the system is quiescent, or in single-user mode. Similarly, restore an entire limits database only when the Solaris Resource Manager is not in use, such as when the system is in single-user mode.