Space Requirements for Backup Copy Jobs

If the repository is insufficiently provisioned, or retention is configured to cause the job to retain more point than the storage can contain, enforcement of retention can fail. This can lead to the repository having not enough free space. If the repository runs out of space, and retention cannot be enforced successffuly the restore points may likely be put into an unrestoreable state. When this occurs, the most common outcome is that existing restore points must be removed from storage and a new backup chain must be started. 

Note: Backup Copy job retention when GFS is enabled is handled differently than normal Backup Jobs. For more information please review this section of the Use Guide.

The important thing of note is that when GFS point creation takes place, there will be an "extra" Full restore point (VBK) file on the disk until the operation is complete and retention enforcement deletes the oldest GFS restore point. For GFS retention, every Weekly, Monthly, Quarterly, and Yearly backup is itself a Full restore point (VBK).

For Synthetic GFS method, it utilizes a temporary file. For Active Full GFS method, an extra VBK will be kept in the repository until the end of the job run.

As a result, users are strongly advised to plan ahead for the addtional space required.

 

How to estimate space needs

1. 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.
2. 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
3. Add one more full for the overhead needed while GFS backup is being made. (Y+1)
4. 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.

Example:

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.