backupjob from linux files to tape takes ages

[dsmagghe]

hi i am evaluating the product coming from barracuda.
i have a win2012 machine with a SATA tape library connected to it
IT backups local and remote VMs of hyper-v very fast.
next to the vms I need to backup +/- 4 TB files on a linux machine, I have installed the agent and selected the folder to backup.
it is actually still "building file list" for over 35 hours now, without backing up anything. On the linux machine I can see the veeam ap in TOP using CPU and bandwith but I don"'t think it is normal it takes that long...

[Dima P.]

Hi dsmagghe,
Can you please elaborate what version of Veeam B&R are you using? I am assuming you are backing up vm’s via file to tape job from a network location is that correct? Thanks

[dsmagghe]

version 8.0

yes from a network location, but the vm's work fine only the file based backups don't work

[dsmagghe]

when on the tape proxy i map the drive to Z: (the linux machine has samba installed) it only takes 12 minutes to build the file tree list.
But I don't think this is best practice. ..?

[veremin]

Just to be clear - there is a backup server running on some machine, as well, as a tape server (that has a library attached) residing on a different machine. If you select a network location in the source settings of a file to tape job, performance will be dismal. If besides that you also map it as a drive to a tape server, performance will be better? Right? Thanks.

[dsmagghe]

the linux agent is buggy i think, i can't even stop the backup process without restarting running veeam services

[veremin]

Can you open a support ticket regarding it, please? Once opened, please post its number here, so that, we can follow the case. Thanks.

[NTmatter]

Greetings - I'm running in to a similar issue myself. Could I get a "me too" on that support ticket?

We're (ab)using Copy Files to Tape for our archival process so that we can perform small single-file recoveries without having to do an intermediate 6TB restore from tape. I know, it's not called Veeam Archive and Replication, but it is still better than our old solution.

From a bit of digging during the indexing phase, it looks as if Veeam is opening a new SSH session for every directory and file in the tree at a rate of roughly two sessions per second. This is a rather slow process for 70k files. Some of these connections also seem to fail in large batches (excerpts from logs are below).

Wasn't Veeam capable of leveraging mlocate for file indexing operations, or is this limited to regular VM backups with indexing enabled?

Some background information on the systems at hand:
Veeam Server:

• Veeam 8.0.0.2030
  Windows Server 2012R2
  8-core Xeon
  16GiB RAM
  10GbE Ethernet
  HP MSL2024 + LTO5

Source server:

• Ubuntu Server 14.04.3 LTS
  Dual Quad-Core Xeon @2GHz
  16GiB RAM
  10GbE Ethernet

mlocate exists:

Code: Select all

# which mlocate
/usr/bin/mlocate

Successful execution from /var/log/auth.log:

Code: Select all

Sep 13 11:42:11 archive sudo: veeam-backup : TTY=unknown ; PWD=/home/veeam-backup ; USER=root ; COMMAND=/bin/ls -dl /path/to/file/redacted.txt
# Time passes ...
Sep 14 11:05:47 archive sudo: veeam-backup : TTY=unknown ; PWD=/tmp ; USER=root ; COMMAND=/usr/bin/perl veeam_soapGUID_HERE.pl -d -c -l libGUID_HERE -e /tmp/veeam_errorGUID_HERE

Unsuccessful execution from /var/log/auth.log:

Code: Select all

Sep 11 16:49:18 archive sshd[4130]: Disconnecting: Packet integrity error.
Sep 11 16:49:18 archive sshd[4081]: pam_unix(sshd:session): session closed for user veeam-backup
Sep 11 16:49:18 archive sshd[4133]: Accepted publickey for veeam-backup from [VEEAM IP REDACTED] port 49697 ssh2: RSA [PUBKEY REDACTED]
Sep 11 16:49:18 archive sshd[4133]: pam_unix(sshd:session): session opened for user veeam-backup by (uid=0)
Sep 11 16:49:18 archive systemd-logind[705]: Removed session 11968.

[NTmatter]

In case the OP didn't create one, I've just opened support ticket #01060600.

No hurry, as it's a slow and sunny morning out here

[Dima P.]

Thanks for sharing the details. Let’s see how the investigation at the support side will go.

[NTmatter]

Sounds like it's working as intended, unfortunately. One invocation of "sudo ls" per file or folder in the tree.

I've put in a request to use something along the lines of "find /path/to/tree -ls" or to use "mlocate" just like the regular guest file indexing does. Until then, we wait. (and wait and wait and wait )