Forum Discussion

Mal_Boteju's avatar
Mal_Boteju
Level 3
20 years ago

Different Lengths of Time to Backup Same Data on Same Configuration

Same Job, Same Configuration, Same Media and Same load on the server and the network bandwidth. BUT the time to finish a 44 GB backup can vary anything between 7 to 14 hours on different days. The change to data is less than 1 GB if anything.

Assuming this is anything to do with the network- Does the backup speed remains constant at the speed it started at during a job ? (i.e if the network becomes quiet after an hour does it not pick up that speed)

Assuming this is anything to do with hardware load on the server- Shouldn’t it pickup up speed when the system is quiet?

On this particular server the job start at 1800 hrs when there is no load on this machine (its the ERP system & SQL db and everyone's gone home by then)

I cannot seem to identify a reason that can justify a 100% increase in time it takes to finish an identical job.

What else can cause this behaviour ? Has anyone else seen this?

P/S For various reasons I need to do a full backup rather than an incremental one on this server. So that is not an option as a measure to save time.
10.x and Earlier
Backup and Recovery
Backup Exec
  • GTeley's avatar
    GTeley
    Level 3
    7 months ago

    Almost 20 years on and still the same issue. And of course without a clue from 'technical support' as to what could cause it. I truely believe they don't understand their own product.

  • ray_littlefie1's avatar
    ray_littlefie1
    Level 6
    20 years ago
    Mal-
    You should consider your removable disks as a variable too.
    I'm not sure what type of rotation you have set up, but would it be possible to perform an erase on all the B2D files on the removable media prior to the nightly backup? (I don't mean delete them- rather right click and "erase') I know this is inconvienient, and I'm not suggesting this as any type of permanent solution, but am simply attempting to rule out the possibility of a disk related issue.
  • Mal_Boteju's avatar
    Mal_Boteju
    Level 3
    20 years ago
    Nothing personal. I wrote the same comment for the below thread. Yes seeing this again !!!

    http://forums.veritas.com/discussions/thread.jspa?forumID=103&threadID=53699

    This is a typical "technical support" reply. The first post clearly states that it is now taking longer than it usually did. We would have expected to see an answer which highlights the reasons why a job can take longer given the above conditions...rather than pointing out the most obvious anyone could have found through a basic search.

    I wonder if these people who actually provide support ever engage their brains while doing their job. Perhaps the software they use doesn’t say on the screen "use your brains" or "take trouble to read"...
  • Amruta_Bhide's avatar
    Amruta_Bhide
    Level 6
    20 years ago
    Hello,

    You could try going through the following Articles:
    Reasons why the data throughput rate can be slower than the theoretical maximum when backing up to tape media http://seer.support.veritas.com/docs/231488.htm

    What Backup Exec settings can be modified to reduce the amount of time it takes for a backup to run?
    http://seer.support.veritas.com/docs/249090.htm

    How to correct slow backup performance, slow virus or pre-job scans, and agent initialization problems on fragmented Windows NT, Windows 2000, and Windows 2003 server partitions http://seer.support.veritas.com/docs/237444.htm

    ******************************************************************
    *****************************************************************

    Note : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to ‘answered questions’ pool.


    Thanks.
  • Mal_Boteju's avatar
    Mal_Boteju
    Level 3
    20 years ago
    Hopefully someone from Veritas could tell us which other paramters can actually cause this behaviour ?
  • MitchR's avatar
    MitchR
    Level 6
    20 years ago
    We're getting the same thing - job that take 3-4hrs one day sometimes take 8-9hrs. No rhyme or reason to when it's slow or fast. Day of week doesn't matter.

    I have noticed that on slow days, all the jobs seem to run slow. Thus it's not a client issue.

    Some jobs use AFO, some don't - that's not a factor.

    Our BE server isn't doing anything else- just backing up to tape. NIC settings are set to 1gb/full duplex. CPU utilization is low all of the time. Tapes are getting overwritten on a normal rotation, and drives are frequently cleaned.

    Some clients are on the same subnet on a fairly quiet part of the network, so I don't think this is from heavy network traffic.

    We're on the latest patches of BE 10. We reboot maybe every 4-6 months for security updates. Speeds go up & down regardless, so it's not a memory leak.

    Any info from others getting this problem would be helpfull!

    -Mitch
  • Mal_Boteju's avatar
    Mal_Boteju
    Level 3
    20 years ago
    I dont use AOFO. Its definitly not the the SQL as I dont use the agent.

    These are simply files, pretty much the same lot. This is why I even didnt think this has anything to do with the software comrpession.

    I'm backing up to Removable Disks not tapes. But I'll think about splitting the job, into some logical parts.

    cheers
    Mal
  • uz's avatar
    uz
    Level 6
    20 years ago
    hard to say,
    there are a lot of options that could be the cause.

    When looking at the individual backup sessions within the job ( C: drive, D: drive, SQL database, Shadow copy component etc.) can you define witch one slows down - or doe all of them slow down ?!

    Are you using the SQL Agent if yes, with or without database consistency check ? - If with, when does the SQL server itself run its maintenance - insure they do NOT overlap.
    Are you using AOFO ?
    If no AOFO what are the settings for backing up open files? ( with a lock or e.g. after close within x seconds )

    If all this does not clear the problem, try splitting the job in parts for each backup set ( C, D, SQL, shadow copy etc) and simply append them to the tape. This will be a little slower, as the tape will have to be revinded and back but it will be much easier to find out existing bottlenecks - whether they are network related or BEWS related.

    hope this helps a little

    regrads

    uz