Skip to main content

How to structure and name jobs

  • July 12, 2026
  • 8 comments
  • 108 views

fabian.papenfuss
Forum|alt.badge.img+1

Hello everyone!

This is my first contribution to the Veeam Community Hub!

In the long term, I plan to start my own blog to share my thoughts and technical perspectives from my daily work, but while it is in the making, let's move on with my thoughts on the topic „how to structure jobs.“

This post will cover Veeam Backup & Replication in the first place, but in the future I will also cover Veeam Microsoft 365.

In my daily work, I have seen a lot of variations, like “naming schemes“ (please imagine this in very large quotation marks), like "Backup Job 1“ or „Server Backup x with Database.“

Basically naming jobs like this, of course, works, but in the daily work you have to search for what this job is exactly, and when the description is the default one, you don't know anything.

To prevent this situation, and because I really like to organize things:)

Over time, I have developed a specific naming scheme for jobs in Veeam Backup and Replication, such as Backup to Disk or Backup Copy Jobs.

This scheme is based on the post of ​@wolff.mateus:

and the official Veeam VMCE (VMCE 2025/v12) training material.

But let's get specific; here is one example name and description for a VMware vSphere Backup to Disk Job for application VMs like Active Directory Domain Controller or Microsoft Exchange with a retention of one week:

Name

Description

B2D-FRA-VMV-APP-7D

Backup to Disk, Frankfurt, VMware vSphere, Application servers, 7 days retention

 

For the individual parts of the job name, here is the explanation:

B2D means simple, that is, a backup to disk, but this can also be a backup to Cloud or Tape.

So this is where I mention above in this article from @wolff.mateus, it’s so simple but genius.

Here is a short overview of the abbreviation:

Abbreviations

Description

B2D

Backup to Disk

B2T

Backup to Tape

B2C

Backup to Cloud

BC

Backup Copy

LTR

Long Terminal Retention

VMR

VM Replication

CDP

Continuous Data Protection 

 

FRA is the airport code for the Frankfurt Airport, also called Fraport.

So the idea behind this is to set a short and precise description of the location, and in most cases your equipment or hosted infrastructure is located in a datacenter in a bigger city that has an airport.

Here is an overview of the bigger airports in Germany:

Airport Code

City

CGN

Cologne

DUS

Düsseldorf 

HAM

Hamburg

MUC

Munich

STR

Stuttgart

A complete overview of all airport codes all over the world you can find here:
https://www.world-airport-codes.com/

 

VMV is the short for VMware (vSphere Foundation/Cloud Foundation).

Of course, you can shorten any other hypervisor platform or OS (this list is not complete but has the popular workloads):

Abbreviations

Description

VMV

VMware vSphere

HV

Microsoft Hyper-V

PVE

Proxmox Virtual Environment  

AHV

Nutanix AHV

MVE

HPE Morpheus VM Essentials

PHY

Physical Clients

NAS

Unstructured Data (File or Object)

 

APP stands in the case of this VM Backup for Application, but you also have Databases or NAS Jobs FILES.

Abbreviations

Description

APP

Application Aware Workloads

WL

Standard Workloads without any Application Aware Processing

MGMT

Management Workloads without Application Aware Processing

WINDOWS

Microsoft Windows Operating Systems

LINUX

Linux (DEB/RPM) Operating Systems

FILES

File Backup for NAS or Object

 

7D stands for the retention in this example for seven days or one week.

I personally handle it so that all retention over 31D is mentioned in months, for example, like 6M, and the same for all that’s over 12 months; then it goes over to years, like 3Y:

Abbreviations

Description

7D

Seven Days of Retention

4W

Four Weeks of Retention

12M

Twelve Months of Retention

3Y

Three Years of Retention

For GFS Retention, I handle it like this: 7D-4W-12M-3Y

Here are also a few examples for different jobs:

Name

Description

B2D-FRA-NAS-FILES-31D

Backup to Disk, Frankfurt, File Share (NetApp Filer/Production Data), 31 days retention

 

BC-FRA2CGN-PVE-APP-31D-12M-3Y

Backup Copy (Scale-Out Repository CGN), Frankfurt, Proxmox VE, Application servers, 31 day/12 month/3 year retention

B2C-FRA-PHY-WIN-14D

Backup to Cloud (Wasabi EU Central 1 (Amsterdam)), Frankfurt, Physical, Windows server, 14 day

 

And that’s it!

I hope I could give some ideas for structuring your Veeam jobs.

This overview will grow and evolve over time!

8 comments

coolsport00
Forum|alt.badge.img+23
  • Veeam Legend
  • July 12, 2026

Hi ​@fabian.papenfuss - Welcome to the Community!

I do somewhat what you share above in my jobs. But, as I’m a customer, my job-naming doesn’t need as much “detail” thankfully. But if I was a MSP, I’d probably do something similar to what you have. For example, for my ‘local’ Jobs, I name them by criticality, frequency, & if I have so many VMs in the given ‘type’ to where I need to add addt’l jobs (i.e. don’t want too many VMs in a given Job); e.g.
DC1-30MIN-01  <--- These entail critical VM backups I backup every 30mins at my CO site, and are the “1st group” I created
DMZ-24HR-02  <--- Likewise, these entail VM backups I backup daily and are located in my DMZ, and are my 2nd group.

Good post! Thanks for sharing.


HunterLAFR
Forum|alt.badge.img+10
  • Veeam Legend
  • July 12, 2026

Hi there

thanks for the info,

In the companies Ive worked for in the past years, I had different ways to name backup tasks, same with Servers, VMs, etc.

Some of them where full Names, others naming convention like the one you are showing, and the most confusing one was a company that named everything with random names and numbers, generated by a random program like keypass, and we maintained a database with all the randomized names and their real name / role / machine.

The explanation was simple, privacy!

If an attacker gets into our systems, they won't know the roles of any machine, AD, FS, etc… no clue!

to me, its a matter of flavor and way of working, but always thankful to get more possibilities and clean ways to name and organize our Infrastructures.

cheers.


fabian.papenfuss
Forum|alt.badge.img+1

Hi ​@fabian.papenfuss - Welcome to the Community!

I do somewhat what you share above in my jobs. But, as I’m a customer, my job-naming doesn’t need as much “detail” thankfully. But if I was a MSP, I’d probably do something similar to what you have. For example, for my ‘local’ Jobs, I name them by criticality, frequency, & if I have so many VMs in the given ‘type’ to where I need to add addt’l jobs (i.e. don’t want too many VMs in a given Job); e.g.
DC1-30MIN-01  <--- These entail critical VM backups I backup every 30mins at my CO site, and are the “1st group” I created
DMZ-24HR-02  <--- Likewise, these entail VM backups I backup daily and are located in my DMZ, and are my 2nd group.

Good post! Thanks for sharing.

Hi ​@coolsport00!

Thank you for the welcome! 😎

That's a good point!
I think I will make a little change for the future in this structure and add some workload index to it, like T0 for mission-critical workloads that are replicated via CDP or something like this and T1 for critical workloads that are backed up frequently.

Best,

Fabian


fabian.papenfuss
Forum|alt.badge.img+1

Hi there

thanks for the info,

In the companies Ive worked for in the past years, I had different ways to name backup tasks, same with Servers, VMs, etc.

Some of them where full Names, others naming convention like the one you are showing, and the most confusing one was a company that named everything with random names and numbers, generated by a random program like keypass, and we maintained a database with all the randomized names and their real name / role / machine.

The explanation was simple, privacy!

If an attacker gets into our systems, they won't know the roles of any machine, AD, FS, etc… no clue!

to me, its a matter of flavor and way of working, but always thankful to get more possibilities and clean ways to name and organize our Infrastructures.

cheers.

Hi ​@HunterLAFR!

Thank you for your comment!

That sounds crazy with some random names.
But yeah, I think that's also a good point with the privacy, and I tried to make the names not too obvious with the abbreviations.
Normally it should be that the backup server is the best protected server and attackers don't come to the point where they see the backup jobs, but thanks again for this point!

Best,
Fabian


Chris.Childerhose
Forum|alt.badge.img+22

Welcome to the community ​@fabian.papenfuss 

This is always something you need to be mindful of with jobs and some nice tips here.  We name our jobs based on resellers and customers but similar with what the job covers. 👍


fabian.papenfuss
Forum|alt.badge.img+1

Hi ​@Chris.Childerhose!

Thank you also for the welcome!

Definitely, it is also important for me and my employer, who is a CSP/MSP, to have a good structure for shared and dedicated Veeam environments.

Best,
Fabian


Jean.peres.bkp
Forum|alt.badge.img+8

Excellent article! A well-designed naming convention is often underestimated, but it can make a huge difference in day-to-day operations, troubleshooting, reporting, and disaster recovery scenarios.


fabian.papenfuss
Forum|alt.badge.img+1

Hi ​@Jean.peres.bkp,

Thank you for your feedback!
That was exactly my reason for writing this Community Hub article.

Best,
Fabian