File to Tape backup uses LAN

[4c7]

Hello, I installed 2 veeam servers (1 that's "primary" and one specifically for tape jobs).
Tape server has got all the LUN's in read mode attached to it for backups (I'm using Symantec, but trying out veeam). So I created a file to tape backup (we have about 1 tb worth of doc files, 600k+ files). So Symantec does it faster and doesn't use LAN to transfer data from LUN. So I assume veeam takes data from file server via LAN and then writes it to tape.
The question is - is this by design or am I missing something?
I tried creating job from the tape server itself, but veeam doesn't "see" the luns attached.

Thanks in advance.

[Shestakov]

Hello,
Could you specify how did you connect the tape device? VBR supports such types of direct connections as Fibre Channel (FC), Serial Attached SCSI (SAS), SCSI.
Backup to tape job copies existing restore points to tape. So you need to create backup or backup to tape job first and then set backup to tape job.
Thanks!

[4c7]

I'm using file to tape backup, not VM backup. I'm backing up files, not VM's.
Tapr Library is connected via FC. The backup itself works fine, but slow, since its using LAN instead of FC to transfer data.

[Shestakov]

Sorry, my bad. Second part of my post was about backup-to-tape instead of file to tape.
Regarding file to tape, could you provide your bottleneck statistics (Load: Source > Proxy > Network > Target ) and processing rate?
In general File-to-tape works much slower if dealing with a vast number of small files, like in your case.
Thanks!

[4c7]

Yeah, I know that it works slowly, the point is... It doesn't take data from LUN, it copies it over the network from the "source" server to tape server.

Again. I have this LUN attached both to file server and tape server. Tape server has LUN in read only mode. It should be able to take data from LUN directly, not transfer it via LAN from file server.

ps. Primary bottleneck: Source 87%, duration 13:26:49, processed 932,2 GB, processing rate - 20mb\s, we have 1 gb\s network adapters.
pps. when it does incremental it goes through all files again?? So incremental job took 11:36:01 (160mb of data) to complete. WTH?
ppps. what is weird. job log contains 2 time stamps. 0:33:45 and 0:02:07. which doesn't really sum to ~12 hours. WTH??

[Shestakov]

Try to change job settings: on "Files and folders" step choose tape server, then click "Add" and check if there is the mounted LUN storage. Choose files to copy from the LUN and see if the backup speed will be improved.
By the way, what is the full bottleneck statistics: Proxy, Network, Target?
Thanks.

[4c7]

I suppose you were asking for this:
Source 87% > Proxy 0% > Network 0% > Target 0%

Just like i said in my original post "I tried creating job from the tape server itself, but veeam doesn't "see" the luns attached."
It only recognizes disk C and the CD-ROM. The luns are attached in read-only, i triple checked that.

ps. the next incremental took ~12 hours again. 220mb of data. Tell me this is a joke, please.

[Dima P.]

So the lun is not mounted to the tape server as a volume or folder, is that correct?

[4c7]

Ehm, is there a way to mount it? I mean, its a part of a file server cluster. It supposed to be active on the cluster?

ps. sorry for the late reply.

[foggy]

Are you probably talking about retrieving VM guest OS files directly from the LUN where VM resides and copying them to tape?

[pufferdude]

220MB over 12Hr means something is seriously wrong with the setup... even if it WERE using a single Gig network link you should be seeing around 100MB/sec (that's what I see, on a NAS with 300+k files) and a single Gig link between NAS and tape server.

[4c7]

I appreciate your concern, but nothing is wrong with the backup, something is wrong with Veeam. Since SBE does the same incremental backup in a matter of minutes.

2 foggy, no, I'm just coping doc,rar,jpg,pdf files from a file share.

[pufferdude]

Do you have multiple (Veeam) proxies enabled? I've seen rare cases where Veeam's automatic proxy selection chooses a *way* wrong proxy (even one across a wan!) and of course this results in crazy bad backup times (and network utilization you're not expecting.) It's easy enough to look in the job to see which proxy it picked. If need be you can force the desired proxy within the backup job. This of course could have nothing to do with your issue, just throwing it out there.

[4c7]

Thanks, I will check it out and return with results. Sorry for late reply.
ps. Can we backup volumes deduped with WS 2012-2012 r2?

[Shestakov]

Yes, you can.
There is a topic with best practices and our customers` examples. Please take a look. Thanks!

[veremin]

If you're going to backup deduplicated volumes to tapes, be aware that those volumes will be re-hydrated to their original size during backup. Thanks.

[4c7]

So, there is no way to choose a backup proxy for a File to Tape job.

[4c7]

So, I have no idea what had changed (maybe 2a did the trick) this backup now takes only 1 hour to complete. Which is still bad compared to Symantec, but good enough for me not to care. So this is settled. God bless.

[Shestakov]

Thanks for updating the topic!
Glad to know it works much better now. Has it decreased from 12 hours to 1 hour?
We will keep working. More feedback we get, more understanding we have what to improve first. So, thanks for the feedback!

[4c7]

Yes, from 12 hours to 1.