How to estimate space needs
- Find the total combined size of a Full restore point (VBK) from each of the Backup jobs that will be included in the Backup Copy job. (X)
Note: You may end up with a slightly smaller copy job due to compression and deduplication of similar blocks, but it’s preferable to plan for more.
- Determine how many full backups you’ll have: (Y)
- One full for the regular retention
- One full for every Weekly, Monthly, Quarterly, and Yearly GFS archival point
- Add one more full for the overhead needed while GFS backup is being made. (Y+1)
- Multiply that total (Y+1) by the size estimated for a full backup (X). Ensure your repository has space for at least this much data, and a bit more for incrementals/variance in data.
A Backup Copy job is created to offsite restore points from two onsite Backup jobs. A Full restore point (VBK) from the first job is around 750GB and a Full restore point (VBK) from the second backup job is 500GB. Adding the two together, 1.25TB should be accounted for the combined full created by the Backup Copy job, and a minimum of another 1.25TB should be allowed for the merge.
The same two local Backup jobs have a combined daily rate of change of 170GB (Local Backup 1, on a given week, has increments sized 100, 120, 100, 150, 125, and 175GB for an average of 128.334~ and Local Backup 2 has increments of 50, 40, 55, 30, 45, and 30GB for an average of 41.667). If the backup copy job will retain 14 points, allow at minimum 14 * 170GB or 2.38TB for increments. Given that one cannot consistently predict rates of change, it’s best to plan for the largest restore point.
In this example GFS retention is disabled, the backup copy repository should have:
[1.25TB (full)] + [1.25TB (merge overhead)] + [2.38TB (incremental points*14)] = 4.88TB
If we add GFS retention of 4 monthly points, those four full restore points add 4 * 1.25TB = 5.0TB. In this case we would need:
[1.25TB (full)] + [5.0TB (GFS points)] + [1.25TB (merge overhead)] + [2.38TB (incremental points)] = 9.88TB
As a general rule, a bit of additional space is recommended for unforeseen issues. Insufficient sizing for a merge can lead to running out of space, and if a copy job repository ends up with insufficient space to perform a merge—and subsequently is filled with more increments than specified by retention—the only recourse in almost every case is to clear the repository and let the copy job start with a new full, or provision more space for the repository if it is scalable.