Calculating the rate of change

MountainGoat,

1 - How do I calculate my expected dedupe and compression savings for my first Auxcopy.

I realize this will effectively be copying over an equivalent full backup, since it will be seeding the new library.

50% is  Safe assumption for compression with FileSystem Data.  It does really depend on the nature of that data, though.  A Large number of pdf, and video/audio files for instance would reduce the compression as they are already in a compressed format.  Conversely, if your clients are laden with more text based documents, html or other programming code  for instance you can see far greater than 50%.

From your description it sounds like the new Copy/Copies will be secondary copies in an already existing Policy.  If this is the case you can basically view the Estimated Baseline Size of the Source Copy’s DDB.  (See Example From my Lab).

For the most part the data will dash over to the new copies relatively the same.

Database Agents are an exception to this.  In order for Database Jobs to line up similarly on source and destination Copies you should follow the steps here:  https://kb.commvault.com/article/55258

FYI:  Baseline is calculated from the size of the compressed size of the most recent Full Backup  for all the Associated Subclients plus 20% to estimate Incremental data change.

2 - How do I calculate my future rate of change?

Rate of change is going to be unique from organization to organization, and even from client to client.

It heavily depends on the use case of each subclient and the data which is being protected.

VMs for instance will often have a relatively lower rate of change.  Consider that the OS and program  files for instance will have very little change.

Database and FileSystem can have vastly different change rates, all depending on how often the data/files is changed, updated or deleted on the client end.  

This is why it is easier to estimate based off of already existing jobs. Look at previous Cycles of your jobs and get an average of how much the Incrementals historically need to write.  You also might find instances where certain days of the week historically see heavier change than others.  Again this depends on the production use for the particular clients.

If you are using Traditional Fulls, than you would want to consider the same Incremental rate of change for the subsequent Fulls, since you are likely to have the same daily change from the previous days Incremental to the Full.  Note though that the Full will be able to take advantage of the Dedup data laid down by the previous Full and the subsequent Incrementals.

Synthetic Fulls are easier to calculate.  These are typically 99% savings.  A Synthetic Full is not backing up any new data.  Instead it utilizes the data already written by the previous Full and Incrementals to virtually create a new Full.  

At the moment, I am seeing figures like 15TB written, from an Application Size of 200TB on ALL backups over a seven day period. So that is a pretty good return on savings, but how do I align this to future needs?

The 15 TB written by this job is indicative of any unique data the job needed to write, plus the tiny reference pointers it had to write for data that already existed on the Storage.  This is where the Dedup benefits come into play.

This job saved 185TB of Storage Space due to A.) Compression, and   B.) Some portion of the baseline for that DDB. 

I hope this answers your questions.