The first time I got a PC with a hard drive I remember thinking, “10 MB is more than I’ll ever need.” Aside from just now disclosing that I began my career in the days of punch cards and floppy disks (where did the time go?), it illustrates something I’ve come to believe:
Disk storage is like closet space. No matter how much you have, it inevitably fills up.
So with this adage as a backdrop, I’d like to discuss several features and techniques to help you optimize space utilization on your Axcient appliances. First we’ll look at something called retention dialing, followed by tips specific to image backups, and finally how to handle rolling backup files.
Retention settings can have a dramatic impact on how much storage is consumed. It’s easy to set backup retention values beyond the capacity of an appliance without knowing it – that is, until the appliance fills up and backup jobs start failing.
It’s impossible to know the perfect settings to maximize retention within storage limits because it’s difficult to accurately predict the rates of data change and data growth. However, there are things you can do to dial in your retention settings and achieve a viable steady state.
First, consider enabling Auto Prune Detection, which can be found under System->Tools in the Axcient Unified Management Console (UMC). When available space is too small, auto-prune allows a backup job to temporarily override normal retention, which prunes the oldest data to reclaim enough space for the backup to complete. If using this feature, it’s advisable to also monitor the event AUTO_PRUNING, which fires when an auto-prune occurs.
If auto-prune routinely kicks in or if you’ve run out of space on the appliance, then it’s time to review your retention settings. These settings are located under Disk Utilization -> Retention Management in the UMC dashboard. This brings you to a “wall of sliders”, which lets you tune retention settings across multiple jobs while instantly receiving visual feedback on potential storage consumption. Using this tool, you should be able to achieve a steady state that strikes a balance between retention needs and available storage.
Since system image backups capture entire volumes, they tend to be large. Here are some space-saving tips to consider when utilizing image backups:
- File restore from image. System image backups let you fail over a server on the Axcient appliance or perform a bare metal restore of a server or workstation. But did you know you can also restore individual files and folders from an image backup? So, if you want to save some disk, consider employing only an image backup schedule. This will reduce your storage footprint while still achieving both file-level and image-level protection.
- Refresh interval. Each image backup produces a restore point in the reverse incremental chain, which consumes space. If your objective is to keep a fresh image handy for failover without storing frequent restore points, then set a “refresh interval” in the backup specification. For example, rather than running an hourly backup that produces 24 restore points per day, run a daily backup with an hourly refresh. Doing so produces only one restore point per day, which is kept fresh so that a failover is never more than 60 minutes out of date.
- Exclusions. When specifying the parameters for an image backup in the UMC, you can click the Advanced Options link to select files and directories to be excluded from the image. This is a handy way to omit unnecessary data from consuming storage, such as a scratch directory full of temporary files. But take care not to exclude any files that are needed by the operating system or applications, as doing so may render your backup image unusable.
Rolling Backup Files
A somewhat non-intuitive gotcha is the handling of rolling backup files, such as a daily database dump. Let’s use an example to illustrate.
An application generates a sequentially numbered database dump file for backup; say, db01.bak, db02.bak, db03.bak, etc. The difference between successive files may be small, but because they have unique names, the Axcient backup treats each as a brand new file. As a result, a full copy of every file is stored in the Axcient backup chain.
A simple technique for handling this circumstance is to rename the generated rolling backup file to a common file name prior to the backup run. So, in our example, rename db01.bak to something like db-latest.bak. The next day, rename db02.bak to db-latest.bak. And so on.
The Axcient backup then stores only the changed blocks of data within each incremental backup of db-latest.bak. Of course, you’ll need to make sure the original rolling backup files are either excluded from the backup specification or deleted from the system being backed up.
I hope you find these suggestions helpful for freeing up some “closet space” on your Axcient appliances. Perhaps you have additional ideas you’d like to share?