NAS to tape very long

[matteu]

Hello,

I have differents issues about how to manages my jobs.

I have :

3 Backup jobs from 3 NAS to repository 1
Then I perform Backup copy from repository 1 to repository 2 (1 per job).
Then I do backup to Tape from backup copy repository data (1 job with 3 backup copy source).

Unfortunately, the NAS backup is arround 50To.

I have library with 2 drive.

1) I enable parallel processing for seperate jobs and inside job on the media pool but Veeam doesn't use it. Only 1 drive is used and arround 140MB/s. Is it normal ?
2) The backup to tape job take several days and the backup copy jobs got error because file is locked by backup to tape job. How can I manage it ?
3) Is it normal there is no data reduction for NAS job ? If my source data = 50To it writes 50To on the tape. When it's VMs, I have 8 less data from the read than I have to write.

Thanks for your help

[HannesK]

Hello,

1) it depends on the file size and the repository speed. With smaller files, it might might be normal. Large files (many MBytes) it should be faster if the repository is fast enough.
2) I only see the option to wait
3) It depends on the data. Office documents are zipped already. Media files are also not compressible. So the data reduction rate for NAS backups is usually lower than for VMs. Zero reduction sound like a corner case, but as I said, it depends on the data.

Best regards,
Hannes

[matteu]

Thanks for your answer.

1) It's for NAS to tape, so, I can't say what files size are because it's lots of vblob right ?
The repository is fast (proliant xl 420 gen 10) and dedicated on this task during my test. I can perform backup copy into it with 1GB/s.
With parallel it should be at least 280 MB/s and reduce my windows from 8 days to 4 ... I don't understand why it's not doing it, I opened support ticket "06132575"

2) That means when Full need to be performed, all my backup copy jobs will fails and then need to be repaired when they can launch right ?

3) It's lots of office documents files so it sounds to correspond !

[HannesK]

1) the file size is what's on the source share. in the end, the source data is backed up into the 64MB vblob files and from there it's extracted to tape in native format again. With lots of office documents, I would say your speed sounds normal.

2) I'm not sure, why a repair would be needed. that sounds wrong

[matteu]

Thanks for your answer.

What could be my solution to have faster speed ?
Actually my setup is :
NAS 1 : 30 To
NAS 2 : 3 To
NAS 3 : 20 To
NAS 4 : 50 To
VM : 30 To

I have 2 libraries :
Lib 1 with 2 drives : Dedicated for all NAS jobs
Lib 2 with 2 drives : Dedicated for VM jobs

I have 3 jobs to tapes :
job 1 : NAS 1 + 2 + 3 -> Lib1
job 2 : NAS 4 -> Lib 1
job 3 : VM -> Lib 2

The issue is my job to tape are really long for full with 7/8 days.

How would you improve it ? Even if parallelism would work it's 4 days locking the lib 2 that means no daily to tape...

[HannesK]

it's hard to say. it might be a physical limit of reading the small files. you can check with support whether they see something in the logs, but I doubt that it will help

smaller jobs might be a workaround, but not really nice...

[matteu]

Thanks for your answer.

Support is working on the case and they escalate it to RND because the result is unexpected with the configuration I used.