This week I supported a customer moving from Backup Exec 2012 to Veeam v7.0 for their backup to tape solution and because everybody was happy in the end, I decided write a little bit about the tape support.
We started with an upgrade from 6.5 to 7.0 R2 which I already described in this post. Then we simply disabled all Backup Exec services and we were ready to go.
Without any issues Veeam recognized the Fibre Channel attached Dell TL2000 tape library which was equipped with two drives. The native Dell (IBM) Windows drivers have already been installed and everything worked out of the box.
Then we performed a “Library Inventorying” to discover all available/free tape drives
This process created two default pools, one for usable (free) tapes and one for medias which have been used by backup exec before. For those Veeam will display the following error “Unknown MTF writer”. I’m not sure if this was just caused by the write protection on the tapes, because Backup Exec actually also uses the Microsoft Tape Format.
Once discovered you can perform several operations on those tape
One thing we missed was the option to schedule an inventory task to re-scan for new or removed tapes. A quick search revealed that this is currently only possible via PowerShell and thanks to the Veeam Community it didn’t take long to solve this problem
$Library = Get-VBRTapeLibrary –name “Name of the Library”
$Library | Start-VBRTapeInventory
Then we were ready to create our own media pools and jobs. For all of you looking for a way to implement a Grandfather-Father-Son (GFS) principle, you will need to prepare the media pools accordingly or you will need to leverage the “Backup Copy” feature in addition, because there is no option for GFS within the backup to tape job itself. However this isn’t a huge problem because you can simple create multiple pools, for example:
- Weekly Pool – Up to 5 weeks write protection
- Monthly Pool – Up to 12 months write protection
- Yearly Pool – Up to 3 years write protection
According to these pool you can create multiple B2T jobs which can use a proper media pool.
An alternative would be to use the Backup Copy feature to “copy” your restore points to a second repository/location and to keep certain restore points according to the GFS principle. Those can be easily backed up via a “File to Tape” job. Note that a copy job cannot be used as source of a backup to tape job.
This customer really liked the “Reverse Incremental” backup method which in combination with the backup to tape turned out to be a good fit.
The reverse incremental method keeps just a single full backup file (*.vbk) which moves forward from day to day as long as you don’t perform an active full backup.
The plan was to use this backup method to keep at least 14 restore points on disk and to write just a single full backup file to tape once a week. The customer really liked this combination because they didn’t need to worry about the number of fulls on disk nor on tape.
But I can’t recommend this method for customers who want to keep a whole backup chain on disk simply because this isn’t supported in combination with the reverse incremental method (*.vrb files).
If you enable the processing for incremental, which will also process *.vrb files you will end up with multiple full backups on tape. This how the backup repository looked like
What happened was that for every *.vrb on disk a full backup *.vbk will be written to tape! So in this case you would end up with three full backups on tape.
If you disable the incremental backup processing as depicted in in the screenshot above, Veeam will only copy the full backup file(s).
Now so far so good, but what for those of you who prefer the forward incremental method which is often used in a combination with synthetic fulls?
This will enable you to keep a complete backup chain on tape, because VBR supports to copy also the incremental files (*.vib) to tape. This is how the repository looked like
And so VBR copied the complete backup chain to tape
But in my opinion this method has a little drawback, at least at the beginning. And please feel free to correct me if I’m wrong here.
Let’s way we also want to keep 14 restore points and we setup the job on Monday. In addition to that we would like to perform a synthetic full and the backup to tape every Saturday.
The following numbers should represent restore points not a date!
In the first week Veeam will create a standard and a synthetic full backup which will be kept on disk until it is automatically deleted according to the backup retention policy. So two full backups will be backed up to tape in that week. This is because VBR will simply backup all restore points associated to a backup job to tape no matter how many full backups the backup chain contains. At least I wasn’t able to find a way to limit this in any way. Of course in the third week the number of full backups will be reduced to two on disk and to a single file which will be backed up to tape.
*The full backup 6* (previously 13) is already on tape and doesn’t need to be backup up again.
However now back to my customers where we created multiple media pools according to their needs as well as multiple B2T jobs.
As source for a backup to tape job you can add a bunch of backup jobs or even whole repositories. And of course in addition to the scheduling options or the selection of the media pool, you can also enable hardware compression and some automation options.
Then we started the first B2T job and as I mentioned earlier, everything just worked.
At this point I should mention that we had to replace the drivers at one point because we rarely had issues with drive locks. By installing the so called “non-exclusive” drivers we were able to easily fix hat.
We were kinda surprised how fast the job started to push data to tape. All of us were used to a delay for backup to tape jobs in other tools, but not with VBR v7.0 which started almost instantaneously.
But this wasn’t the end, we had two drives to use and we wanted to use those simultaneously to speed things up.
To be able to use two drives at the same time we had to use at least two jobs as well as two different media pools, because a single job will lock the target media pool when the backup has started.
I mentioned it at the beginning of the post and I don’t want to neglect the possibility to also backup files to tape. We used this feature to backup Windows & Acronis bare metal backups/images to tape.
In the end all were happy to easily migrate to VBR v7.0 but there are some things we would like to see in future releases:
- Statistic for tapes, like error counters
- Refined scheduling to better support GFS usage. For example a weekly and monthly backup to tape job on the last weekend of the month, with different media pools, would backup the same data twice. Once on the weekly tapes and once on the monthly tapes but usually the last weekly media becomes the monthly tape.
- Schedules for a library inventory within the GUI
But don’t get me wrong they managed to implement a really solid backup to tape support which is really easy to use and so I’m sure also other customers will be happy to get rid of their current backup to tape solution.