Linux Agent Makes me crazy

[rurouni]

Hi,
Though i'm very satisfied with vm backups with veeam. I'm quite disappointed with the agent. I'm struggling to deploy it and make it work.
In our scenario, we're backuping hana database with Dump pre-script, and delete dump post-script

We used pre-freeze and post-thaw, like we do on our vms, behaviour is quite strange because on a physical server the freeze and thaw is performed before the backup itself starts.
Support suggested to use pre-job and post-job script, but first it doesn't seem to support Shell script, second, its is not appropriate if we create a job with multiple servers, the pre-job script will not run on the backed up servers.

Finally, i don't know why but i observed File level backup doesn't work, (it sits waiting forever), while Volume backup does which again is not appropriate in our scenario.

We're running HPE/Dell Hana appliances with supported SLES 12 operating system.
Case ID: 03305768.

Any Help appreciated.

[PTide]

Hi,

Just let me break down your post into three bullets:

We used pre-freeze and post-thaw, like we do on our vms, behaviour is quite strange because on a physical server the freeze and thaw is performed before the backup itself starts.

Would you give more details, please? The normal order of actions is as follows:

0. Pre-job scripts starts
1. Job starts
2. Pre-freeze is executed
3. Snapshot creation is triggered
4. After snapshot is created, post-thaw is executed
5. Agents starts reading data from snapshot and sending it to the repository
6. Backup finishes, post-job script is executed.

Support suggested to use pre-job and post-job script, but first it doesn't seem to support Shell script

Remembering you other post, I guess you configure VAL job from VBR interface. If you use 'Managed by Server' mode then pre/post-job scripts are supposed to be executed on VBR side and therefore shell format is not supported. To execute scripts on the target machine you have to use 'managed by agent' mode.

Finally, i don't know why but i observed File level backup doesn't work, (it sits waiting forever), while Volume backup does which again is not appropriate in our scenario.

Please describe what you see in the session log, and what are your job settings?

Thanks!

[rurouni]

First thanks for the quick answer.

Correct, i use managed by veeam server mode. what would be the pro and cons between managed by veeam server and managed by agent?
I have multiple jobs to run on muliple servers, i need a centralized management. that s why i choosed managed by veeam server mode.

In the session log i had this:

Code: Select all

[05.12.2018 21:25:19] <140398139934464> lpbcore| Lease keeper: sending keep-alive request.
[05.12.2018 21:27:49] <140398139934464> lpbcore| Lease keeper: sending keep-alive request.
[05.12.2018 21:30:19] <140398139934464> lpbcore| Lease keeper: sending keep-alive request.
until
[06.12.2018 01:20:26] <140398139934464> lpbcore| Lease keeper: sending keep-alive request.
[06.12.2018 01:22:48] <140397271557888> lpbcore| Session progress: 0%; processed size: 0 processing speed: 0 bottleneck stats: 0/0/0/0
and Finally
[06.12.2018 01:23:11] <140397271557888> lpbcore| Session progress: 100%; processed size: 2181218304 processing speed: 151238 bottleneck stats: 0/0/0/0

I waited more than 50 minutes, the job said it was backuping file system but it didn't really start. I let it run all night long, at the end the job finally succeeded.

Job took 4hours 19 minutes to process one server only and backup 2gB really in this test.

However Session stats are strange: Processed 13,2tB, Read 2gB, Transfered: 169GB.

I'll try with managed by agent mode.

[PTide]

Generally speaking, in 'managed by agent' mode the agent start jobs by itself, although it receives settings from VBR. In 'managed by server' mode job start is triggered by VBR server.

The file-level job stats look strange, indeed. Just to clarify - you have 13TB server, and selected 2GB of files to backup, however the job ended up with 169GB transferred while the actual backup file is 2GB in size, right? I would suggest to check if it was really 169GB transferred over network, or it is the stats that are wrong. Regarding the performance issue - that should be investigated by our support team, so please stay in touch with them.

Thanks!