Growth from Backups

Overview

Every full backup writes down how much data it contained. Nobody reads that column as a time series, and it is the only long record of database size that exists on an instance where nothing was ever monitored.

On a server that has been running since 2019 with a nightly full, this page has around two thousand size samples per database. The historic database has none, because the historic database starts the day somebody configured it.

The Growth from Backups page: database size as a time series from full backups
The whole page in the Fastest growing view. Nineteen databases measured from their own full backups, growing 315MB a month between them.

Where to find it

Expand a server in the tree, expand the msdb database, then MSDB → Growth from Backups.

What it measures, said out loud

Used data, not file size. That is the more useful of the two for this question, and it has to be stated plainly: a database whose files were grown to 500 GB and holds 80 GB reads as 80 GB here, and 80 GB is the number that will grow.

If you want the file size, that is Files for a Database and File Size Over Time.

Only full backups are size samples

A log backup measures churn since the last log backup. A differential measures change since its base. Charting either as size draws a sawtooth that means nothing at all.

That is why this page reads type D and nothing else.

The projection

A straight line through the first and last samples.

It is deliberately the simplest thing that could work. Anything cleverer would be a forecast, and a forecast off backup sizes is a number somebody would put in a capacity plan.

The grid gives it as A month and In a year so that the arithmetic is visible rather than implied.

The two views

View What it ranks
Fastest growing Databases by rate of change. The planning view.
Biggest now Databases by current size. The inventory view.

Reading the chart

The bars: databases ranked by the rate between their first and last full backup
The sample count and the span sit under each name for a reason: three of these have a single full backup each, so no rate is claimed for them at all.

One bar per database, ranked by the straight line rate between its first and last full backup, with that rate as a month on the right.

A database with too little history to support a rate is drawn at zero and labeled not growing, rather than given a number from two samples that would sit in the list looking like the others.

The bars draw the top thirteen of the nineteen. The grid holds them all.

Reading the grid

The grid: samples, what it was, what it is now, and the projection
Was, Now, a month and in a year, so the arithmetic behind the projection is visible rather than implied. The colored verdict is the database that has more than doubled since its history starts.
Column What it is
Database The database.
Samples How many full backups the size series is built from. A series of two samples is not a trend, and the count is there so you can see that.
First measured The date of the oldest full backup here.
Was Used data at that first sample.
Now Used data at the most recent one.
Change The difference, and the share.
A month The straight line projection one month out.
In a year The same line, twelve months out.
Verdict What this rate means, and whether the sample count supports saying it.

The toolbar

Control What it does
Fastest growing / Biggest now The two views.
Backup ledger Opens Backup Ledger.
Backup speed Opens Backup Speed, because a growing database is a lengthening backup.

Where the data comes from

dbo.backupset, filtered to type = 'D', reading backup_size and backup_finish_date per database.

Databases that are no longer on this instance still have history in backupset, and they are included with their state marked, the same way Backup Ledger treats them.

Messages you may see

There is no full backup history to measure. Only full backups record a size worth charting, and msdb holds none. A log backup measures churn and a differential measures change, so neither can stand in for one.

Report Why you would go there
Backup Speed What this growth is doing to the backup window.
Backup Ledger Whether the history behind these samples is complete.
File Size Over Time File size rather than used data, from the historic database.
Disk Space What is left on the drives these databases live on.
Files for a Database The current files, their sizes and their free space.

Frequently asked questions

This disagrees with the size in the tree. Because the tree shows file size and this shows used data. A database with a lot of free space inside its files reads smaller here, which is correct for the question this page asks.

My database shrank. Either somebody archived, or somebody ran a shrink, or the backup was of a different database with the same name restored over it. The Restore History page settles the third.

Why not fit a curve? Because a curve fitted to two thousand nightly backup sizes would look authoritative and would still be a guess about somebody’s business. The two point line is honest about what it is.

A database appears with one sample. It has been backed up once. The Samples column says so and the projection columns stay blank.