Backup Footprint
{{ totalStorageReadable }}
Coverage horizon {{ coverageHorizon }}
{{ totalBackups }} backup copies Incremental {{ incrementalSizeReadable }} Full {{ fullSizeReadable }} Raw {{ totalStorageRawReadable }} Savings {{ dedupeSavingsLabel }} {{ changeRateLabel }}
copies:
copies:
copies:
copies:
{{ params.changeRatePercent }}%
:1
:1
{{ params.dedupePercent }}%
Tier Frequency Copies Per backup Storage (raw) Storage (net) Coverage Copy
{{ row.tier }} {{ row.frequency }} {{ row.copies }} {{ row.sizePerBackup }} {{ row.rawStorage }} {{ row.netStorage }} {{ row.coverage }}
Total {{ totalBackups }} {{ totalStorageRawReadable }} {{ totalStorageReadable }} {{ coverageHorizon }}
Planner Notes

Use these observations to prioritise storage remediation or policy tweaks.

  • {{ line }}

No insights yet—adjust retention or compression to surface guidance.


                

            


            

                Configure retention targets to estimate backup storage footprint and coverage.
            

        

    

                

                

                    

                        

                            Tags:
                                                            
                                    Automation
                                
                                ,                                                             
                                    Storage
                                
                                ,                                                             
                                    Sysadmin
                                
                                                                                    

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


        
    

        

        

            


                

                    

                    
                


                

                

                
            

            

                
                
            

        

    


    

        

                                                                                                                                                                                                                                                                        
        

            

                
                
                
                
            

            

                
                
            

            

                

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        

                            
                            :
                            
                        

                    

                    

                        
                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                    

                        

                            
                            
                        

                    

                    

                        
                        
                    

                    

                        
                        
                    

                

            


            
        

    



    

        

  

  
Backup rotation is the practice of keeping dense recent restore points and a thinner set of older copies so recovery stays practical without storing every version forever. A retention plan is a trade between recovery point objective, rollback granularity, and storage commitment. Recent copies help with accidental deletion and bad changes from this week. Older copies help when an incident is discovered months later or when a team has to prove what data looked like at a specific time.


  
Grandfather-Father-Son, usually shortened to GFS, is one of the best-known ways to organize that history. The idea is simple: keep frequent short-term points, then preserve selected weekly, monthly, and yearly copies for longer reach. The hard part is not naming the tiers. It is estimating how full backups, data growth, compression, and deduplication change the real footprint once those tiers start to overlap.


  

    Diagram showing daily, weekly, monthly, and yearly backup tiers stretching from recent restore points toward longer archive history.
  


  
A long horizon also does not guarantee the same recovery detail across that whole span. Daily history is usually dense. Monthly or yearly history is much more selective. That difference matters when a team is deciding whether it needs quick rollback for routine mistakes, a legal hold trail, a ransomware recovery buffer, or all three at once.


  
Real backup products add more timing rules than a plain copy count. Some keep the first successful weekly, monthly, or yearly point. Some let one full backup satisfy more than one long-term flag. Some preserve older GFS chains outside short-term retention. A planning model is still useful, but it should be read as an estimate for capacity and policy comparison, then checked against the platform's real retention behavior and restore testing.






  
Technical Details:


  
Retention sizing here starts with two kinds of stored data. Short-term recovery points are treated as incrementals, while weekly, monthly, and yearly history is treated as full backups. Compression is applied first so the model works from stored backup size rather than source dataset size. After that, older tiers are scaled upward with a simple monthly growth assumption so long-lived copies can reflect a dataset that keeps expanding over time.


  
The important simplification is that each tier is priced from an average backup in that tier, not from a day-by-day chain simulation. That makes policy comparison fast and understandable, but it does not reproduce product-specific details such as synthetic full creation, active full scheduling, long-term flag reuse, or the exact rule a platform uses to decide which weekly, monthly, or yearly point is retained.


  

    
Formula Core

    
      
        
          Sinc
          =
          BincCinc
        
        
          Sfull
          =
          BfullCfull
        
        
          G
          =
          1+r100×d/302
        
        
          Ntier
          =
          n×S×G×(1-p100)
        
      
    
    

      

        
        
          

            Symbol
            Meaning
          

        
        
          

            Binc, Bfull
            Entered incremental and full-backup sizes, converted to bytes with binary units.
          

          

            Cinc, Cfull
            Incremental and full compression ratios.
          

          

            r
            Monthly change rate in percent.
          

          

            d
            Coverage days for the tier being estimated.
          

          

            n
            Number of retained copies in that tier.
          

          

            p
            Repository-wide dedupe savings percent.
          

        
      

    

  


  

    

      
      
        

          Tier
          Base size used
          Coverage rule
          What the estimate means
        

      
      
        

          Daily incrementals
          Compressed incremental size
          n days
          Short rollback history for recent file changes, user mistakes, or fast recovery needs.
        

        

          Weekly full
          Compressed full-backup size
          7n days
          Medium-range restore points that reduce dependence on long incremental chains.
        

        

          Monthly full
          Compressed full-backup size
          30n days
          Longer rollback history for investigations, audit support, or slower-moving change control.
        

        

          Yearly archive
          Compressed full-backup size
          365n days
          Very long retention where copy count is small but each preserved full can be expensive.
        

      
    

  


  
Coverage text is intentionally approximate. Days stay in days below two weeks, then roll up to weeks, months, and years using fixed 30-day and 365-day conversions. That makes the output readable for policy planning, but it is not a calendar-accurate schedule. A six-month horizon here means roughly 180 days of reach, not a literal set of month boundaries selected by a live retention engine.


  

    

      
      
        

          Input or rule
          Modeled boundary
          Practical effect
        

      
      
        

          Units
          MB, GB, and TB are treated as binary multiples of 1024.
          A 1 TB entry is interpreted as 1024 GB, not a decimal marketing terabyte.
        

        

          Retention counts
          Negative or fractional values are floored out to whole-copy counts.
          The estimate never creates partial restore points or negative tiers.
        

        

          Monthly change rate
          Cannot drop below 0.
          Older copies can stay flat or grow, but they never shrink from this assumption.
        

        

          Compression ratios
          Minimum effective value is 1.
          The model allows no compression benefit or better, but not expansion disguised as compression.
        

        

          Dedupe savings
          Clamped to 0 to 80 percent.
          Net storage can be reduced heavily, but not to unrealistic near-zero levels.
        

      
    

  


  
Real platforms can still land above or below this estimate because retention is often tied to exact recovery-point selection rules. Azure Backup, for example, keeps the first successful backup of the week, month, or year when those rules are enabled, while Veeam documents that GFS fulls can remain outside short-term retention and can change how backup chains are merged. That is why the result is strongest as a sizing and comparison model, not a byte-for-byte repository forecast.






  
Everyday Use & Decision Guide:


  
The best first pass is to choose the preset that sounds closest to your policy conversation, then overwrite the size defaults with your own numbers before changing any retention counts. GFS 7-4-12-2 is the balanced starting point. GFS 14-8-12-4 stretches weekly history. Compliance 30-12-7-5 pushes hard toward long retention. Cloud snapshot 14-6-6-0 removes yearly archives and keeps the horizon shorter.


  
If your measurements are rough, keep the plan conservative. Enter a realistic full-backup size, set Global dedupe savings to 0%, and compare policies from there. After the storage picture makes sense, add compression and dedupe assumptions. That sequence is safer than starting with aggressive savings and then discovering the repository only fits on paper.


  
    
    
  • Change one variable at a time. Keep the size inputs fixed while you compare monthly and yearly counts so you can see whether policy, not data growth, caused the jump.
    • 
    
  • Read Backup Footprint and Raw together. A plan that only looks affordable after a large dedupe discount deserves another pass.
    • 
    
  • Treat Coverage horizon as the farthest retained point, not as continuous day-by-day history. Long reach and fine restore granularity are not the same thing.
    • 
    
  • Use Capacity Breakdown to find the expensive tier, then open Capacity Trends to see whether weekly, monthly, or yearly copies are driving the slope.
    • 
  


  
After the numbers settle, open Insights to read the built-in planner notes and export the table or JSON only when the assumptions look defensible. If the estimate still feels suspiciously low, rerun the same scenario with dedupe disabled and compare the two totals before you turn the result into a storage request.






  
Step-by-Step Guide:


  
    
    
  1. Pick a Preset that is near your intended policy, or switch straight to Custom if you already know the retention counts you want.
    2. 
    
  2. Enter Daily incremental size and Full backup size with the correct unit. Those two fields anchor every later estimate.
    3. 
    
  3. Set Daily incrementals, Weekly full backups, Monthly full backups, and Yearly archives to match the policy you are considering.
    4. 
    
  4. Open Advanced and adjust Monthly change rate, Full compression ratio, Incremental compression, and Global dedupe savings so the model reflects your environment instead of the preset defaults.
    5. 
    
  5. Read the summary box first. It shows the net storage estimate, raw storage, effective incremental and full sizes, copy count, savings label, and the farthest modeled horizon.
    6. 
    
  6. Use Capacity Breakdown for tier-by-tier review, Insights for the short narrative summary, Capacity Trends for visual comparison, and JSON when you need a machine-readable record.
    7. 
    
  7. If the result area stays empty, make sure at least one retention count is above zero and both size inputs are positive numbers. The planner does not show totals until there is something real to estimate.
    8. 
  






  
Interpreting Results:


  
The headline Backup Footprint is the net estimate after dedupe savings. That number answers the storage-budget question, not the dataset-size question. The nearby Raw badge matters just as much because it shows what the policy would cost before repository-wide savings are applied.


  

    

      
      
        

          Output
          Read it as
          Check again when
        

      
      
        

          Backup Footprint
          Estimated net repository capacity after dedupe.
          The number drops sharply only because dedupe is high.
        

        

          Raw
          Pre-dedupe storage load across all retained copies.
          The gap between raw and net is wider than your platform usually delivers.
        

        

          Coverage horizon
          Farthest retained point among all tiers.
          You need dense daily recovery all the way through that window.
        

        

          Largest row or tallest bar
          The tier contributing the biggest share of net storage.
          A long-term tier dominates more than expected for your stated recovery needs.
        

      
    

  


  
The easiest false-confidence trap is a small net total backed by a very optimistic savings assumption. A second one is a long horizon that looks like complete daily history when it is really a mix of daily, weekly, monthly, and yearly points. Before treating the estimate as final, compare raw versus net and confirm that the tier carrying the most storage is also the tier you actually need.






  
Worked Examples:


  
Balanced GFS starting point

  
The default GFS 7-4-12-2 preset uses a 60 GB daily incremental, a 500 GB full backup, 14 daily copies, 4 weekly fulls, 12 monthly fulls, 2 yearly archives, 5% monthly change, 1.5 full compression, 2.0 incremental compression, and 30% dedupe. That combination produces about 7.9 TB raw and 5.5 TB net with a 2.0-year horizon.

  
The main lesson is not the total. It is that Monthly full dominates the plan at roughly 3.6 TB net. The recent daily history is useful, but it is not where most of the capacity goes.


  
Archive-heavy compliance posture

  
The Compliance 30-12-7-5 preset assumes 100 GB of daily change, a 1.5 TB full backup, 30 daily copies, 12 weekly fulls, 7 monthly fulls, 5 yearly archives, 10% monthly change, 1.4 full compression, 1.8 incremental compression, and 20% dedupe. The estimate rises to about 48.1 TB raw and 38.5 TB net with a 5.0-year horizon.

  
Here the expensive tier moves. Yearly archive becomes the largest share at roughly 17.3 TB net, which is a strong sign that long-retention storage class and offsite strategy matter as much as backup frequency.


  
Troubleshooting a too-good net total

  
Suppose the balanced GFS example above is left unchanged except Global dedupe savings is pushed from 30% to 60%. Raw storage stays about 7.9 TB, but the net estimate falls to about 3.1 TB. Nothing about the retention policy got smaller. Only the assumed savings changed.

  
That is the corrective path when the result feels unrealistically cheap: compare Raw and Backup Footprint, lower dedupe to a value supported by platform evidence, and rerun the same policy before you size storage or approve budget.






  
FAQ:


  

    Does a 2-year horizon mean I can restore any day from the last 2 years?
    
No. The horizon marks the farthest retained point in any tier. Daily history is dense only inside the daily tier. Older tiers become weekly, monthly, or yearly restore points.

  


  

    Why can yearly retention use less space than monthly retention even though it reaches farther back?
    
Because the planner counts copies, not just elapsed time. A small number of yearly archives can cost less than many monthly fulls even though the calendar reach is longer.

  


  

    Do my backup sizes leave the browser?
    
This planner has no tool-specific backend. The estimate, chart, CSV, DOCX, and JSON export are produced in the browser from the values already on screen.

  


  

    Why is the summary still empty?
    
The result area stays hidden until there is at least one retained copy and a positive storage estimate. Check that one or more retention counts are above zero and that both size fields contain valid positive numbers.

  


  

    Why can real backup software consume more space than this estimate?
    
Vendor platforms can keep extra chain data, choose specific weekly or monthly points, or preserve long-term GFS fulls outside short-term retention. Those rules are intentionally simplified here so policies are easier to compare.

  






  
Glossary:

  

    
Incremental backup

    
A backup that stores data changed since the previous protected recovery point.


    
Full backup

    
A complete copy of the protected dataset at a point in time.


    
GFS

    
Grandfather-Father-Son retention, a pattern that keeps short-, medium-, and long-term history in separate tiers.


    
Dedupe

    
Storage savings gained by storing repeated blocks once instead of many times across related backups.


    
Recovery point objective

    
The maximum acceptable amount of data loss measured in time, often shortened to RPO.

  






  
References: