Previous  |  Next >  
Product: NetBackup System Administrator's Help  

Policy Planning Guidelines for Backups

Policies allow you to meet the needs of a wide variety of clients in a single NetBackup configuration. However, taking full advantage of policies for use in backups requires careful planning before starting your configuration. The following procedure provides planning guidelines.

  1. Divide clients into groups according to the types of work they perform.
    Clients used for similar tasks usually have a high level of commonality in their backup requirements. For example, most clients in an engineering department create the same types of files at similar levels of importance.
    In some instances, you can create a single policy for each group of clients. In other cases, you will have to further subdivide the clients and cover them in separate policies, based on their backup requirements as explained later in this procedure.
    The table below is the initial grouping for our example. We assume these clients are in the same work group and the initial plan is to cover them all in the same backup policy.
    Clients

    mercury
    mars
    jupiter
    neptune

  2. Gather information about each client. Include information relevant to the backups such as the names, size, and number of files.
    In our example client list, mercury is a file server and has a large amount of data. To avoid excessively long backup times, we include mercury in a separate policy called S1 and the workstations in a policy called WS1. Later, we may find that we need more than one policy for mercury, but we will evaluate other factors first. For now, the backup policies are as follows:
    Policy Clients

    S1

    mercury (file server)

    WS1

    mars
    jupiter (workstations)
    neptune

  3. Create backup policies to accommodate special storage requirements.
    The storage unit and volume pool settings apply to all files that are backed up by the policy. If files have special storage unit and volume pool requirements, create separate policies for them, even if other factors, such as schedules, are the same.
    In the example below, we create a separate policy (S2) for /h002/devexp and /h002/desdoc on mercury because those files go on DLT tape. Other files on mercury go on 8 mm tape. If it is necessary to keep backups for some files on separate media, create a policy that specifies a unique volume pool for those backups. Then, add the media for that volume pool.
  1. Create additional backup policies if one set of schedules does not accommodate all clients and files. Factors to consider are:
    • Best times for backups to occur. To back up different clients on different schedules, create more policies. For example, create different policies for night-shift and day-shift clients. In our example, we can back them all up during the same hours so additional policies are not necessary.
    • How frequently the files change. For example, if some files change very infrequently in comparison to other files, back them up on a different schedule. To do this, create another policy that has an appropriate schedule and then include the files and clients in that policy.
      • In our example (see the next table), we place the root (/) file system on mercury in a different policy (S3). The root(/) file system on the workstations is also in a separate policy (WS2).
    • How long backups have to be retained. Each schedule has a retention setting that determines how long NetBackup keeps files that are backed up by the schedule. Because the schedule backs up all the files in the backup selection list, it is best if all files have similar retention requirements. Do not, for example, include files whose full backups must be retained forever, in a policy where full backups are retained for only four weeks.
      • In our example (see the next table), we place /h002/desdoc on mercury in a different policy (S4). This is done because /h002/desdoc requires full backups every 12 weeks and those backups must be retained for a much longer time than the other files on mercury.
        Policy Clients Files Frequency of Change Desired Storage Auto Backup Frequency

        S1

        mercury

        /usr

        /h001

        /h002/projects

        high

        8 mm

        Daily Incr

        Weekly Full

        4 Weeks Full

        S2

        mercury

        /h002/devexp

        high

        DLT

        Daily Incr

        Weekly Full

        4 Weeks Full

        S3

        mercury

        /

        low

        8 mm

        Daily Incr

        4 Weeks Full

        S4

        mercury

        /h002/desdoc

        high

        DLT

        Daily Incr

        Weekly Full

        4 Weeks Full

        12 Weeks Full

        WS1

        mars

        jupiter

        neptune

        /usr

        /people

        /usr

        /home

        /usr

        /people

        /var

        high

        8 mm

        Daily Incr

        Weekly Full

        4 Weeks Full

        WS2

        mars

        jupiter

        neptune

        /

        /

        /

        low

        8 mm

        Daily Incr

        4 Weeks Full

  2. Create separate policies for clients that require different general attribute settings than other clients. Some attribute settings to consider are:
    • Policy Type. There are several types of backup policies and you must use the correct one for the client. For example, include Windows NT and Windows 2000 clients in an MS-Windows NT policy.
    • Follow NFS. Select this attribute if a UNIX client has NFS mounted files and you are going to back them up from that client. It is also a good idea to use a separate policy for these clients so problems with NFS do not affect the other clients.
    • Cross Mount Points. Select this attribute if you want NetBackup to cross mount points when backing up the files for UNIX or Windows clients covered by this policy. In some instances, you will not want to cross mount points because it will result in backing up too many files---the UNIX root file system is an example of this.
    • Backup Network Drives. Select this attribute to back up files that the client stores on network drives (applies only to MS-Windows-NT policies).
    • Compression. Set this attribute if you want a client to compress its backups before sending them to the server. Note that the time to compress can increase backup time and make it unsuitable to use for all clients.
    • Policy Priority. Use this attribute to control the order in which NetBackup starts its backups. The client in the higher priority policy is backed up first.
    • . In our example, no extra policies are required because of general attribute settings.
  3. Create separate policies as necessary to maximize the benefits of multiplexing.
    Using multiplexing for slower clients that produce small backups is a strategy for maximizing drive utilization. However, higher-performance clients that produce long backups are likely to fully utilize drives and not benefit from multiplexing.
  4. Evaluate total backup times for each schedule and further subdivide your policies to reduce backup times to an acceptable level.
    In our example, backing up /usr, /h001, and /h002/projects on mercury takes too much time so we create a new policy for /h002/projects . This new policy (S5) has the same requirements as S1 but we can now back up /h002/projects separately thus reducing backup time. The next table shows the final set of backup policies.
    In addition to reducing the backup time for each policy, backing up the files with separate policies can reduce the total backup time for the server mercury. NetBackup processes files within a backup selection list serially and in the order they appear in the backup selection list. However, separate policies are processed in parallel if enough drives are available and the maximum jobs attributes are set to allow it.
    Multiplexing and Allow Multiple Data Streams also allow processing backup policies in parallel.

 ^ Return to Top Previous  |  Next >  
Product: NetBackup System Administrator's Help  
VERITAS Software Corporation
www.veritas.com