Amazon AWS VTL Gateway

[Bobin_NZ]

Hi Guys

Decided to try out AWS VTL now that Veeam officially supports it.

Went through all the steps on AWS website and all seemed to go well apart from one problem (there is always one). I can't seem to get the barcodes from the tapes in the VTL library into Veeam. I have tried rescanning, re-indexing, etc, etc, but no joy. All I can come up with is its got to be the media changer. In the AWS guide it says to use the SLK-L700 media changer (which is a SUN product) and the drivers AWS says to use are the "SONY TSL-A500C Autoloader". I would of thought there proper drivers for this SLK-L700 and that is why I can not read the barcode of the Tapes.

Any one got this working ? I hope i'm not the only one

Latham

Case number #00726328

[veremin]

Hi, Latham,

Are you positive that all of the requirements provided by Dmitriy have been followed?

Thanks.

[Dima P.]

Hello Latham,

I can't seem to get the barcodes from the tapes in the VTL library into Veeam.

There is indeed an issue with SONY TSL-A500C Autoloader drivers as it does not properly pass the barcode information from Amazon to Veeam tape service. As a workaround you can manually rename tape media according to the Amazon console, meanwhile we are working to get this fixed. Thank you.

[Bobin_NZ]

Thanks for the quick reply Dmitry

Will use the workaround as suggested. Fingers crossed you guys can work it out.

Thanks again

Latham

[Dima P.]

Latham,
Thanks! The plan is to provide a solution in the next major release, so stay tuned.

[Meyercord]

Looking forward to a fix for the barcode issue.

[veremin]

As mentioned above, I wouldn't expect this to be addressed pretty soon, as amount of changes required makes it rather next release, than just a patch. Thanks.

[Meyercord]

Oh, I had the impression that Dmitry's workaround was only intended as a temporary measure and that a fix would be coming soon.

As a workaround you can manually rename tape media according to the Amazon console, meanwhile we are working to get this fixed. Thank you.

Manually renaming every tape is not a practical long-term solution. Even doing it once is a pain. Are you saying we won't see a fix until Version 9?

[veremin]

As Dmitry's mentioned, it's more likely that the fix will be implemented in the next release, rather than in the upcoming patch. The main reason is that fix requires mutual efforts from both Amazon and Veeam, and the whole process might not necessarily be that fast.

Latham,
Thanks! The plan is to provide a solution in the next major release, so stay tuned.

Thanks.

[Dima P.]

Hello AJ,

Manually renaming every tape is not a practical long-term solution.

Just out of curiosity, how many tapes your VTL is handling? Are you using VTL shelf for export?

[Meyercord]

We are still in the evaluation and planning stage, so I don't know how many tapes we will use ultimately; but our monthly backups are around 3TB. I am still trying to decide the ideal tape size for Amazon VTL that will balance manageability with recovery time and cost. Larger tapes means fewer to manage, but it also means a higher cost and time to recover, since restoring even a single file would require at least an entire tape and possibly multiple tapes to be downloaded from Glacier. Smaller tapes allow me to retrieve the minimum data necessary to perform a restore.

Right now, I'm considering a relatively small tape size of around 200Gib, which would result in about 300 tapes initially, plus another 15 per month. We would most likely be archiving/exporting to Glacier on a monthly basis.

[Dima P.]

AJ,
Great, thanks for sharing! As it was mentioned before, we are going provide a fix in the major release. Possibly, we will get a private fix some time before the v9 release, so if you (or maybe other readers) are interested in testing it in non-production environment, please, let me know via PM. Thank you.

[Bobin_NZ]

Hi Guys.

I have been using the gateway for the last 2 quarterly backups and have noticed that Veeam only seems to use two of the tape drives available to it. There is a total of 10 and was wondering how I increase it?

Any Ideas?

Many Thanks

Latham

[veremin]

I have been using the gateway for the last 2 quarterly backups and have noticed that Veeam only seems to use two of the tape drives available to it.

You mean that backup server is using only two drives simultaneously or just two specific drives, disregarding the other 8?

[Dima P.]

Hello Latham,
In addition, how many tapes are displayed as 'AVAILABLE' in the VTL console?

[Bobin_NZ]

It only seems to use two drive simultaneously (Drive 1 and 2). I have 10 drives listed. Loogin over the job report it only seems to use drive 2. I swear it was using drive one as well.

I have 16 Tapes marked as 'AVAILABLE' and are in the media pool for the job.

Have you guys in testing got it to work with more than 0ne-two Drives?

[Dima P.]

Yes, its all the drives should be visible. Can you perform a rescan? In addition, have you installed the Sony changer driver on Veeam tape server according the VTL guide?

[Bobin_NZ]

Yes, followed the guide to the letter.

Currently it has Drive 1 and 2 loaded. But that's all it ever uses.

[Dima P.]

Got it and thanks for the screenshot! If you run Import tapes – would the VBR recognize the loaded media? Could you please clarify how many media pools you’ve setup in the VBR (to let the tape job work simultaneously you must have one media pool per drive)?

[Bobin_NZ]

I see. So currently I have two media pools. One with my unassigned tapes (free) and one for my quarterly backup to AWS (quarterly backup). So to use all the drives available I need to have a pool for each one. Meaning I can't use more than one tape drive per backup job, right? But I could run two jobs at the same time and that would allow me to use two of them. No way to use more than one on the same Job?

[veremin]

Meaning I can't use more than one tape drive per backup job, right?

Correct.

No way to use more than one on the same Job?

Currently no.

[Bobin_NZ]

Thanks for Clearing that up Eremin.

Also any idea if we will be able to get the tape labels out of AWS in the up-coming service pack for 8? Creating them one at a time, adding them one at a time and manually renaming new tapes in Veeam (one at a time) is a real drag.

[Dima P.]

Hello Latham,

Also any idea if we will be able to get the tape labels out of AWS in the up-coming service pack for 8?

We will provide the solution for barcode reader issues in the next major release.

[Bobin_NZ]

So that is Version 10? Meaning maybe some time at the end of the year?

[veremin]

So that is Version 10?

Current product version is 8. The next major one is 9.

Meaning maybe some time at the end of the year?

There is no ETA at the moment.

Thanks.

[user1337]

The lack of barcode makes this feature completely useless. No legitimate backup strategy could run the risk of an administrator making a mistake and incorrectly naming a tape within Veeam and subsequently deleting/archiving the wrong media from AWS. This would be a fantastic feature if it worked; disappointed.

[Dima P.]

Hello,

Unfortunately, there are some technical limitations in the Sony medium changer drivers. There is nothing we can do about it, except the renaming workaround. As stated above we are going to provide the complete support of the Amazon VTL in the next versions (including the barcode reader support). Stay tuned.

[Gav@GH]

I'd like to add my voice to getting the missing barcode issue looked at in an upcoming patch, rather than waiting for a full release.

We're just completing a full POC for using Veeam and archiving to AWS (as a replacement for Symantec BE and tapes). It's been a long assessment and has included waiting for the new V8 Veeam servers and test build for both AWS storage gateways (Volume gateway and VTL gateway). The later giving us greater control over large media sets and archival control into Glacier.

Everything was looking fantastic - right up until the end when I've gone to recover a tape and realised there was no way to identify "Tape x" with the barcode on the archived tape.



Your suggested workaround is NOT a viable option; I have for example 5 tapes needed per month, but there is no way to identify which ones are which. It limits the creation to 1 tape at a time, which then need to be imported and manually renamed. Whilst I could created fewer (but larger tapes), to ease this overhead, it goes against the benefits of granularity in storage and recovery.

- Is there a better way to create and rename multiple tapes?
- Perhaps there is an alternative/updated driver that can be used? Blaming the limitations on your channel partners (that you've chosen) is not really good enough.
- Perhaps you could provide a patch?

We are 99% satisfied with our POC, but the 1% is a massive failure.

[Dima P.]

Hello Gav@GH,
Thanks for the feedback. Unfortunately, that’s the only widows changer driver Amazon supported. The fix we are working on is complex and does not fit the next patch.

If you don’t mind I’ll add you to the list of the users submitted for testing the new functionality and let you know once we have a private fix (or build) testing so you could show your customers complete integration or just check if it fits your requirements. Meanwhile, stay tuned. Thanks

[tsightler]

- Is there a better way to create and rename multiple tapes?

As an interim it looks like it might be possible to something with Powershell using the AWS Tools for Powershell and the Veeam Powershell API. The AWS Powershell toolkit has an cmdlet for creating and retrieving tapes (New-SGTapes and Get-SGTapes). My thought is you could potentially create a Powershell that creates tapes on the VTL and then immediately names them in Veeam. Unfortunately I won't have time to play with this for the next week or so but it looks doable at first glance. I know it's not ideal, but might help mitigate the issue until the more complex fix is implemented.