Quick question that has been confusing me a bit, I am only using a 1.2TB disk array to hold backups for short periods of time and have retentions set on the storage policies to reflect backups to be retained for something like 15 days. Now, when I browse the CV_Magnetic folder I still see V_## folders from 2 months ago with backup files in them...shouldn't they automatically be deleted after the 15 day retention period or am I just missing a configuration setting somewhere?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Magnetic Retention for Backups to Disk?
- Thread starter Mike00s10
- Start date
- Thread starter
- #3
So as an example of one of the storage policies I have set, under the retention tab:
Enable data aging checked
Enabled managed disk space for magnetic data checked
Basic Retention Rules for all backups:
"retain for 7 days and 2 cycles"
To me this means backups older than 7 days should be automatically pruned, no?
Looking further however since you mentioned "extended rules", under the "CommserveDR" storage policy there are extended rules set, but to my understanding this should only affect the DR backup of the Commvault configuration data?
Enable data aging checked
Enabled managed disk space for magnetic data checked
Basic Retention Rules for all backups:
"retain for 7 days and 2 cycles"
To me this means backups older than 7 days should be automatically pruned, no?
Looking further however since you mentioned "extended rules", under the "CommserveDR" storage policy there are extended rules set, but to my understanding this should only affect the DR backup of the Commvault configuration data?
According to you retention policy, both 7 days and 2 full cycles must be met before the data will age. Are you backing up any SQL clients, and is this version 6.1? If so, I've found that if new databases are created and picked up by the default subclient, then deleted a few days later, that backup job will never be deleted since the contents changed, and therefore will never meet any of the retention policies. This doesn't appear to be the case so far in 7.0 which is a big help.
- Thread starter
- #5
Well 7 days and 2 cycles would be however many days pass between full backups X 2 + 7 days.
So if you backup full daily, than your retention will be 9 days. If you backup full weekly than you retention will be 21 days. If you backup full monthly than you retention will be 2 months and 7 days.
With 7.0 you can finally set retention to days only on a primary copy. This is something that I have been asking for for years. I want to keep my daily backups for 30 days flat. Now I can without having multiple storage policies etc.
Of course for the poor sole that only backs up 1 full and then incrementals for life, well he / she is going to be in a bad position on that 31st day if retention is set to 30/0.
So if you backup full daily, than your retention will be 9 days. If you backup full weekly than you retention will be 21 days. If you backup full monthly than you retention will be 2 months and 7 days.
With 7.0 you can finally set retention to days only on a primary copy. This is something that I have been asking for for years. I want to keep my daily backups for 30 days flat. Now I can without having multiple storage policies etc.
Of course for the poor sole that only backs up 1 full and then incrementals for life, well he / she is going to be in a bad position on that 31st day if retention is set to 30/0.
My primary copy of SQL backups to disk are retained for 3 days 1 cycle with nightly fulls. I aux copy to tape with semi standard retentions (daily full=7d, weekly=30d)
I keep quarterly backups for a year.... but it is sql so if you have to go back more than a month for a production db then you are pretty much hosed already.
I am actually trying to veer away from using a sql agent and get the DBA's to do local disk dumps to a SATA array. Then I would use a FS agent to backup that array.
I proposed that they size it to allow for 1 full 6 diffs and 24hours of tlogs. The DBA's really love the idea because they are responsible for the disk space and the backups. The only time I am involve is when they need to go back farther than a week (hehe see above "Hosed" comment)
This saves us on SQL agent maint and allows them to add more cluster instances without spending more $$ for SQL agents.
I can still point my FS backups for SQL to DASD attached to my media agents (and keep the same retention/aux copy schedule.
I keep quarterly backups for a year.... but it is sql so if you have to go back more than a month for a production db then you are pretty much hosed already.
I am actually trying to veer away from using a sql agent and get the DBA's to do local disk dumps to a SATA array. Then I would use a FS agent to backup that array.
I proposed that they size it to allow for 1 full 6 diffs and 24hours of tlogs. The DBA's really love the idea because they are responsible for the disk space and the backups. The only time I am involve is when they need to go back farther than a week (hehe see above "Hosed" comment)
This saves us on SQL agent maint and allows them to add more cluster instances without spending more $$ for SQL agents.
I can still point my FS backups for SQL to DASD attached to my media agents (and keep the same retention/aux copy schedule.
Enabled managed disk space for magnetic data checked"
I think that's your 'problem'. I haven't used it myself but my understanding is that by enabling that you are essentially saying "my retention settings are a bare minimum - keep as much additional history as there is space for"
The older data will go when the volume is out of space.
I think that's your 'problem'. I haven't used it myself but my understanding is that by enabling that you are essentially saying "my retention settings are a bare minimum - keep as much additional history as there is space for"
The older data will go when the volume is out of space.
- Thread starter
- #9
You think so NATD? I will have to try disabling that option and see what happens. Another question, if I do disable that will it go back and start removing old data or will I have to manually remove the older data that I no longer need?
This is from books online
Managed Disk Space provides a way to prune data according to disk capacity in addition to the existing retention criteria which is usually defined by number of days as well as full cycles of data. This adds another layer of retention parameter in addition to specified days/cycles.
Two disk capacity thresholds for managed disk space can be defined. They are:
A threshold (in percentage) for starting the data aging operation (upper limit)
A threshold (in percentage) for stopping the data aging (lower limit)
When disk capacity reaches a high threshold, e.g., 85%, older data automatically qualify for removal. They are removed from the disk if they meet their retention criteria and have been copied to appropriate secondary copies. The aging process automatically stops when the disk capacity reaches a low threshold, e.g., 70%.
Once the managed disk is set up the process runs automatically without user intervention to manage disk capacity. Data protection operations are retained on disk longer than usual providing the benefits of magnetic storage without having to spend manual efforts to manage the disk capacity.
The Enable Managed Disk Space for magnetic data option is available in the Retention tab of the Copy Properties dialog box. (By default, this option is disabled in all copies.)
The pre-defined thresholds for disk capacity for a magnetic library can be defined in the Mount Paths tab of the Library Properties (associated with a magnetic library) dialog box.
Managed Disk Space provides a way to prune data according to disk capacity in addition to the existing retention criteria which is usually defined by number of days as well as full cycles of data. This adds another layer of retention parameter in addition to specified days/cycles.
Two disk capacity thresholds for managed disk space can be defined. They are:
A threshold (in percentage) for starting the data aging operation (upper limit)
A threshold (in percentage) for stopping the data aging (lower limit)
When disk capacity reaches a high threshold, e.g., 85%, older data automatically qualify for removal. They are removed from the disk if they meet their retention criteria and have been copied to appropriate secondary copies. The aging process automatically stops when the disk capacity reaches a low threshold, e.g., 70%.
Once the managed disk is set up the process runs automatically without user intervention to manage disk capacity. Data protection operations are retained on disk longer than usual providing the benefits of magnetic storage without having to spend manual efforts to manage the disk capacity.
The Enable Managed Disk Space for magnetic data option is available in the Retention tab of the Copy Properties dialog box. (By default, this option is disabled in all copies.)
The pre-defined thresholds for disk capacity for a magnetic library can be defined in the Mount Paths tab of the Library Properties (associated with a magnetic library) dialog box.
- Thread starter
- #11
They are removed from the disk if they meet their retention criteria and have been copied to appropriate secondary copies."
If I am only using backup to physical disk for short durations what would an "appropriate secondary copy" consist of?
If I am only using backup to physical disk for short durations what would an "appropriate secondary copy" consist of?
- Status
Similar threads
- Locked
- Question
- Locked
- Question