Edit: I'd like to stress only doing this customization if your network really requires you to. The ability to use a script to transfer files off server is preferred over this method of maintaining more backups on the server itself.
Table of Contents:
1. Reasoning
2. Caution
3. Easy Patch (with instructions for applying patch)
4. Unable to download the patch?
5. Editing patch for more days
6. Trigger you should have if you decide to patch
1. Reasoning:
This is for the solo jack-of-all-trades IT / Network Admin, who's responsible for everything. A common symptom of do-it-all role is that if AMP goes down, it may not always be noticed within 4 days. Sometimes AMP isn't even a major priority item to fix at the time of an issue. Knowing that this is sometimes the case, why only 4 back-ups?
2. Caution
The method discussed requires going into the command line to make changes to the code. The applying of the patch will require some AMP downtime. Further, when expanding the number of backups, make sure you have enough disk space to maintain the desired number of back-ups. Often times, you may not have sufficient disk space and should look into a different method for maintaining more backups like an AMP script to copy back-ups to an off server location daily. Check the size of existing backups to see how large the backups are normally. This will help to extrapolate a good estimate for how much space more back-ups will take.
# /ls -lah /var/airwave-backup
3. Easy Patch (with instructions for applying patch):
Attached is a copy of a patch for keeping 7 days of backups (made specifically from AMP 7.6.2 code - may possibly work on other versions, but guaranteed for AMP 7.6.2).
To apply the patch, copy/SCP/FTP the attached file into AMP's /var/airwave/custom directory.
From the CLI:
# cd /root/svn/mercury
# patch --dry-run -p0 < /var/airwave/custom/rotatebackupsfor7days.patch
---this is a test run to see if the patch will apply cleanly
# patch -p0 < /var/airwave/custom/rotatebackupsfor7days.patch
---this is actually putting the code in place
# make
---this is the part that applies the changes to running code
*****Note that if you ever upgrade your AMP code, you will have to re-apply the patch.*****
4. Unable to download the patch?
If you're unable to download the attached patch, here's the contents of the patch for you to copy and paste into a file
#####BEGIN cat /var/airwave/custom/rotatebackupsfor7days.patch#####
Index: scripts/nightly_backup
===================================================================
--- scripts/nightly_backup (revision 68167)
+++ scripts/nightly_backup (working copy)
@@ -23,6 +23,9 @@
$airwave_bin/stopped_amp_data_backup -o \
"$backup_dir/nightly_data.tar.gz"
+rotate 6 7
+rotate 5 6
+rotate 4 5
rotate 3 4
rotate 2 3
rotate 1 2
#####END cat /var/airwave/custom/rotatebackupsfor7days.patch#####
*If you copy and paste this to a notepad document, you may have to run dos2unix and chmod on the patch
# dos2unix /var/airwave/custom/rotatebackupsfor7days.patch
# chmod 777 /var/airwave/custom/rotatebackupsfor7days.patch
-After this, you can apply the patch following the instructions from portion 3.
5. Editing patch for more days
To edit this patch, keep adding 'rotate' lines at the top of the rotate list. With the rotation of the last back-up file as the first line of the rotation. It needs to follow this order to rotate existing back-ups properly. The reason we edit the patch instead of the direct code is because the patch will live in /var/airwave/custom which gets backed up in the back-up files.
If you decide to do this after you've already patched the AMP, the patch won't work without some work. You'll have to revert the previous patch job before you can use the updated patch.
-If the original patch file was untouched-
# patch -p0 < /var/airwave/rotatebackupsfor7days.patch
Example:
[root@rgin mercury]# pwd
/root/svn/mercury
[root@rgin mercury]# patch -p0 < /var/airwave/rotatebackupsfor7days.patch
patching file scripts/nightly_backup
Reversed (or previously applied) patch detected! Assume -R? [n]
---the response here is 'y' to revert.
-If the original patch file was edited-
# svn revert scripts/nightly_backup
Once reverted, continue with patching using the same instructions in portion 3.
6. Trigger you should have if you decide to patch
For all AMPs, I suggest having at least 1 disk usage alert:
Disk Usage. Partition Percent Used >=75%
If disk space fills up quickly, it may be a good idea to also add an 80% or 90% trigger. Once the disk space reaches 100%, the AMP falls over, so be sure to give yourself plent of notice for this.