We’re considering changing our storage retention policy from 1 year to something less than that and we’d like to know how much storage we’d reclaim by making this change *before* making this change (to see if its even worth it). Is there a report that could tell us this? Or how could we best gauge the effects on our back-end storage of changing our storage retention policy from one year to, say, six months?
- Vaulter
- 266 replies
-
2 May 2024
Hello
I am assuming you are using Dedup in this case. I would recommend looking at the "baseline” size of your data that is listed here:
This information is amount of space for 1 full cycle of your environment if you were to start again.
From here you would add you rate of change per cycle to understand loosely how much data you write each job.
Once you know this can you then figure out how many cycles you are cutting and get an estimate on how much space you will get back.
please note that this will be an estimate and most likely will be a much smaller number than you expect. The thing with Deduplication is it takes a long time to fill the storage up but also takes just as long to clear up. Backups after the first backup tend to only be 10% of the size if not smaller when it comes to impact on disk.
Kind regards
Albert Williams
- Vaulter
- 46 replies
-
7 May 2024
You can also use this report to make sure judgement
The report will provide details as follows
-
Backup jobs that are on each media or disk volume
-
Backup jobs that either exceed their retention criteria or need to be retained
-
Media that can be recycled and a list of media that cannot be recycled based on the copy retention
-
The amount of disk space that is freed and kept for each storage policy copy
-
An estimated date, including the time zone, on which a job is due to be aged
-
Reasons why data was not aged
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.