Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Change backup_dir to point to an NFS mount due to tar/gzip load?

This thread has been viewed 0 times
  • 1.  Change backup_dir to point to an NFS mount due to tar/gzip load?

    Posted Mar 07, 2013 11:54 AM

    Running AMP 7.5.4 on CentOS 5.9

     

    My sys admin is noticing large CPU utilization during the nightly backup tar and gzip cron jobs. He wants to point the backups to a NFS mount and possibly NOT run the tar/gzip process since we have plenty of disk space on the NFS mount.

     

    His words: "Is it kosher to modify the nightly backup script directly or can/should that be done through the Airwave web interface?  The main thing I'd like to do is change backup_dir to point to an NFS mount.  Additionally, we may want to disable the tar/gzip process to reduce the load on storage, but that would be a more invasive change."

     

    Possible? Problematic? Anyone else doing this or have a better/different idea?



  • 2.  RE: Change backup_dir to point to an NFS mount due to tar/gzip load?

    EMPLOYEE
    Posted Mar 07, 2013 12:25 PM

    The best way to do this would be to replace /var/airwave-backup folder with a symlink to the destination mount (this is the recommended method for users offloading their data to a SAN - though in the case of a SAN, we offload the entire /var directory).  I suggest trying this in a lab environment to prevent any disruption to the production environment - to make sure it's accomplishing what you desire.

     

    Logistically, what are the size of your regular backups?  The tar process is known to take a while, but it's done in the background.  The CPU portion is most likely from the tarring of the linear RRD data (used for graphs), you can probably get a good idea of how much work is being done by getting a count of files in /var/airwave/rrd (recursive count to include the subfolders = 'find . -type f | wc -l').  Also, 7.6 has been very stable, any plans to upgrade?  Likewise, we've moved from Cent5.5 to Cent6.2 with plans to discontinue Cent5 support in 7.7 (http://community.arubanetworks.com/t5/AirWave/AMP-7-7-will-discontinue-support-of-CentOS-5-RHEL-5/m-p/63784#M1472).

     

    The key is to test a backup to make sure that the symlink data persists.  To do this, after you create the symlink change, run nightly_maintenance (the majority of nighly maintenance is run in the background, but a test run should either be done early before users amass, or later when users have gone for the day).



  • 3.  RE: Change backup_dir to point to an NFS mount due to tar/gzip load?

    Posted Mar 07, 2013 01:44 PM

    Thanks, Rob.

     

    We have  52103 files in /var/airwave/rrd/ and our regular backups are usually around 800MB tar'd and gzip'd.

     

    Yes, we plan on moving to 7.6 and Cent6 in the next few weeks. We also plan to move from dedicated HW to virtualized.

     

    My sys admin thought your suggestion was "definitely a workable solution".

     

    We are trying to determine what our platform / os / sw upgrade path should be.

     



  • 4.  RE: Change backup_dir to point to an NFS mount due to tar/gzip load?

    EMPLOYEE
    Posted Mar 07, 2013 02:35 PM
    upgrade path should be:
    1. 7.5 -> 7.6 upgrade (currently 7.6.3), leave up/running
    2. setup VM installed with upgraded AirWave version (all 7.6 ISOs have Cent6.2)
    - this will handle both the move to VM and OS upgrade
    3. Force backup on original server, copy that backup to the new VM install
    4. Restore
    5. Redo data offload settings if you still want to offload backups to another NFS mount
    6. Point controllers to send traps to the new VM instance
    7. Have both instances running until you've confirmed that the new server is operating well