Review: Veeam Backup & Replication v8 - Backup jobs

In my last post, I talked about different ways to set up the infrastructure that will power your Veeam Backup & Replication backups. There are a lot of moving parts, from the server itself to the repositories and proxies, necessary to efficiently use the product. Now that all of that is out of the way, in this post I’m going to cover a lot of the options you have in configuring the three major protection job types: backup, backup copy, and replicas. Each of these has its own wrinkles, so settle in.
Follow me

Backup jobs ^

Veeam offers a number of ways to back up data, each of which has its advantages and disadvantages, so a decision of which one to use needs to be made based on both the source and destination of the backup data. Keep in mind that all of these methods are going to start with what’s called an active full backup, which will be an all-in backup of whatever data you want to back up. Where it gets interesting is how we deal with changes after that. Simply put, here’s when to use what:

  • Forward incremental: Traditional; good for basic backup and tape
  • Reverse incremental: Good for disk-based, local backups
  • Forever forward incremental (FFI) backup: New default; good for backups over the WAN

Now let’s look at why we choose these type-to-scenario pairings.

Forward incremental backups ^

For those who are used to working with traditional backups, this strategy will seem the most familiar. With forward incremental backups, you start with a full backup and then changes from one backup cycle to the next are backed up via changed block tracking. In a vSphere environment, the changes can be seen by looking in a virtual machine (VM) folder on the data store after the initial backup has been performed in the form of CTK files. When an incremental job is run, this CTK file is what is actually backed up and then rolled back into the parent .vmdk file.

Forward incremental backups

Forward incremental backups

In a typical forward incremental job, either an active full or what’s called a synthetic full backup is performed weekly to keep the number of active increments to a manageable level. A synthetic full backup is a pretty neat concept: a period of incremental backups are synthetically meshed to form the equivalent of a full backup, just without the full hit on the network and storage.

There are a couple of downsides to a forward incremental job. The biggest is in regards to adherence to retention policy. Because a traditional forward incremental job with periodic full backups requires there to always be a full backup prior to the increment that needs to be restored, a restore point will not be dropped from the backup chain until there is a supporting full backup behind it. For example, if you have a 7-day retention policy that starts on Wednesday and your synthetic full backup occurs on Saturday a week from Friday, you will have 9 restore points, and only after the synthetic operation occurs on Saturday will you return to the 7 restore points dictated by policy.

Another issue is in the case of an immediate need restore. You have a VM blue screen overnight and it is determined that you need to restore from backup. In order to restore this VM, the VBR server is going to have to merge both the full backup and all the increments between that full backup and the point where you need to restore to in order to present you with a complete picture of the data, an operation that takes time. Although using regular full backups—either active or synthetic—will mitigate most of this time, it still isn’t as quick as being able to restore last night’s data from a full backup.

Reverse incremental backup ^

The reverse incremental backup provides you the ability to always have last night’s backup as the full backup. For this reason, this is the recommended backup type for disk-to-disk backup scenarios.

Reverse incremental backup

Reverse incremental backup

So how does it work? The reverse incremental backup does a synthetic full backup during every run, merging the new incremental into the full backup each time. Because it only has to do a single merge, this operation is relatively quick. Further, with reverse incremental backups, you have the option to do synthetic rollbacks, so as you move your synthetic full backup along the chain, it backs out each day’s incrementals behind it. It is highly recommended that you also create weekly synthetic full backups here as well, otherwise you will find yourself having to do multiple merges anytime you have to restore anything from a past point in time.

The downside to the reverse incremental backup is that there is an increased level of processing required each night, resulting in a need for greater resources on the Veeam server. Further, you do not want to address these jobs directly offsite; rather, you can use the reverse incremental backup locally in conjunction with a backup copy job to ship the data offsite.

Forever forward incremental backup ^

Last but not least is the newest option, the forever forward incremental (FFI) backup, made available in version 8 of Backup & Replication. In a forever forward backup, there is always only a single full backup, the first in the backup chain. As the backup chain hits the specified retention policy, the full backup merges in the increment immediately before it and discards the last increment retained in the full backup. For me, the simplest way to grasp this concept is to think of it is as a reverse reverse incremental backup.

Forever forward incremental backup

Forever forward incremental backup

This job type was brought about to fix the issue of forward incremental backups not being able to always meet the job’s retention policy while still being resource efficient. While FFI backups will give you the same CPU processing hit as a reverse incremental backup, it is still able to ship only the smallest amount of data in the traditional backup bottlenecks of WAN connections and tape writes. For this reason, FFI is the type of choice for backup copy jobs and any other operations which are bandwidth sensitive.

Backup copy jobs ^

Finally, the last thing we’ll cover here is backup copy jobs. So you have your backups set up for a local repository in the type of your choice, but now you need to get a copy of that data somewhere offsite. The old way to do this was to either a) have two separate jobs with two separate snapshot points—one local, one remote—or b) use rsync, or something like it, to replicate the data in the onsite directory to somewhere offsite.

Neither of these is a particularly efficient method of performing the task, so in version 7, the backup copy job type was born. Backup copy jobs will look at a particular backup chain, see if anything has changed and if so, replicate those backups using FFI backups to another repository optionally through WAN accelerators. By doing so, Veeam limits the access to the production VM and maximizes the bandwidth between sites by keeping the link as full as allowed.

I find that the tricky part about backup copy jobs is understanding that I need to have a basic backup copy job defined first that sets up the basic set of parameters we’re looking for: where to store, how many restore points to keep, what storage type to use, etc. After that, backups from any “regular” job can then be added to a backup copy job. This is similar to the idea of protection policies in modern storage environments or security policies most anywhere else.

Example setup ^

So now that we have covered the job types, let’s walk through a common scenario as pictured below. In this situation, we are going to do primary backups to a repository local to the production VMware environment using reverse incrementals, then have a continuous backup copy job ship those backups to another repository offsite through a pair of WAN accelerators to maximize our bandwidth usage.

Example Setup

Example setup

When I’m setting up my jobs, I like to keep a runbook of what each job is doing and how it’s doing it. Below is what I’d include for this job, taking note of any situation where the configuration deviates from the default.

Job Name: 6 Lab

  • VM Name(s) to be backed up: 6LabDC1
  • Restore Points: 7
  • Storage Target (Local): 1st Tier Storage
    • Method: Reverse Incremental, Saturday Synthetic
    • Compression level: Dedupe-friendly
    • Storage optimization: Local Target
    • Encryption: Yes, Lab Password
  • Do not use storage snapshots
  • Enable Guest Processing
  • Runs weekdays at 6pm

Job Name: 6 Lab Backup Copy

  • VM Name(s) to be backed up: 6LabDC1 (Choose from Backup)
  • Restore Points: 7
  • Storage Target (Remote): DR Repo 1
    • Method: Reverse Incremental, Saturday Synthetic
    • Compression level: Dedupe-friendly
    • Storage optimization: Local Target
    • Encryption: Yes, Lab Password
  • WAN accelerators: hqbackup, drrepo1
  • Runs during off-hours

So here it is step by step:

Let’s start by creating and running the local backup job.

  1. Right-click Backup and choose “Backup…”
  2. Give your job a name.
    Job name
  3. Add the VMs you want to protect. We are just using one here (6LabDC1), but usually I like to group jobs either by OS or application group to maximize the deduplication potential within Veeam.
    Add the VMs
  4. Specify the backup proxy and repository to be used. I’ve left the backup proxy as the default “Automatic selection,” but you have to specify a repository. I’ve selected “1st Tier Storage.”
    Specify the backup proxy and repository
  5. Specify your retention policy. Don’t worry about the secondary destinations; we’ll cover that in another step.
  6. Click Advanced.
  7. Specify a backup mode. You’ll see that I’ve selected a reverse incremental mode, selected “Create synthetic full backups” and specified “Saturday.” If you are going to do a long-range chain, you will want to select “Transform previous backup chains into rollbacks” as well.
    Specify a backup mode
  8. Define your storage. Use the default deduplication within Veeam, but also store it using de-dupe friendly compression allowing Windows 2012 R2 to optimize further. I’ve also chosen to encrypt these backups by creating a password and enabling the new version 8 feature.
    Define your storage
  9. Another newer feature under Advanced Settings is being able to use storage snapshots to serve as the source on the backups. This is compatible with HP StoreServ and StorVirtual compatible systems and now NetApp ONTAP compatible arrays. Because I have neither of these, I’m disabling this feature.
    Another newer feature under Advanced Settings
  10. In Guest Processing, you can specify how to handle application aware settings, so that log files are managed for SQL and Exchange and you can do full indexing of compatible systems to allow for file search in Enterprise Manager. To do either of these you’ll need to specify compatible credentials to the protected systems.
    Application aware settings
  11. Specify your schedule, setting the job to run on weekdays at 6 PM.
    Specify your schedule
  12. As you can see from the Running screen, our job is now progressing. Once it has completed for the first time, we can start configuring our backup copy job.
    Job is now progressing

Creating a backup copy job begins similarly:

  1. Right-click on Backup Copy and click “Backup Copy…”
    Backup Copy
  2. Once the wizard is launched, specify the name and the option of how often you want to do a copy operation. Once a day is sufficient for this case, but you may want it done more often.
  3. In Virtual Machines, add the VMs. You’ll notice when you click “Add” that you have the option to add from VI, backups or jobs. I like to add from a backup. You’ll notice that when I did so it decided the source backup was encrypted and prompted me to do the same for the copy.
    Add the virtual machines
  4. Specify the destination and how many restore points to keep. Notice that we now have the additional option to retain older copies of the data as the chain progresses; this is to allow for proper grandfather-father-son data retention and may assist you in meeting your organization’s retention policies.
    Specify the destination
  5. Click Advanced.
  6. This looks similar, doesn’t it? Here we’ll tell it to store the copy backup using dedupe-friendly compression as well. If you are in a low bandwidth situation, you may want to do this differently.
    Store the copy backup
  7. The Data Transfer screen is where you specify if the WAN accelerators feature will be used. This already needs to be set up in your infrastructure, but once it’s done, you use it here. Version 8 WAN accelerators are even more efficient than the v7.5 ones and are great for this purpose.
    The Data Transfer screen
  8. Set the schedule. Note that this schedule is different than for the backup job. Essentially backup copy jobs just watch the job directory to see if there is a new backup. By default, when it sees one, it activates the job and begins copying. This WOULD NOT BE OPTIMAL DURING BUSINESS HOURS since it would suck up quite a bit of your bandwidth. You can optimize this, but to keep it simple, we’ll just set our schedule to be anytime outside of business hours.
    Set the schedule
  9. Now you have functional, multi-site backups. Congratulations!

Everything you saw above was done using the free 60-day evaluation that Veeam provides. You may want to give it a try yourself.

Also read my previous post where I discussed deployment and different components of Veeam Backup & Replication 8.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads and for free by becoming a member!

1 Comment
  1. Jesse 4 years ago

    Fantastic articles. Informative yet concise, and with practical real world examples to boot. Much appreciated!


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account