Backup, Recovery, and Media Services (BRMS) is a great tool for backing up your system and keeping track of what data lives on what backup media. You can quickly look up libraries that you have backed up, see what day they were backed up on, what time, and the volume number they are on. As well, you can look up the times that you’ve backed up the Integrated File System (IFS), and if you tell BRMS to do so, it will keep track of all the objects you have backed up – every single one of them! While being able to look at every backup and drill down to a specific IFS object for a restore sounds FANTASTIC… it does come at a cost: disk space.
Each day, your system should be running BRMS maintenance, which expires any volumes that have reached their expiration date.
When volumes expire, BRMS deletes the records it was keeping on that now expired volume. Because of this, you should also be running BRMS maintenance with a file reorganization as least once a week and at most once a day alongside maintenance (RGZBRMDB parameter in the STRMNTBRM command). The file reorganization will remove deleted records from the BRMS database files, which will return space back to your system.
Where BRMS can often chew away at your disk space is when you have a BRMS backup that runs often, backs up the entirety of the IFS, and then retains that data for a long time due to a long expiration date. Over time, this can cause your BRMS IFS database file (QUSRBRM/QA1ALI2) to swell to an enormous size. To control whether or not BRMS keeps information on IFS backups, you must look in your control groups you are using. Find all the items in your backups that are *LINK (all of IFS) or have a List Type of *LNK (often a subset of IFS data). Take a look at the Retain Object Detail column. If this is set to *YES for these items, then BRMS, by default, is keeping track of everything backed until it is cleaned up during maintenance. This adds up to hundreds of thousands to multiple millions of records per backup.
Retain object detail inside a BRMS control group. A copy of the *SYSTEM control group will have this set to *YES by default.
My recommendation for anyone that has lengthy retentions of daily, weekly, and monthly backups is to set Retain Object Detail for *LINK and *LNK type backups to *NO. If you are a shop that is frequently restoring IFS objects, you may consider setting it to *YES. This will eat up more disk space, but will make restoring IFS objects much faster. Important to note is that not saving the object detail doesn’t mean you can’t restore the data. The data is still there for restoring – it will just take a while longer and you will need to use the native OS command: RST.
Lastly, if you are running very low on disk space, have a large QA1ALI2 file, and need a quick win, consider doing the following:
- Run the SAVOBJ OBJ(QA1ALI2) LIB(QUSRBRM) command to save it to tape or save file.
- Run the CLRPFM FILE(QUSRBRM/QA1ALI2) command.
- Once storage has been increased, restore the file saved in step 1 into a different library, and then use the command: CPYF FROMFILE(new lib/QA1ALI2) TOFILE(QUSRBRM/QA1ALI2) MBROPT(*ADD). This will merge the data from the old QA1ALI2 file with the current data in the QA1ALI2 file in QUSRBRM.
More from this month:
- Obtaining Your Last IPL Details
- Five Costly Mistakes that IBM i Companies Make
- System Cleanup: My QUSRBRM/QA1ALI2 File is Large
- iTech iTip Videos
- Sips & Tricks: Coffee with iTech
- iBasics: IBM i Education for the Beginner System Administrator
- Watch Replay: Tactical Security Day
- Register Now: iAdmin Fall 2022
- iPOWER Hour Episode 40: Security Vulnerabilities on Your IBM i(NEW!)
- Upcoming Events
- IBM i, FSP, and HMC release levels and PTFs (September 2022)