If using a single backup management group, the UTM setting has no effect. Documented in bug http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=554340.
Question. Do you have just daily backups running currently or are you also performing standard backups (multiple backups per day)? There are two ways to handle this but assuming you just have backups in a single management group, there is a script on the Netapp communities site that will accomplish what you want. However, this is not a great option because it also deletes the backup metadata xml file and the one or two logs required for a clean database shutdown (something that VSS backups do not allow at the time of creation).
The better supported workaround today is to implement multiple backup management groups in a rotation as follows:
Set all standard backups to preserve the up-to-the-minute option, but set all daily and weekly to allow older backups to become point-in-time only. Set the UTM retention option to the last 3 backups.
1) Create a standard backup that runs once per day after heaviest business hours (say 5-7 PM) and keep the last 3.
2) Create a Nightly backup (say midnight-2am) Monday through Friday and keep the last 5.
3) On Saturday, run an additional standard backup at the same time you would have run the normal Daily backup (midnight-2am)
4) Create a Weekly backup on Sundays, and retain whatever number of weeks you would like (in this case 8 weeks)
By following this rotation, the majority of daily logs get purged before the weekly backups run, and only minimal evening mail traffic is retained in the daily backups for an extra 5 days.
On the weekend (Sunday) backup, the additional standard backups before the weekly ensure that only minimal weekend logs for the last 24 hours are retained for the full duration in the longer term weekly retention snapshots.
Using a single backup management group, you would have to retain 1344 hours of logs (8 weeks * 7 daily backups * 24 hours = 1344 hours of log retention). Not good.
Using the rotation proposed above, we retain the sum of:
* The standard backups we trap in the weekly from Saturday to Sunday
(18 hours + 6 Hours + 18 Hours = 42 hours),
* The daily hours we trap per weekly
(8 Weeks * 5 Daily Retained * 6 hours = 240 hours),
* The weekly hours we trap in the weekly
(8 Weeks * 6 hours = 40 hours)
…for a total of only 322 hours of logs retained.
Still more than the 24-48 hours worth that we wanted to keep (but as these are off-peak weekend and evening only logs they are likely to be very small relative to the 1000+ hours of heavy business day log traffic we were able to delete).
The advantage of this approach over the one described in the communities post with the VBS script to delete SnapInfo is that we retain the backup metadata and last few required logs for clean database shutdown replay (not to be confused with UTM restore), so we never have to force a database online using eseutil. This is also a well documented and better supported configuration.
Finally, if you could open up a case with NetApp and let them know that you have hit NetApp bug 554340, that would be a big help as they have a SME release timeline that is contingent on customer cases of this issue and gauging the cost impact to customers of being saddled with these unnecessary logs.
