cancel
Showing results for 
Search instead for 
Did you mean: 

Running jobs do not continue for hours!

Carel-UU
Level 2

This is my first post, and I have 3 related questions...

We have a 7.4 TB backup job (Linux with the VTARalus-agent; a zillion of small files) running which takes already more than a week now. The job is still "running" but there is minor communication and the byte count is not increasing for more than 24 hours. Suddenly only 1 GB is added and the job stalls again.

1. What could be causing this ?
Because of the apparent network hickups the job is taking more than a week

2. If it is indeed a firewall statefull port that is closed after some time, then how could I trigger the BE-agent to restore the connection ?

As a matter of fact when I try to download a large amount of data from internet, there's a lot of downloadmanagers that could easily restore connections and continue halted download jobs, even days later. Why is this not a "simple" feature in Backup Exec ? That feature could provide you with the possibility to halt running jobs, do some maintenance on mediaserver or backup-client, and continue the halted job ....

1 ACCEPTED SOLUTION

Accepted Solutions

Carel-UU
Level 2

When RedHat is supported, then Scientific LInux is....

Taking a snapshot on a system for a multi-day backup makes no sense, since the snapshot will also become inconsistent (running out of snapshot-space)

BUT:

As a matter of fact we solved the problem of the slow backup. Alsmost certainly it turned out that a faulty network-cable caused a lot of 'lost packages'.

changing the cable for a new CAT6 seemed to solve it, though it still took a while for the job to continue full speed.

 

View solution in original post

4 REPLIES 4

pkh
Moderator
Moderator
   VIP    Certified

Pausing a backup job is not possible because backups is preserving the state of a server in a particular moment in time.  Suppose you have a directory with 10 files and you have backed up the first 5 files.  If you have pause a job for 1 day and all the files have been modified since you pause the job, do you backup the first 5 files again?  If not, the first 5 files would be from the previous day and the last 5 files would be from now.

If you are backing up a lot of small files, the response would be slower than if you were to back up a few big files.

What is the bandwidth of the link between the media server and the Linux server?  BE requires a very stable connection between the two servers.  Normally a WAN link does not cut it.

What is the version of BE that you are running and what is the version of Linux that you are trying to backup?

Carel-UU
Level 2

I know that "pausing a job" is not likely to create a 'consistent backup', but when a complete backup takes over a week, then also the first files could be a week older than the last files ..... not very consistent either.

I use Backup Exec 2010, and the client is Scientific Linux 5.3 (RH-clone).

The lan-connection is perfect, GigaBit, and the backup starts at a rate of 2 GB/min. But then it has it backup a lot of small files, hence the average speed is dropping.... But the problem is more that sometimes for various hours the job seems to have stopped, but stays in running condition. There is no way I could trigger the job again to continue.

 

pkh
Moderator
Moderator
   VIP    Certified

Your variant of Linux is not supported. See the SCL below

BE 2010|2010 R2|2010 R3 Software (SCL)

 

I don't know about Linux, but for Windows, BE create a snapshot of the disk, so that the backup is consistent.

Carel-UU
Level 2

When RedHat is supported, then Scientific LInux is....

Taking a snapshot on a system for a multi-day backup makes no sense, since the snapshot will also become inconsistent (running out of snapshot-space)

BUT:

As a matter of fact we solved the problem of the slow backup. Alsmost certainly it turned out that a faulty network-cable caused a lot of 'lost packages'.

changing the cable for a new CAT6 seemed to solve it, though it still took a while for the job to continue full speed.