Skip to main content

Why Veeam isnt’t able to use the whole capacity of LTO-tapes? E.g.: Why can't Veeam write a new mediaset to the end of another mediaset?

Tapes are in the same mediapool. Mediapool setting “Do not create, always continue using current media set” ist active. If i edit some settings on Backup-To-Tape-Job, a new MediaSet-Name is setting. On next run of this job veeam uses a new fresh tape, although the last tape still has enough storage capacity.

I’ve got LTO-7 Tapes (12TB mx. capacity). Veeam uses, for example, only 2TB of capacity in case of doubt.

Hi @hufnagst 

Welcome to the Community Forums. Do you have the append setting enabled:

More here: https://helpcenter.veeam.com/cn/docs/backup/hyperv/add_gfs_media_pool_advanced.html?ver=110


Thank you very much for the very quick reply!

But we don’t use GFS-Media Sets becauce we do not want to use G-F-S rules. It is a standard media pool.


From your description, it should use the same tape. Can you send screnshots of the media pool configuration and the space used in the tapes? 

Also, lto7 has a native space of 6TB without compression. With compression could reach 12TB, but the compression is made by the tape drive if you have this feature and the veeam files are already compressed, so you will neve see 12TB cobsumed. 


Additionally, have you set any settings under the ‘Media Set’:

https://helpcenter.veeam.com/cn/docs/backup/hyperv/add_media_pool_set.html?ver=110

 


We use the standard mediapool “Monatssicherungen” für a Job named “Weekly to tape”. This job write backups of the whole (disk) Backup repository with its VM-Backups. The configuration of this job you can see as followed…

The Job runs weekly at every saturday…

… to tapes in a media pool named “Monatsicherungen” with this conditions….

 

And here is a listing of the tapes in this pool. As you can see there are, for example, the tapes NNW582L7 and NNW594L7. These tapes were not fully utilized. Instead, Veeam used the new tape NNW587L7 for the last backup, for example and the MediaSet name has changes (since i changed the backup job befor)

 


I’m familiar with the limitations and conditions of a LTO7-tape about its capacity. The limit of 5,5 TB ist expecting for me in this use case.

Thank you very much in advance for your time and effort.


It's configured correctly, bu Veeam could create a new media set on certain conditions. It's better to create a support case to investigate why a bew media was created.


Based on the best practice page under the Media Set heading the settings you have should write the full tape - https://bp.veeam.com/vbr/3_Build_structures/B_Veeam_Components/tape.html

So as noted a support case to determine why this is not happening might be the best route now.


Ok, I thank you.


Ok, I thank you.

Let us know if you do contact support and what they say or if they give you an answer to post here.  Also be sure to select an answer to your question in the thread here so others can see.


Before I open a ticket, I suggest that I observe Veeam's behavior for a few more days

Perhaps the error occurred for the following reason:

  • Veeam did not find a tape with sufficient capacity in the media pool during the last backup.
  • I wanted Veeam to use the tape NNW582L7 with the media set "Monatssicherung #1 07.10.2023" for this purpose. To achieve this, I entered the manual value "Monatssicherung #1 07.10.2023" in the 'Media set name' field (without the default variables).
  • However, as this led to errors, I temporarily selected the 'Create new media set for every backup session' option.
  • As a result, Veeam again detected that no tape was available. I then set back the option to 'Do not create, always continue...'.
  • This then caused Veeam to create a new media set. Perhaps this explains why the original media set 'Monatssicherung #3 28.10.2023' could no longer be used.

So my last question:
Is it not possible to set the name for the media set manually (i.e. without variables)?


I have never tried to manually name a media pool and always used the variables from this page - Media Set Names - User Guide for VMware vSphere (veeam.com)

You could always try naming it manually and see if it works which to me it should but maybe they force the variables.


Let us know how it goes the next few days and hopefully the issue resolves without a support ticket.


Before I open a ticket, I suggest that I observe Veeam's behavior for a few more days

Perhaps the error occurred for the following reason:

  • Veeam did not find a tape with sufficient capacity in the media pool during the last backup.
  • I wanted Veeam to use the tape NNW582L7 with the media set "Monatssicherung #1 07.10.2023" for this purpose. To achieve this, I entered the manual value "Monatssicherung #1 07.10.2023" in the 'Media set name' field (without the default variables).
  • However, as this led to errors, I temporarily selected the 'Create new media set for every backup session' option.
  • As a result, Veeam again detected that no tape was available. I then set back the option to 'Do not create, always continue...'.
  • This then caused Veeam to create a new media set. Perhaps this explains why the original media set 'Monatssicherung #3 28.10.2023' could no longer be used.

So my last question:
Is it not possible to set the name for the media set manually (i.e. without variables)?

Ah ok, so this makes sebse why the tape used a new media set. It's better wait a few days. 


Before I open a ticket, I suggest that I observe Veeam's behavior for a few more days

Perhaps the error occurred for the following reason:

  • Veeam did not find a tape with sufficient capacity in the media pool during the last backup.
  • I wanted Veeam to use the tape NNW582L7 with the media set "Monatssicherung #1 07.10.2023" for this purpose. To achieve this, I entered the manual value "Monatssicherung #1 07.10.2023" in the 'Media set name' field (without the default variables).
  • However, as this led to errors, I temporarily selected the 'Create new media set for every backup session' option.
  • As a result, Veeam again detected that no tape was available. I then set back the option to 'Do not create, always continue...'.
  • This then caused Veeam to create a new media set. Perhaps this explains why the original media set 'Monatssicherung #3 28.10.2023' could no longer be used.

So my last question:
Is it not possible to set the name for the media set manually (i.e. without variables)?

One other thing to add is to make sure that your Tapes and Inventoried and Catalogued as well so Veeam knows what is already on there. However, worth waiting a few days and let us know how it goes. Hope you manage to get it sorted.


Before I open a ticket, I suggest that I observe Veeam's behavior for a few more days

Perhaps the error occurred for the following reason:

  • Veeam did not find a tape with sufficient capacity in the media pool during the last backup.
  • I wanted Veeam to use the tape NNW582L7 with the media set "Monatssicherung #1 07.10.2023" for this purpose. To achieve this, I entered the manual value "Monatssicherung #1 07.10.2023" in the 'Media set name' field (without the default variables).
  • However, as this led to errors, I temporarily selected the 'Create new media set for every backup session' option.
  • As a result, Veeam again detected that no tape was available. I then set back the option to 'Do not create, always continue...'.
  • This then caused Veeam to create a new media set. Perhaps this explains why the original media set 'Monatssicherung #3 28.10.2023' could no longer be used.

So my last question:
Is it not possible to set the name for the media set manually (i.e. without variables)?

Ah ok, so this makes sebse why the tape used a new media set. It's better wait a few days. 

Now that the tape job has run over the weekend, I can report that attaching the backup to an already used tape has worked. This means that Veeam continues to use tapes that have not yet been fully written to, as long as they are one and the same media set.

In this respect, I was correct in my assumption regarding the cause of the fault.


Glad to hear you were able to resolve the issue.


Comment