DrDude1
asked on
DLT7000 Backup fails to use the full 35G capacity
I am using a IBM/Quantum DLT7000 to do a FULL back up of 28 Gigabytes of MP3 data on a DLTIV 40/70/80 tape. Using BackUp Exec 8.6 (also tried version 10) the process goes over the 28G's, reaches about 30G, and asks for a second tape. For what I don't know, as stated, the original data is 28G. However, if I use Acronis True Image Server, it mounts the DLT drive and according to the softeware, compacts the whole HDD/28G on down to about 16G. Full backup on one tape, no problem. I would prefer to use BU Exec because I can choose folders instead of imaging complete drives. Why the heck would 28G not fit on a 35G tape? Are my BU Exec settings wrong? I am stumped.
rindi
Download all servicepacks and patches from veritas. Also use the veritas driver for the Tape drive. Your Windows should also be fully patched and uptodate.
Wow, 28gb of mp3 down to 16 that is pretty good. One thing in its favor is the image aspect.
When doing a file level backup there is overhead for each file. For example there will be a file header and trailer filemark. Regardless it should not be that much overhead.
Mp3 files are already compressed so with or without compression used for the backup it is expected that they would get about the same amount of data written to tape.
If it was softwrite errors then it would effect both products.
That 10.0 has the same problem leads me to believe that it is not a bug in BE.
Perhaps an OS update will take care of it.
Prior to this what was capacity of the tapes? If the tapes had at one time been used in an older model drive then that old capacity will be maintained. So if you have not tried them you might want to try new tapes. Oh and brand matters, Quantum or Maxell are the best.
When doing a file level backup there is overhead for each file. For example there will be a file header and trailer filemark. Regardless it should not be that much overhead.
Mp3 files are already compressed so with or without compression used for the backup it is expected that they would get about the same amount of data written to tape.
If it was softwrite errors then it would effect both products.
That 10.0 has the same problem leads me to believe that it is not a bug in BE.
Perhaps an OS update will take care of it.
Prior to this what was capacity of the tapes? If the tapes had at one time been used in an older model drive then that old capacity will be maintained. So if you have not tried them you might want to try new tapes. Oh and brand matters, Quantum or Maxell are the best.
ASKER
Greetings All,
Background: WIN XP SP1, Drivers from Veritas, Veritas 8.6 full lic. Version, Fuji-Film brand new tapes (recognized by the machine as 35G). This has kept me up two nights straight till 2 & 1 am respectively. I installed BE 10 trial version, just to see if it is a BE problem. Nope. Still the same. Then I said, I gotta ask at the EE, someone has got to have had similar problems.
I was able to follow a link http://support.veritas.com/docs/199542 from a different post whereas Veritas states:
1. The tape drive may be trying to compress data that is already compressed. If the data cannot be compressed any further than it already is, the attempt may cause the data to expand. Run a test backup with no compression to compare how much data can be written to the tape media without compression. When using hardware compression, software compression should be turned off, and vice-versa.
GO FIGURE! ...the attempt may cause the data to expand. WOW! Amazing!
Got up early this morning. Fired up the machines, turned off the Hardware Compression, and let BE rip. Yep, sure enough. Back-up successful. And dovidmichel, like you said, there is only a slight expansion, example; from Windows Explorer 28,4 GB (30.590.172.705 bytes) >>> to the 30,591,932,029 bytes that BE recorded in the Job History. Another thing I noticed is that the throughput increased from 247.00 MB/Min to 280.00 MB/Min; not bad for turning off the compression!
Just for experimental purposes, I am going to run a job and turn on the Software compression. I am interested to see how that will effect the whole situation.
Last but not least, even though this BE 10 looks nice, sadly to say I cannot afford the upgrade. Alas, I will have to de-install it and go back to my 8.6 version. (Hope turning off the compression under 8.6 solves this problem too!).
Thanks for the comments.
P.S. @dovidmichel, I will probably continue to use Acronis True Image to do my MP3 backup since it is on one dedicated 80G drive. However, on my 120G drive where my photos and videos are located, it requires folder/file backups (since I cannot image a whole 120G on a 35G tape). I see I must carefully control the BE jobs, since jpg/mpg and are already compressed.
Background: WIN XP SP1, Drivers from Veritas, Veritas 8.6 full lic. Version, Fuji-Film brand new tapes (recognized by the machine as 35G). This has kept me up two nights straight till 2 & 1 am respectively. I installed BE 10 trial version, just to see if it is a BE problem. Nope. Still the same. Then I said, I gotta ask at the EE, someone has got to have had similar problems.
I was able to follow a link http://support.veritas.com/docs/199542 from a different post whereas Veritas states:
1. The tape drive may be trying to compress data that is already compressed. If the data cannot be compressed any further than it already is, the attempt may cause the data to expand. Run a test backup with no compression to compare how much data can be written to the tape media without compression. When using hardware compression, software compression should be turned off, and vice-versa.
GO FIGURE! ...the attempt may cause the data to expand. WOW! Amazing!
Got up early this morning. Fired up the machines, turned off the Hardware Compression, and let BE rip. Yep, sure enough. Back-up successful. And dovidmichel, like you said, there is only a slight expansion, example; from Windows Explorer 28,4 GB (30.590.172.705 bytes) >>> to the 30,591,932,029 bytes that BE recorded in the Job History. Another thing I noticed is that the throughput increased from 247.00 MB/Min to 280.00 MB/Min; not bad for turning off the compression!
Just for experimental purposes, I am going to run a job and turn on the Software compression. I am interested to see how that will effect the whole situation.
Last but not least, even though this BE 10 looks nice, sadly to say I cannot afford the upgrade. Alas, I will have to de-install it and go back to my 8.6 version. (Hope turning off the compression under 8.6 solves this problem too!).
Thanks for the comments.
P.S. @dovidmichel, I will probably continue to use Acronis True Image to do my MP3 backup since it is on one dedicated 80G drive. However, on my 120G drive where my photos and videos are located, it requires folder/file backups (since I cannot image a whole 120G on a 35G tape). I see I must carefully control the BE jobs, since jpg/mpg and are already compressed.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
thanx.
ASKER
Greetings All,
Here the results with Compression Off:
Backed up 8714 files in 604 directories.
Processed 30,591,932,029 bytes in 1 hour, 43 minutes, and 54 seconds.
Throughput rate: 281 MB/min
Here with Software Compression On:
Backed up 8714 files in 604 directories.
Processed 30,591,932,029 bytes in 1 hour, 42 minutes, and 20 seconds.
Throughput rate: 285 MB/min
Only a nominal and insignificant throughput increase. But still completed successfully. @rindi, I will take your tip on testing the simple text files. Will keep a close eye on backing up mixed folders. Think I'll add a Gig of docs to the MP3 drive and see what happens with Hard or Software compression turned on. Wonder if it will compress only the text files, skip the mp3s, and still fit the 29G on one tape.
Here the results with Compression Off:
Backed up 8714 files in 604 directories.
Processed 30,591,932,029 bytes in 1 hour, 43 minutes, and 54 seconds.
Throughput rate: 281 MB/min
Here with Software Compression On:
Backed up 8714 files in 604 directories.
Processed 30,591,932,029 bytes in 1 hour, 42 minutes, and 20 seconds.
Throughput rate: 285 MB/min
Only a nominal and insignificant throughput increase. But still completed successfully. @rindi, I will take your tip on testing the simple text files. Will keep a close eye on backing up mixed folders. Think I'll add a Gig of docs to the MP3 drive and see what happens with Hard or Software compression turned on. Wonder if it will compress only the text files, skip the mp3s, and still fit the 29G on one tape.
In the test you want to run, compression is not smart enough to be selective. All the files will be processed with compression but the end result will be that only the text files will actually compress since you can not compress a compressed file. That is where the time is lost, trying to compress a file that is already compressed.
One question on the above test. Is the # of bytes processed the # read from disk or the # written to tape?
The reason I ask is because I'm still thinking about the original question on why it is spanning tapes at 30gb instead of 35.
One question on the above test. Is the # of bytes processed the # read from disk or the # written to tape?
The reason I ask is because I'm still thinking about the original question on why it is spanning tapes at 30gb instead of 35.
ASKER
Hi dovidmichel,
I was clear on the non-selective compression. I just was wondering how BE and the machine would handle the mixed files. So, I added a folder with 1.28G of docs, txt, xls and .pub files. For the first test I turned on Software Compression:
Backed up 28868 files in 1125 directories.
Processed 31,980,968,461 bytes in 1 hour, 47 minutes, and 34 seconds.
Throughput rate: 284 MB/min
This, as well as the results mentioned above are from the Job Log, thus, # of bytes written to tape, according to BE. The actual size according to Windows Explorer: is 29,7 GB (31.975.251.381 bytes). Here it looks as though BE didn't compress any of the text files. Hmm. I will run the same files using Hardware Compression tomorrow. It is almost midnight here in Germany, gotta get to bed early tonight!
BTW. Yep, the spanning at 30G has me bewildered too. Here is the log file below from the first "problem" job. It only took slightly longer, but broke(requested a second tape; when I canceled) with only two remaining directories (BE just does not like Vertical Horizon and Wynton Marsalis music I guess :-) those are the last two directories).
Backed up 8698 files in 602 directories.
Processed 30,508,371,488 bytes in 1 hour, 57 minutes, and 43 seconds.
Throughput rate: 247 MB/min
The other thing is that I really don't have that much mixed environment. As a semi-pro photographer I have nearly 20G of jpg photos. And perhaps just as many video clips. I might as well not even try compression on these files, knowing that it has no effect on them anyway. Will simply plan on buying a few more DLT tapes.
Good night for now.
DrDude1
I was clear on the non-selective compression. I just was wondering how BE and the machine would handle the mixed files. So, I added a folder with 1.28G of docs, txt, xls and .pub files. For the first test I turned on Software Compression:
Backed up 28868 files in 1125 directories.
Processed 31,980,968,461 bytes in 1 hour, 47 minutes, and 34 seconds.
Throughput rate: 284 MB/min
This, as well as the results mentioned above are from the Job Log, thus, # of bytes written to tape, according to BE. The actual size according to Windows Explorer: is 29,7 GB (31.975.251.381 bytes). Here it looks as though BE didn't compress any of the text files. Hmm. I will run the same files using Hardware Compression tomorrow. It is almost midnight here in Germany, gotta get to bed early tonight!
BTW. Yep, the spanning at 30G has me bewildered too. Here is the log file below from the first "problem" job. It only took slightly longer, but broke(requested a second tape; when I canceled) with only two remaining directories (BE just does not like Vertical Horizon and Wynton Marsalis music I guess :-) those are the last two directories).
Backed up 8698 files in 602 directories.
Processed 30,508,371,488 bytes in 1 hour, 57 minutes, and 43 seconds.
Throughput rate: 247 MB/min
The other thing is that I really don't have that much mixed environment. As a semi-pro photographer I have nearly 20G of jpg photos. And perhaps just as many video clips. I might as well not even try compression on these files, knowing that it has no effect on them anyway. Will simply plan on buying a few more DLT tapes.
Good night for now.
DrDude1
I'm not a Backup Exec user and question just what does the megabytes processed value equal.
Does it show the mbs read from disk or mbs written to tape?
Does it show the mbs read from disk or mbs written to tape?