| Author |
Ridiculous Increase in Backup Time
|
|
| TheScullster 2005-06-08, 7:46 am |
| Hi all
For some reason, the length of time taken for our nightly backup seems to be
increasing at a ridiculous rate.
Backup device is Sony AIT3 tape (100-200Gb) on Win2003 server box backing
up local server and remote MS Exchange server.
In march, 60.5 Gb backed up in 7.5hrs.
Now, 68 Gb takes 10.5 hrs.
Each night the backup time increases by a few minutes, even if the amount of
data decreases slightly!
So far I have tried:
Using an unused tape.
Cleaning the drive with a cleaning tape, regularly on a weekly basis.
What more can I do?
Any suggestions gratefully received
Phil
| |
| Howard Kaikow 2005-06-08, 7:46 am |
| what software software?
try defragmenting the drives,
--
http://www.standards.com/; See Howard Kaikow's web site.
"TheScullster" <phil@dropthespam.com> wrote in message
news:1DqdnaVEGvwLcTvfSa8jmA@karoo.co.uk...
> Hi all
>
> For some reason, the length of time taken for our nightly backup seems to
be
> increasing at a ridiculous rate.
> Backup device is Sony AIT3 tape (100-200Gb) on Win2003 server box backing
> up local server and remote MS Exchange server.
>
> In march, 60.5 Gb backed up in 7.5hrs.
> Now, 68 Gb takes 10.5 hrs.
> Each night the backup time increases by a few minutes, even if the amount
of
> data decreases slightly!
>
> So far I have tried:
>
> Using an unused tape.
> Cleaning the drive with a cleaning tape, regularly on a weekly basis.
>
>
> What more can I do?
>
> Any suggestions gratefully received
>
>
> Phil
>
>
| |
| TheScullster 2005-06-08, 5:52 pm |
| Howard
Thanks for response.
The software is Veritas Backup Exec V9.1.
From your comments, do I take it that WinServer2003 fragments easily?
Phil
| |
| John . 2005-06-08, 5:52 pm |
| "TheScullster" <phil@dropthespam.com> wrote:
>Thanks for response.
>The software is Veritas Backup Exec V9.1.
>From your comments, do I take it that WinServer2003 fragments easily?
>
>Phil
Any NTFS volume should be defragmented at least once/week. Use a good
defragmenter such as PerfectDisk (www.raxco.com) or Diskeeper
(www.executive.com). Best option would be to defrag nightly BEFORE
the tape backup.
Also, isn't there an option to compact the Veritas catalog? It tends
to grow over time and could be contributing. Look for that and
compact the backup catalog.
| |
|
| Listen to the tape drive while it's backing up. If it is constantly
active, it may have trouble and retry a lot. If it sits there idle,
your server has slowed down.
If the software can backup to a bit bucket (preflight test), try that.
Alternatively, just test read the file system(s) you're backing up with
tar or a recursive copy /b to NUL: and check how fast you can read.
Move any log and temp files to a different file system.
Could network throughput from the Exchange server be the problem?
| |
| TheScullster 2005-06-09, 2:46 am |
| Thanks John/RPR
I will have to look into your suggestions and revert.
Whatever's happening can't be right!
Phil
| |
| Mark Fineman 2005-06-09, 5:47 pm |
| On 8 Jun 2005 13:17:46 -0700, "RPR" <rohbeck@yahoo.com> wrote in part:
> If the software can backup to a bit bucket (preflight test), try that.
> Alternatively, just test read the file system(s) you're backing up with
> tar or a recursive copy /b to NUL: and check how fast you can read.
Note that with some operating system/program combinations writing to
a null device is slower than writing to some real devices, so you may
find that things run slower still.
Typically the slowdown is because the I/O blocksize for the real
devices is many times larger than the blocksize for the null
device.
----== Posted via webservertalk.com - Unlimited-Uncensored-Secure Usenet News==----
http://www.webservertalk.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
|
| This suggestion seems really simple but It mights pay to also make sure there are no open files or other processes running at the same time as the backup. I'm using Veritas Backup EXEC 8.6 and have noticed the timing of the backup plays a huge part in how long it runs. | |
|
| Oh, interesting. I never noticed that. So far /dev/null and NUL: have
always been fast enough for me to sink data from a HD at max speed. But
yes, if you have a program that writes many small blocks to /dev/null
this may be an issue. I don't think it is with tar and dd.
Ralf-Peter
|
|
|
|