Grandfather-Father-Son Backup Storage Calculator
How to use the Grandfather-Father-Son backup storage calculator
This Grandfather-Father-Son (GFS) backup storage calculator shows how much space a retention policy will occupy when daily incrementals, weekly fulls, and monthly fulls all have to remain available together. It is meant for the real planning question backup administrators face: if every restore point must stay online, how large should the repository, cloud bucket, or tape pool be?
What each Grandfather-Father-Son backup term means
In a GFS backup storage calculation, each input answers a different part of the same capacity question. The size fields describe how large one backup copy is, while the retention counts describe how many copies of each tier you keep at the same time.
- Full backup size: the size of one complete backup copy of the protected data set, in gigabytes (GB). In a GFS plan, this is the baseline copy that the weekly and monthly tiers repeat.
- Incremental backup size: the size of one incremental backup (changes since the previous backup), in GB. It represents the changes since the previous backup run and usually makes up the short-term tier.
- Daily incremental copies (Sons): the number of short-term incremental restore points you want to keep. For example, 7 means a week of recent daily recovery points.
- Weekly full copies (Fathers): the number of weekly full backups you retain. These give you medium-term restore points for rollbacks beyond the daily window.
- Monthly full copies (Grandfathers): the number of long-term full backups you keep. This tier usually preserves history across months and is often the main driver of storage growth.
Core Grandfather-Father-Son storage formula
This calculator uses a straightforward capacity-planning rule: each retained backup tier is sized independently, then the tier totals are added together. The weekly and monthly tiers are both full backups, so a longer retention window means another full-copy block of storage rather than a lighter delta copy.
The same GFS storage model can also be checked tier by tier:
Where:
- F = full backup size (GB)
- I = incremental backup size (GB)
- D = number of retained daily incrementals (sons)
- W = number of retained weekly full backups (fathers)
- M = number of retained monthly full backups (grandfathers)
The calculator also breaks the total into three components so you can see where the storage goes:
- Incremental tier storage =
I ร D - Weekly tier storage =
F ร W - Monthly tier storage =
F ร M
How to interpret the Grandfather-Father-Son storage result
The output is the estimated concurrent footprint of the retained GFS copies, not the size of a single backup job. It answers the practical question: if the daily, weekly, and monthly restore points all have to remain online at the same time, how much backup storage is needed?
Use the result for:
- Repository sizing for NAS, SAN, backup appliances, or object storage buckets.
- Budget planning when you need a rough storage cost forecast before procurement.
- Retention trade-offs when you want to see what changes if you increase or reduce a tier.
In many GFS plans the monthly full tier ends up contributing the most capacity because every long-term restore point is another full copy. If your incrementals are unusually large or your daily count is high, though, the short-term tier can become the main driver instead. That is why the calculator breaks the total into three lines: it lets you see which part of the policy is expensive before you change the settings.
To make the result easier to compare with storage products, the calculator reports both GB and TB using decimal units. That keeps the output aligned with common capacity planning language when you are comparing NAS shelves, backup appliances, cloud buckets, or tape libraries.
Worked example: 100 GB full backups, 10 GB incrementals, and 7/4/12 GFS retention
This worked example uses the default values in the form, so you can see how a common GFS policy turns into a storage estimate before you change anything.
- Full backup size F = 100 GB
- Incremental backup size I = 10 GB
- Daily incrementals retained D = 7 (keep 7 restore points)
- Weekly fulls retained W = 4 (keep 4 weeks)
- Monthly fulls retained M = 12 (keep 12 months)
Then:
- Incrementals:
I ร D = 10 ร 7 = 70 GB - Weekly fulls:
F ร W = 100 ร 4 = 400 GB - Monthly fulls:
F ร M = 100 ร 12 = 1200 GB
Total = 70 + 400 + 1200 = 1670 GB โ 1.67 TB.
In this configuration, the monthly full tier dominates the total because every long-term restore point is another full copy. The daily incrementals add useful recent recovery points, but they usually matter less than the number of full copies once the monthly archive grows.
Common GFS retention patterns and storage trade-offs
The right GFS retention settings depend on how far back you need to restore, how often data changes, and how much room you can dedicate to backups. The patterns below are not rules; they are shorthand for different storage priorities:
| Pattern name | Daily incrementals (sons) | Weekly fulls (fathers) | Monthly fulls (grandfathers) | What itโs good for | Trade-offs |
|---|---|---|---|---|---|
| Basic IT default | 7 | 4 | 12 | General-purpose retention with a year of monthly points | Monthly tier can dominate storage |
| Short-term heavy | 14 | 4 | 6 | Frequent recent restores; less long-term history | Higher incremental storage; fewer long-term restore points |
| Compliance-oriented | 7 | 8 | 24 | Longer history and more weekly granularity | Large full-backup footprint; may need tiered storage |
| Lean archive | 5 | 4 | 3 | Minimal capacity usage while keeping a few historical points | Limited rollback options for older data |
Assumptions and limitations for GFS backup sizing
This calculator keeps the math intentionally simple, which makes it easy to use but means it does not capture every feature of a real backup product. Treat the output as a conservative baseline for early planning.
- Full backups are counted independently: weekly and monthly fulls are treated as separate copies. If your product reuses one full as the basis for another tier, the real footprint can be smaller.
- Incrementals are counted on their own: the calculator does not model restore chains or merge operations. Some products may require a base full plus several incrementals to restore one point in time.
- Sizes are constant: one full and one incremental are assumed to be the same size every time. That keeps the estimate easy to follow, but it does not capture data growth or fluctuating change rates.
- No compression or deduplication is applied: real backup platforms often reduce stored size. If your product compresses well, actual capacity may be lower than the calculator shows; if it stores metadata or immutable copies, overhead can push the real requirement higher.
- Retention counts mean concurrent copies: entering 12 monthly copies means 12 monthly restore points are kept at once, not that 12 months of jobs are merged into one number.
Because those assumptions are explicit, the estimate is still useful when you are comparing options or discussing storage budgets. Once the policy is chosen, refine the number with vendor metrics and a few real backup cycles.
Practical tips before you finalize GFS storage
Before you lock the policy, use the estimate to see whether the repository, cloud bucket, or tape pool still has enough headroom for growth and operational overhead.
- Add a safety margin for growth, repository metadata, and file-system overhead.
- Check whether your monthly point is a true full, a synthetic full, or a tagged weekly copy.
- Compare the tier totals before and after a retention change; the biggest savings usually come from the tier with the largest line item.
- Recheck the estimate after major application changes or after the first few backup cycles.
Arcade Mini-Game: Grandfather-Father-Son Backup Storage Planning Calibration Run
Use this quick arcade run to practice spotting the GFS sizing inputs that change the storage estimate most before you rely on the result.
Start the game, then use your pointer or arrow keys to catch useful inputs and avoid bad assumptions.
| Tier | Copies | Size Each (GB) | Total Size (GB) |
|---|---|---|---|
| Daily Incremental | |||
| Weekly Full | |||
| Monthly Full |
GFS backup planning works because restore requests usually arrive by tier: a recent change needs yesterday's incremental, a broader rollback often needs last week's full copy, and older incidents may depend on a monthly archive point. Turning those possibilities into separate size lines gives you a practical number instead of a vague retention target.
The tier breakdown is especially helpful when one part of the policy starts to dominate capacity. If the monthly archive is the largest line item, that is the place to look first when you need savings. If the daily incrementals are growing instead, the issue may be change rate rather than retention count, which points to a different kind of review.
The calculator assumes that every retained full backup is the same size and every incremental backup is the same size. That keeps the math transparent, but it also means the number should be treated as a baseline. When the protected data set grows, the same retention counts will require more room even if the policy never changes.
Because of that, it is smart to revisit the estimate whenever your environment changes. A larger file set, a heavier database, a new application, or a longer retention mandate can all shift the storage picture quickly. The form is meant to give you a planning number, not a promise that remains accurate forever.
The result also helps you think about restore behavior. A policy with many recent incrementals gives you fine-grained recovery points for day-to-day mistakes, but long-term history depends on the weekly and monthly full tiers. If older recovery points matter more than frequent rollbacks, the calculator makes it clear which settings deserve attention.
Different storage back ends solve the same problem in different ways. Local disk arrays, cloud object storage, and tape libraries each have their own cost profile, retention mechanics, and operational quirks. Once you know the retained GFS footprint, you can decide where the copies should live and how much spare room to leave for verification, staging, or duplication.
Security and retention go together as well. Every additional backup copy is another object that must be protected, indexed, and verified, so a storage plan is also a protection plan. If your backups are encrypted or immutable, remember that those controls can affect overhead even though the calculator focuses only on backup data size.
If your design includes an off-site duplicate of the same backup tree, treat the calculator's total as the baseline for one retained set. A second location, a replication target, or a staging area adds to the broader architecture, so the final design often needs more capacity than the single-set estimate shown here.
When vendor compression or deduplication is available, compare those reported numbers with this estimate after a few backup cycles. That gives you a practical view of how close the simple model is to production. Some environments shrink dramatically, while others stay closer to the raw stored size because the data changes in ways that are hard to compress.
In short, the Grandfather-Father-Son backup storage calculator turns retention planning into a visible capacity plan. It shows what each tier costs, which tier dominates, and how a small adjustment in daily, weekly, or monthly retention can move the overall storage requirement up or down.