Skip to main content

This is the description of an unusual scenario where Backup Job Files (.vbk and .vib Files) are backed up with a File-to-Tape Job instead a Backup-to-Tape Job. This has several disadvantages, e.g., you must know on which tape your files you want to restore are residing. You cannot find your tape backups under the backups section in the “Home” view of console and many more…

OK, now have a look how we get these files back from tape.

See the results of the File-to-Tape job and find the tape number the files reside on. If you don’t know the tape, read further, and use the search function ( Note: the warning in the screenshot can be ignored. The filesystem is too big for VSS Snapshots, I have forgotten to switch the VSS snapshots off for this test backup job.).

Then go in the Veeam Console to the “Tape Infrastructure” section. Either go to the media pool where the affected tape is in or look for it in the Media section of your tape library.

Right click on the tape and select “Restore Content”. This opens a wizard, follow the directions of the dialog to proceed.

If you have right clicked on the affected tape, the correct tape is shown in the list.

In case you don’t know on which tape your files are, right click on any tape and select “Restore Content”. The use the search field of the wizard and type a part of your filenames you want to find. Then you can select the needed files from the list. Use this search procedure in case you don’t want to restore the whole tape, too.

Click on “Next” and follow the next steps of the wizard.

Select the server and the directory you want to restore the files on. The directory should be a directory you have defines a repository on. After that click “Next”.

In my case no files are in the target directory. So, I cannot select anything here. Select the correct option for your environment. Keep the checkbox “Restore file and folder security” checked. Click “Next” to proceed.

Last chance to change any options. If all is ok, click “Finish” to start the restore.

Check the results of the restore. Hopefully there are no errors, and all your files are on disk now. Click “Close” to end the restore wizard.

Now some more steps are necessary to use the restored backup job files.

The restore has saved the restored files with the complete original path under the directory you have chosen earlier.

Copy your files to the base repository directory (in my case E:\Backup).

Then rescan your repository

Now you find the backup files in the “Home” section under “Backups” --> “Disk (Imported)”. From here you can restore from these files with all options Veeam offers.

 

 

The recommendation for backup job files is to use a Backup-to-Tape job and not a File-to-Tape job. The handling of the files is much easier. I will create a similar tutorial for restore from a Backup-to-Tape job in the next time.

I constantly use this method for archiving backup jobs to tape. 

 

When I delete a VM, I’ll often create a final VeeamZIP, then follow that with a file to tape job.

I remove the old entry in the file to tape job, then add the new location. It gets the same media pool and I can keep all my old VM’s for a few years.

 

I don’t need a daily backup for most of these.

It is granular so I can select a single VM instead of entire jobs going to tape. 

 

Depending on the use, and being organized before hands, having a few Media Pools makes things easy to find. I can right click a tape, view the properties and files and see what VM’s are on the tapes.

 

I have been asking in the forums for an “ARCHIVE” type feature for either VM’s and/or file to tape for some time. 

Think of it as VeeamZIP to tape for servers.

I’d also want a similar archive for files. Think “VeeamZIP for a specific folder to tape”  

 

Perhaps one day this will exist. It’s our last step in getting rid of TSM. 

 


Hello @JMeixner,

Is it possible to share the Backup-to-Tape job restore tutorial.


Yes, had that in my VeeamOn session covered, but unfortunately it was virtual only ;) 

 

In your case file to tape acts as a secondary job to process Veeam plug-in backup data, so should not / wont consume any additional license for the size of plug-in backup files.

 

That session can be played at Veeamon.com - but only until July 18!


Yes, had that in my VeeamOn session covered, but unfortunately it was virtual only ;) 

 

In your case file to tape acts as a secondary job to process Veeam plug-in backup data, so should not / wont consume any additional license for the size of plug-in backup files.

Ok, that's fine. Thank you.

And  I asked this in a virtual VeeamOn session… not sure if it was yours. The answer was that this not decided up to now.

 

So, thank you for the clarification.


Yes, had that in my VeeamOn session covered, but unfortunately it was virtual only ;) 

 

In your case file to tape acts as a secondary job to process Veeam plug-in backup data, so should not / wont consume any additional license for the size of plug-in backup files.


All Veeam backup files are excluded from file to tape licensing engine. That’s true for plug-ins, agents, nas backup and the vm backup/backup copy stuff.

Was this decision made now? It was not clear at VeeamOn, I have spoken to several of the people who did presentation about the plugins.

This would be very nice, otherwise it will get rather expensive for us to write the plugin data to taoe in the future….


All Veeam backup files are excluded from file to tape licensing engine. That’s true for plug-ins, agents, nas backup and the vm backup/backup copy stuff.

Thank you for clarification @Dima P. 


All Veeam backup files are excluded from file to tape licensing engine. That’s true for plug-ins, agents, nas backup and the vm backup/backup copy stuff.


You’re perfectly right… that file to tape should be avoided in this case. But for another (future) reason. I don’t think VBR is aware that the source was backed up in the past as you choose to pick a file (accidentally a backupfile) to place it on a tape…

in V12 this shall be licensed as nas-backup so with vul. 

but it has an advantage… it will be a LOT faster ;)

Yes, completely true. You should not use file-to-tape jobs for this. But there are clients that do this in this way sometimes - an then do not know how to get the files back.

And in V12 these files should be excluded from licensing. With this I am more afraid that the files generated with the application plugins will be licensed. Plugin files can be copied to tape with file-to-tape only and if there are licensed this will get very expensive for us…. We have a lot of RMAN data.

we always have the same query for RMAN files even if I planned with my database expert to move to the new RMAN system in V12, the switch will not be as fast as the update in v12. We will need to validate this new paradigm in testing before going into production… Maybe @Rick Vanover  or @Mildur could have an answer about this subject 😇


Great post, thank you for sharing.

 

  1. If you do have access to backup to tape jobs please use those. Forever incremental merges are not tracked/processed by file to tape at all. Backup to tape can handle that and create periodic synthetics whenever needed
  2. If you by any chance have to stick with file to tape jobs for Veeam backup file processing (say you have socket license with Standard edition and cant upgrade to VUL or a higher edition) - disable incremental processing for forever forward backup chains and try to avoid interference with your primary backup job (there is no awareness of running source job in file to tape, but backup to tape can do that)

Thank you guys!

 

+1


Great post, thank you for sharing.

 

  1. If you do have access to backup to tape jobs please use those. Forever incremental merges are not tracked/processed by file to tape at all. Backup to tape can handle that and create periodic synthetics whenever needed
  2. If you by any chance have to stick with file to tape jobs for Veeam backup file processing (say you have socket license with Standard edition and cant upgrade to VUL or a higher edition) - disable incremental processing for forever forward backup chains and try to avoid interference with your primary backup job (there is no awareness of running source job in file to tape, but backup to tape can do that)

Thank you guys!

 


Thanks for this great walkthrough @JMeixner!


Great write up @JMeixner, handy guide to help people walk back out of that scenario, I’m sure there are more than a few people out there waiting to trip up on this scenario when they suddenly find themselves needing to recover! Great work Mr Tape!!!


Great write-up @JMeixner!

I'm glad that Standard licensed environments are rather rare as managing tapes is no fun without backup to tape jobs.

With VUL we will not see much standard editions in future 🙄


Great write-up @JMeixner!

I'm glad that Standard licensed environments are rather rare as managing tapes is no fun without backup to tape jobs.

Definitely! With standard license you can manage a standalone drive with a handful tapes, but not a library with a lot of tapes.


Great write-up @JMeixner!

I'm glad that Standard licensed environments are rather rare as managing tapes is no fun without backup to tape jobs.


Thanks for the great post, @JMeixner !

The only environments where I see this type of B2T scenario are where there is no enterprise (and/or +) license.

Yes, but I think this is manageable for very small environments only…. Ok, a small company will probably not have a big tape library 😎


Thanks for the great post, @JMeixner !

The only environments where I see this type of B2T scenario are where there is no enterprise (and/or +) license.


interesting case… because I recall file to tape being litterally any file to a tape… without logic or intelligence. I’ll ping one of my peers for beta2 try-out.


You’re perfectly right… that file to tape should be avoided in this case. But for another (future) reason. I don’t think VBR is aware that the source was backed up in the past as you choose to pick a file (accidentally a backupfile) to place it on a tape…

in V12 this shall be licensed as nas-backup so with vul. 

but it has an advantage… it will be a LOT faster ;)

Yes, completely true. You should not use file-to-tape jobs for this. But there are clients that do this in this way sometimes - an then do not know how to get the files back.

And in V12 these files should be excluded from licensing. With this I am more afraid that the files generated with the application plugins will be licensed. Plugin files can be copied to tape with file-to-tape only and if there are licensed this will get very expensive for us…. We have a lot of RMAN data.


I don’t have the tape-capacity in my homelab to test it, but I hope that isn’t true…

 

What shouldn‘t be true? That it doesn‘t require a license? 
Veeam Backup Files will be excluded from the size calculation and doesn‘t consume a license for the Tape Job. :)

https://forums.veeam.com/post453227.html#p453227

 

I’ve seen a lot… so it would not surprise me to see inventive people with zip-archives that are going to be renamed and tracked in excel files

 

I don‘t have tested it yet, but I‘m sure that only changing the file ending will not be enough to trick veeam into thinking they are backup files. 



Veeam will know that this are backup files with Agent or VM content, which already used a license.

I don’t have the tape-capacity in my homelab to test it, but I hope that isn’t true…

I’ve seen a lot… so it would not surprise me to see inventive people with zip-archives that are going to be renamed and tracked in excel files 🙄


You’re perfectly right… that file to tape should be avoided in this case. But for another (future) reason. I don’t think VBR is aware that the source was backed up in the past as you choose to pick a file (accidentally a backupfile) to place it on a tape…

in V12 this shall be licensed as nas-backup so with vul. 

but it has an advantage… it will be a LOT faster ;)

@smarivoet 
File 2 Tape Backups of vbk and vib files doesn‘t need to be licensed with V12. Veeam will know that this are backup files with Agent or VM content, which already used a license.

But I agree from a technical side with not using File 2 Tape Jobs at all, if you have veeam backup files. 


You’re perfectly right… that file to tape should be avoided in this case. But for another (future) reason. I don’t think VBR is aware that the source was backed up in the past as you choose to pick a file (accidentally a backupfile) to place it on a tape…

in V12 this shall be licensed as nas-backup so with vul. 

but it has an advantage… it will be a LOT faster ;)


Great! Thank you @JMeixner for showing these steps!


Comment