Forum Discussion

laguns97's avatar
laguns97
Level 4
4 years ago

Includes files / Exclude_list - help for AIX clients

Hi,  we are with Netbackup 8.1.1


We have 2 classes for our AIX servers, one for the OS (SYSUX) and the other for the rest of FS (PRDUX).

Currently we have includes files with more than 1000 lines for PRDUX and this is causing a problem (Old NB administrator) He wanted to make sure not to forget FS for all the clients of the PRDUX class.

We would like to improve this by using the excludes files. I would like your comments on how we could do this as simply as possible. We must continue to use these 2 classes.

Here's what we thought of:
The includes file for the SYSUX policies would contain "/", "/ usr", "/ var", "/ opt", in short, the FS which are specific to the OS.
For the includes of the PRDUX class, we will put only "/" and having an exclude_list.PRDUX on the clients containing the FSs listed of the SYSUX class and checking the "Cross mount point" option. This does not work because of the "/" found in the exclude_list.PRDUX. If I remove it, it works except that I backup the data from "/" which is already taken in the SYSUX class. Do you have any ideas for me?
Thank you for your help.

I don't know if my explanation is understandable, I tried my best for the English translation

8.1.2
AIX

7 Replies

Sort By
  • jnardello's avatar
    jnardello
    Moderator
    4 years ago

    When setting up your backups try to remember the administrative overhead you're creating as well. If you can handle backing up a client using one policy instead of two you're not only saving the Master processing time, but your own time in having to manage the extra policy. Unless you have a very environment-specific reasoning for it I would HIGHLY recommend cutting the OS backups to a single policy. If the client is also running a database or application that also requires an agent backup, fair enough, but otherwise do your best to get everything under one umbrella. For the same reason, ALL_LOCAL_DRIVES is your friend. Manual management of your policy filelist is a giant time-sink - avoid it and automate things if at all possible. Backing up " / " is a really old legacy config from back in the dark ages - avoid it if at all possible. =) Typically when it's recommended by someone it's because of an NFS share that requires backing up (which would not be considered a local filesystem), yet the first question that ought to go through your head when that's brought up is, "why am I backing that up via NFS and not NDMP ? " 

    As far as include/excludes go, while they can get extremely complex again, keep it as simple as possible. Also keep in mind how the Master will process those files - traverse the entire client according to the policy filelist, build the backup list, then apply the include and exclude lists; if you have a giant include/exclude list you could be looking at a significant time sink for each job that runs on that box before any actual backups start happening. Keep those files as short as possible - skip /tmp/, application dedicated temp directories, live database directories that are backed up using your agent policies, things like that. 

    Since every environment is different and you're probably better off just nuking the setup entirely and starting from scratch if you're not sure how things will really run. Set up a basic ALL_LOCAL_DRIVES policy, get rid of those include/exclude files, and run a full. How long does it take ? Did it include everything that's needed? Now tweak it - add some basic excludes, rerun a full, and see how it does. Any better ? 

    It's a learning process sometimes but standardization, simplification, and automation will pay off in the long run. 

    • laguns97's avatar
      laguns97
      Level 4
      4 years ago

      Thank you for your answers. In the case where we have a cluster, if we take ALL_LOCAL_DRIVE, this will cause us to take the duplicate data on the members of the cluster for the shared folders or file system. In this situation, how would you proceed?

      • jnardello's avatar
        jnardello
        Moderator
        4 years ago

        If you're concerned about trying to remember 5 years later which of your several nodes the data might have lived on for a restore you can always have one policy covering the cluster nodes' OS info, and a second policy that points to a virtual hostname associated with all of your cluster data that fails around. Set up a basic exclude so the OS policy doesn't pick up the cluster data and you should be good. Of course, you ABSOLUTELY want to confirm after the first backup that each policy is picking up what it should (and only what it should) - it really sucks finding out 6 months down the line that your exclude accidentally also applied to the cluster data policy too. This also requires the app owners to let you know when they add in a new cluster filesystem, although hopefully you'll also notice that when your node OS backups suddenly go from half an hour to 12 hours. 

        i.e.
        Policy #1 = mycluster.OS
        Clients = node1 physical name, node2 physical name
        Filelist = ALL_LOCAL_DRIVES
        exclude_list.mycluster.OS = /myapplication/*

        Policy #2 = mycluster.data
        Client = cluster virtual hostname (which in some larger cases ought to point to a VIP that fails back and forth between the backup NICs on your physical nodes)
        Filelist = /myapplication/*

  • Tape_Archived's avatar
    Tape_Archived
    Moderator
    4 years ago

    laguns97 why only two classes?

    Managing classes is way easier than managing the exclude list on each client. Creating policy for common backup inclusion makes the job more easier for admin.

    How many clients do you have in each of these policies (classes )?

  • Nicolai's avatar
    Nicolai
    Moderator
    4 years ago

    hi laguns97 

    There is in my opinion two ways to do this - generic not related to your current setup. 

    Files selection /
    Cross Mountpoints: yes
    Exclude Files: exlude_list.{Policy Name}
    Best for : Tape based backup as each job will contain all data from all file systems. No data will be lost because backup always start with the root file system.

    Files selection : ALL_LOCAL_DRIVES
    Cross Mountpoints: no
    Exclude Files: exlude_list.{Policy Name}
    Best for : disk based backup, each job will be a file systems - e.g /var /usr /opt
    Comment: ALL_LOCAL_DRIVES works the same was as on Windows, where a list of files system are identified before backup start. This way no file systems will ever miss a backup. 

    A include list of 1000 lines to me sounds very prone to errors. Exclude list on the other side should well defined, specific and short so all admins can comprehend. With specific I mean, don't do *.dbf but instead /data/oracle/*/*.dbf - specify the full path of what you want to exclude.

    Best Regard
    Nicolai