Skip to main content
  • EN

One of the things that we have in all our projects and backup environments are Backups Jobs.

After deploying all components and servers on our Veeam infrastructure, the first thing that we do is the creation of our backup jobs.

Thinking of that, I write this post telling you what is the main nomenclatures that I’ve been used on my Veeam Backup & Replication.

 

B2D - Backup to Disk

Backup jobs that we use to send data to any disk repository.

 

B2T - Backup to Tape

Backup jobs that we use to send data to tape libraries.

 

B2C - Backup to Cloud

Backup jobs that we use to send data to cloud. On V11 we need a SOBR to send data to public cloud like AWS, Azure and GCP. However, if we have a Veeam Cloud Connect repository, we can send data to this kind of 'cloud' and use B2C name on backup job.

 

BC - Backup Copy

Backup copy jobs we often use to make one or more copies of data between repositories or sites.

 

LTR - Longe Term Retention

Backup copy jobs we can have to attend a long-term retention on data archiving. We often have this kind of job to send data to storage systems though for lengthy periods like DataDomain.

 

This is the main nomenclatures that I use on my backup projects.

Do you have something different? Tell me this on comments below!

I’d love to know that.

These seem to be very common as I use the same ones.

In my personal case, depending on the project or the customer, but I like naming depending on type and application group, and then an extra of where is located, cause they were a small amount of tasks, but it’s very well described and easy to follow.😄

In my personal case, depending on the project or the customer, but I like naming depending on type and application group, and then an extra of where is located, cause they were a small amount of tasks, but it’s very well described and easy to follow.😄

It’s the same for me!

In all my backup projects we have used customer name or datacenter location. 

Where it is needed it is added application group name.

 

Interesting topic and nomenclatures, thank you for sharing @wolff.mateus 

I use vsphere cluster name or application group with the mention of backup, copy, tape… and storage type.
 

I have a blog post waiting to be finished on that topic, as I designed several nomenclatures for several customer environments with specific properties. Also thinking further about ROBO’s, copys and so on all in all with tag combinations. Hopefully I’ll get this one finished very soon !

I have a blog post waiting to be finished on that topic, as I designed several nomenclatures for several customer environments with specific properties. Also thinking further about ROBO’s, copys and so on all in all with tag combinations. Hopefully I’ll get this one finished very soon !

 

I have a blog post waiting to be finished on that topic, as I designed several nomenclatures for several customer environments with specific properties. Also thinking further about ROBO’s, copys and so on all in all with tag combinations. Hopefully I’ll get this one finished very soon !

Nice @falkob!

Remember to mention our community on your blog post! 😅

Interesting idea.  My jobs are typically named a bit more verbosely:

 

  • Backup VMs to NAS01
  • Backup VMs to Tape
  • Copy VMs to NAS02
  • Copy VMs to Wasabi
  • Replicate VMs to DR
  • Replicate CDP VMs to DR
  • Verify VM Replicas in DR
  • Verify VM Backups on NAS01

 

You get get the idea.  I do like your nomenclature though so I may have to think about how to implement that to some degree.

Interesting idea.  My jobs are typically named a bit more verbosely:

 

  • Backup VMs to NAS01
  • Backup VMs to Tape
  • Copy VMs to NAS02
  • Copy VMs to Wasabi
  • Replicate VMs to DR
  • Replicate CDP VMs to DR
  • Verify VM Replicas in DR
  • Verify VM Backups on NAS01

 

You get get the idea.  I do like your nomenclature though so I may have to think about how to implement that to some degree.

These names are typically what often use on description.

I prefer job names with only uppercase and without spaces.

These are some examples:

  • B2D-VMS-AD
  • BC-VMS-APP
  • LTR-VMS-FS

 

Interesting idea.  My jobs are typically named a bit more verbosely:

 

  • Backup VMs to NAS01
  • Backup VMs to Tape
  • Copy VMs to NAS02
  • Copy VMs to Wasabi
  • Replicate VMs to DR
  • Replicate CDP VMs to DR
  • Verify VM Replicas in DR
  • Verify VM Backups on NAS01

 

You get get the idea.  I do like your nomenclature though so I may have to think about how to implement that to some degree.

These names are typically what often use on description.

I prefer job names with only uppercase and without spaces.

These are some examples:

  • B2D-VMS-AD
  • BC-VMS-APP
  • LTR-VMS-FS

 

I agree.  The longer names I would use for the descriptions.  Shorter names are better and without spaces in case moving them is required too.  😉

Interesting idea.  My jobs are typically named a bit more verbosely:

 

  • Backup VMs to NAS01
  • Backup VMs to Tape
  • Copy VMs to NAS02
  • Copy VMs to Wasabi
  • Replicate VMs to DR
  • Replicate CDP VMs to DR
  • Verify VM Replicas in DR
  • Verify VM Backups on NAS01

 

You get get the idea.  I do like your nomenclature though so I may have to think about how to implement that to some degree.

These names are typically what often use on description.

I prefer job names with only uppercase and without spaces.

These are some examples:

  • B2D-VMS-AD
  • BC-VMS-APP
  • LTR-VMS-FS

 

I can definitely see the argument for case and spaces, and that said, it’s a little strange that I opted for this when I was coming up with my standard.  I think it was because I needed to be clear to my Engineers/Administrators what each job was doing without confusion at a glance.  Might be time to revisit my standards though.

Thx for sharing this @wolff.mateus ! Very interesting and probably will take over this naming convention 🤣. Now I always start the job with BACKUP-, COPY-, AGENT-, … but I like the idea. As you already mentioned, I also never use spaces in the names of the jobs (issues when migrating from standard repo to SOBR … - you need to manually change the files with underscores instead of spaces …

 

Nice one!

Something to add : for cloud-jobs to the service-provider I always use the name of the tenant as a piece in the job-name, it’s handy for the service-provider 😅

 I also never use spaces in the names of the jobs (issues when migrating from standard repo to SOBR … - you need to manually change the files with underscores instead of spaces …

 

Interesting...I haven’t run into this issue.

 I also never use spaces in the names of the jobs (issues when migrating from standard repo to SOBR … - you need to manually change the files with underscores instead of spaces …

 

Interesting...I haven’t run into this issue.

No problem, I did 😂, more info at this KB of Veeam : KB2236: Manually moving backup files to or from a Scale-Out Backup Repository (veeam.com)

 I also never use spaces in the names of the jobs (issues when migrating from standard repo to SOBR … - you need to manually change the files with underscores instead of spaces …

 

Interesting...I haven’t run into this issue.

No problem, I did 😂, more info at this KB of Veeam : KB2236: Manually moving backup files to or from a Scale-Out Backup Repository (veeam.com)

We have seen this too many times being an MSP and moving client files around. 😜

 I also never use spaces in the names of the jobs (issues when migrating from standard repo to SOBR … - you need to manually change the files with underscores instead of spaces …

 

Interesting...I haven’t run into this issue.

No problem, I did 😂, more info at this KB of Veeam : KB2236: Manually moving backup files to or from a Scale-Out Backup Repository (veeam.com)

We have seen this too many times being an MSP and moving client files around. 😜

Indeed @Chris.Childerhose ! 😎

Interesting idea.  My jobs are typically named a bit more verbosely:

 

  • Backup VMs to NAS01
  • Backup VMs to Tape
  • Copy VMs to NAS02
  • Copy VMs to Wasabi
  • Replicate VMs to DR
  • Replicate CDP VMs to DR
  • Verify VM Replicas in DR
  • Verify VM Backups on NAS01

 

You get get the idea.  I do like your nomenclature though so I may have to think about how to implement that to some degree.

These names are typically what often use on description.

I prefer job names with only uppercase and without spaces.

These are some examples:

  • B2D-VMS-AD
  • BC-VMS-APP
  • LTR-VMS-FS

 

I can definitely see the argument for case and spaces, and that said, it’s a little strange that I opted for this when I was coming up with my standard.  I think it was because I needed to be clear to my Engineers/Administrators what each job was doing without confusion at a glance.  Might be time to revisit my standards though.

I’m using essentially a mix of both like:

BKP-VMS-APP
BKP-COPY-WASABI-VMS-APP
BKP-TAPE-VMS-APP
SUREBACKUP-VMS-APP

+1 to avoid space in the name convention.

It’s much easier to have a nomenclature, especially if you want to use scripts later

 

We are using names like this:

<client short name><cluster short name (optional)><type of backup><OS><applikation (optional)><SLA>

The single parts are divided either by space (with the “older” customers) or by dash.

Comment


Terms & Conditions