IBM Tivoli Storage Manager, Version 7.1

File space tuning

Using Tivoli® Storage Manager virtual mount points can enhance the performance of backup and restore operations on file systems that contain millions of files.

On many operating systems that Tivoli Storage Manager supports, you might be able to use file system or operating system tools to divide the file systems into manageable units, such that each file system can be protected in an acceptable backup or restore window.

On AIX®, HP-UX, Linux, and Solaris operating systems, the Tivoli Storage Manager virtualmountpoint option can be used to logically divide a large file system into smaller increments. Virtual mount points are a Tivoli Storage Manager construct. Virtual mount points are not recognized by the operating system as mount points; they are only recognized and used by Tivoli Storage Manager.

When it protects objects that are contained under a virtual mount point, Tivoli Storage Manager treats each virtual mount point as a separate file space. Creating virtual mount points can enhance performance in the following ways:

Less memory is needed for client operations because the virtual mount points divide a large file system into smaller increments, and processing fewer objects uses less memory.
Tivoli Storage Manager can do more work in parallel, by running concurrent backup or restore operations on objects that are under two or more of the virtual mount points.

Using virtual mount points to improve performance works best if each of the virtual mount points has approximately the same number of files. If you cannot divide your file system in this way, virtual mount points might not be a suitable means to improve performance.

To illustrate how to use virtual mount points, assume that a client has a large file system called /data. Also, assume that the /data file system has multiple subdirectories that you want to frequently protect.

You can use the virtualmountpoint option to create virtual mount points that divide the /data file system into manageable logical units, such as shown in the following example:

virtualmountpoint /data/dir1
virtualmountpoint /data/dir2
.
.
virtualmountpoint /data/dir19
virtualmountpoint /data/dir20

These example virtualmountpoint options create 20 virtual mount points for the /data file system. The objects (dir1, dir2, and so on) that are shown on the example virtualmountpoint statements are directory objects on the file system. When objects in these directories are stored on the server, they are stored in a file space that matches name of the objects that are included on each virtualmountpoint statement. That is, objects in dir1 are stored in file space named dir1, and so on.

You can back up and restore objects in each virtual mount point, independently of the others, and independently of other objects that are not in a virtual mount point. Any objects that get added to the /data file system, but that are not under a virtual mount point, are protected when you back up the objects in the /data file system. Objects that are under a virtual mount point are protected when you back up the virtual mount point.

If you use virtualmountpoint options, monitor the growth of the physical file system. If many new objects are added to the physical file system in locations that are not defined as logical mount points, it might eventually be easier to abandon the use of the virtual mount points and just backup the entire file system.

If you intend to use virtual mount points to divide the contents of a large file system, be aware that adding virtual mounts after a file system has been backed up can change the command syntax that is needed to restore objects.

For example, assume that you back up the /data/dir1/file1 object before you create any virtual mount points. The /data/dir1/file1 object is stored on the server in the /data file space. Assume that you later create a virtual file space by setting virtualmountpoint /data/dir1 and that you create and back up a file1 object in it. This new file1 object is stored on the server in the /dir1 file space (the file space matches the virtual mount point name).

Running dsmc restore /data/dir1/file1 restores the file1 object from the copy that is stored on the server in the virtual mount point (dir1) file space.

To restore the file1 object that was saved in the /data file space, you must use the following syntax:

dsmc restore {/data}/dir1/file1

The brace ({ and }) characters force the server to search the /data file space for the file1 object.

Consider the following items if you use virtual mount points to create addition file spaces on the server:

For applications that use the Tivoli Storage Manager API, limit the number of file spaces to no more than 100 per client. Examples of programs that use the API are IBM® Tivoli Storage Manager for Virtual Environments, IBM Tivoli Storage Manager for Mail, IBM Tivoli Storage Manager for Enterprise Resource Planning, and IBM Tivoli Storage Manager for Databases.
For sequential-accessed storage pool volumes, collocate files by node or group, rather than by file space. For example, 100 small file systems require 100 volumes if they are collocated by file space, but fewer volumes are needed if the files are collocated by node or group.

Feedback