IDC Logo

Veeam #1 Worldwide in
Data Recovery & Protection in 2H'22

LEARN MORE

Space Requirements for Backup Copy Jobs

KB ID: 2207
Product: Veeam Backup & Replication
Version: All
Published: 2016-12-19
Last Modified: 2020-08-13
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please try again later.

Challenge

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. 

Cause

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.

 

Solution

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.

To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.