• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 334
  • Last Modified:

Backing up on SCSI tape takes too long

We have a SCSI tape which daily backups our mail server. For some reason the time to make a backup increased from 8 hours to 21 hours. There was no significant increase on the data to backup and we are wondering what could have caused this.

Any ideas?

Thanks
0
AJKBOC
Asked:
AJKBOC
  • 4
  • 4
  • 3
  • +1
2 Solutions
 
speshalystCommented:
Did this increase from 8 - 21 hours happen over a period of time.. or was is it outa the blue?
Are there any other tasks running on the Server during the backup window.. like a AV scan or something ?
or some kinda maintenance operation...
0
 
TapeDudeCommented:
If you can hear the tape drive 'shoe-shining' (repeatedly attempting to write over the same section of tape) then the backup tape might be worn and in need of replacement, or the drive heads may need cleaning... or both.

You haven't stated if the drive is connected directly to the server... check that the server's disc isn't heavily fragmented, or, if the drive is backing up over the network, that there isn't some other large transfer going on at the same time, or that the network hasn't switched to a lower speed for some reason (ie, on a 1GB network, check the network settings to ensure it hasn't dropped down to 100MB/S)

Other possibilities - problem with SCSI termination means the drive is working as SE rather than LVD, or the tape heads are worn, or the write circuitry of the drive is malfunctioning....
0
 
LTO_MoeCommented:
What kind of tape drive is it?  And how big is the data set you are backing up?  So far, there are a myriad of possibilities for the problems you are having.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
AJKBOCAuthor Commented:
We are backing up our mail server (Sun Messaging Server) on a Solaris 10.0 using imsbackup on an Sun DLT-S4 tape driver. The size of the data set is 450 GB and the tapes are 400-800 GB. On the ad of the tape driver it was refering to 60MB/s. With very quick calculations in our case we have 6MB/s.

We don't hear any weird noises coming our of the tape drive. It is connected through a SCSI card.

Is there a tool that can test the tape for Solaris? (writing speed, termination etc)

The increase was out of the blue. From 8 hours went to 12, then after a few days to 15 and now to 21. The incease in data was only a few GB (30-40). There are other program running on the server but the programs were always there. There is no antivirus currently installed on the server.

Thanks for your time.
0
 
TapeDudeCommented:
Try TARing a known amount of data (say, 10GB) and seeing how long it takes, then divide the data quantity by the time taken to get throughput. Make sure you do this on the machine the drive is attached too.

How old is the tape? Have you cleaned the drive heads?
0
 
LTO_MoeCommented:
Couple of things to try:

1.  Run a cleaning tape through it.  (Even if the tape is not "dirty", a cleaning tape actually helps to recalibrate the drive.

2.  Make sure the cooling fan on the back of the unit (assuming its a basic external drive) is working properly.  Quantum drives (SDLT, DLT-S4) are very sensitive to temperature and overheat easily.

3.  Try a new piece of media.

Also, the DLT-S4 tapes should be 800/1600GB.  If you do have "400/800GB" media, it may be frankenstein media and the culprit.
0
 
AJKBOCAuthor Commented:
Sorry for delaying. I was waiting for the cleaning tape. I tried it but no use. It took 23 hours today.
We tried a new tape but still the same. The cooling fan on the back of the unit seems to be working. I am not sure if i can check this in another way.

The tape we have is 800/1600 GB.

Any other ideas?

Thanks.
0
 
LTO_MoeCommented:
Hmmm...

Make sure that the block size has not changed on the backup job.  The higher, the better.  The 'S4 supports up to a 16MB block size.

Otherwise, replace the drive.  Hopefully, it's still under warranty.

Really, there's not much known about the 'S4's reliability, but we've heard (and confirmed on our own) the SDLT 600's can start to lose calibration after only a couple of hundred tape hours.
0
 
AJKBOCAuthor Commented:
What do you mean loosing calibration? What is this? And what do you do if it does? Also how can i check the block size and how to i change it?

Regards
0
 
AJKBOCAuthor Commented:
Since we are using imsbackup to do the backup I read the options reffering to the block and here what is says:

"Everything written to the backup device is performed by blocks of the size 512xblocking_factor. The default is 20."

What is the maximum factor I can use for the DLT-S4? Also since it is backing up a lot of small files will this help?

Thanks again.
0
 
LTO_MoeCommented:
The maximum blocking factor would be 32 (512K x 32 = 16MB).  Your current setting should still be more than adequate for a decent throughput.

IIRC, the backup software will bundle multiple small files together to create the blocks.

Calibration determines the drive's ability to read and write to the tape.  There are a number of factors that can affect the calibration of the drive head.  There are companies out there that can recalibrate/repair/replace the drive head, but there's nothing you can do on your end.  Most of my experience with that sort of voodoo has been with SDLT drives (the predecessors to the 'S4).

I would say repair or replace the drive.
0
 
TapeDudeCommented:
It's 512 BYTES, not kilobytes. So with a default blocking factor of 20 you get a tape block size of 10240. Giving it a blocking factor of 32 would mean a 16k block size.

In my experience, once you get above a 10k (or so) block size most tape drives don't get appreciably faster, and I'd be amazed if your system was happy to transfer 16Mb block sizes. As a maximum I'd recommend 64k (blocking factor of 128).

You might see a sudden decrease in speed if the device/adapter was changed from working in fixed block to variable block transfers, but you say that it gradually slowed down, so that's probably not the problem.

If you've gone through all the possibilities mentioned in my post of the 11th, then it's almost certainly a drive failure. Get it swapped out.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now