Re: [Bacula-users] DLT 40/80GB never reaches 40GB
On Tuesday 25 October 2005 22:31, Ryan Novosielski wrote: One other thing to note -- sometimes the tape drive will improperly determine the tape size for whatever reason. I have had experience with a DLT7000 drive that, for whatever reason, initialized a tape to 15GB. After that, I had to manually set the drive to 35GB and re-initialize it. After that, no problem. Interesting. I have never heard of a tape drive that can set the tape size to various values. Can you explain in detail how you manually set the drive to 35GB and re-initialized it? Just stuff to look out for. Anwar Ahmad wrote: Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. This may be a silly question, but .. You've stated you have a mixture of DLT1 (20/40GB nominal) and DLT2 (40/80GB nominal) tapes. Are your drives DLT1 or DLT2? A DLT1 drive will only get 20/40GB capacity from a DLT2, DLT3 or even DLT4 tape. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ( /\ V_V --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
Hello, On 26.10.2005 09:53, Kern Sibbald wrote: On Tuesday 25 October 2005 22:31, Ryan Novosielski wrote: One other thing to note -- sometimes the tape drive will improperly determine the tape size for whatever reason. I have had experience with a DLT7000 drive that, for whatever reason, initialized a tape to 15GB. After that, I had to manually set the drive to 35GB and re-initialize it. After that, no problem. Interesting. I have never heard of a tape drive that can set the tape size to various values. Can you explain in detail how you manually set the drive to 35GB and re-initialized it? I'm not Ryan, but anyway... Basically, a tape, when initialized, has some sort of carrier data written to it which a drive recognizes. My DLT drive, which is rather normal in that respect, allows setting this by two means: Either load a tape, (must be a BOT), use mt to set the density, and write to the tape. Don't try to read anything before that. Or use the front panel of the changer to select a density (here, for DLT IV tapes in a DLT-4000 drive, 10, 15, 20 GB uncompressed and the corresponding compressed values, optimistically called 20, 30, 40 GB. After that, the tape is newly initialized like when I load a blank tape, which you recognize by the time it takes until the first byte is actually written - less than a minute with a initialized tape, up to three minutes with initialization. Arno Just stuff to look out for. Anwar Ahmad wrote: Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. This may be a silly question, but .. You've stated you have a mixture of DLT1 (20/40GB nominal) and DLT2 (40/80GB nominal) tapes. Are your drives DLT1 or DLT2? A DLT1 drive will only get 20/40GB capacity from a DLT2, DLT3 or even DLT4 tape. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
On Wednesday 26 October 2005 10:36, Arno Lehmann wrote: Hello, On 26.10.2005 09:53, Kern Sibbald wrote: On Tuesday 25 October 2005 22:31, Ryan Novosielski wrote: One other thing to note -- sometimes the tape drive will improperly determine the tape size for whatever reason. I have had experience with a DLT7000 drive that, for whatever reason, initialized a tape to 15GB. After that, I had to manually set the drive to 35GB and re-initialize it. After that, no problem. Interesting. I have never heard of a tape drive that can set the tape size to various values. Can you explain in detail how you manually set the drive to 35GB and re-initialized it? I'm not Ryan, but anyway... Basically, a tape, when initialized, has some sort of carrier data written to it which a drive recognizes. My DLT drive, which is rather normal in that respect, allows setting this by two means: Either load a tape, (must be a BOT), use mt to set the density, and write to the tape. Don't try to read anything before that. Or use the front panel of the changer to select a density (here, for DLT IV tapes in a DLT-4000 drive, 10, 15, 20 GB uncompressed and the corresponding compressed values, optimistically called 20, 30, 40 GB. Yes, I *have* heard of setting the density, but didn't think of that. Normally, on most systems, the density is set by default to the highest value for that drive ... This might be worth mentioning in the manual. After that, the tape is newly initialized like when I load a blank tape, which you recognize by the time it takes until the first byte is actually written - less than a minute with a initialized tape, up to three minutes with initialization. Arno Just stuff to look out for. Anwar Ahmad wrote: Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. This may be a silly question, but .. You've stated you have a mixture of DLT1 (20/40GB nominal) and DLT2 (40/80GB nominal) tapes. Are your drives DLT1 or DLT2? A DLT1 drive will only get 20/40GB capacity from a DLT2, DLT3 or even DLT4 tape. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
I've got a SDLT/320 changer I use for some fulls, and a SDLT/220 changer I use for weeklies and other fulls. As I expire tapes from our previous backup system, I'll usually want to make sure I've gone through the tapes I've put in the 320 and write EOF to each tape, so that the drive 'reformats' it to the full 320. (if the 220 had written it before, the drive will leave it 220) Assuming Bacula has released the drive: #!/bin/sh DRV=overland for i in `seq 1 8`; do echo Loading $i mtx -f /changer/$DRV unload mtx -f /changer/$DRV load $i echo Clearing $i mt -f /tapes/$DRV rewind mt -f /tapes/$DRV weof mt -f /tapes/$DRV rewind done and (IIRC) next time it gets loaded, the drive will treat it as it's default compression level. This will also kill the bacula label on it, so. While I'll admit I've never paid that much attention to it, both Solaris and Linux seem to let the tape set it's default, highest density. Since I have the Media Type defined as SDLT for the 320 and SDLT0 for the 220, they'll never mix in Bacula. If I drop the 220 drive in the future, all those tapes will have to be weof'd as they get recycled. Mark On Wed, Oct 26, 2005 at 11:52:19AM +0200, Kern Sibbald wrote: On Wednesday 26 October 2005 10:36, Arno Lehmann wrote: Hello, On 26.10.2005 09:53, Kern Sibbald wrote: On Tuesday 25 October 2005 22:31, Ryan Novosielski wrote: One other thing to note -- sometimes the tape drive will improperly determine the tape size for whatever reason. I have had experience with a DLT7000 drive that, for whatever reason, initialized a tape to 15GB. After that, I had to manually set the drive to 35GB and re-initialize it. After that, no problem. Interesting. I have never heard of a tape drive that can set the tape size to various values. Can you explain in detail how you manually set the drive to 35GB and re-initialized it? I'm not Ryan, but anyway... Basically, a tape, when initialized, has some sort of carrier data written to it which a drive recognizes. My DLT drive, which is rather normal in that respect, allows setting this by two means: Either load a tape, (must be a BOT), use mt to set the density, and write to the tape. Don't try to read anything before that. Or use the front panel of the changer to select a density (here, for DLT IV tapes in a DLT-4000 drive, 10, 15, 20 GB uncompressed and the corresponding compressed values, optimistically called 20, 30, 40 GB. Yes, I *have* heard of setting the density, but didn't think of that. Normally, on most systems, the density is set by default to the highest value for that drive ... This might be worth mentioning in the manual. After that, the tape is newly initialized like when I load a blank tape, which you recognize by the time it takes until the first byte is actually written - less than a minute with a initialized tape, up to three minutes with initialization. Arno Just stuff to look out for. Anwar Ahmad wrote: Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
OK, thanks. I'll add a note in the manual to check the density ... On Wednesday 26 October 2005 17:34, Mark Bober wrote: I've got a SDLT/320 changer I use for some fulls, and a SDLT/220 changer I use for weeklies and other fulls. As I expire tapes from our previous backup system, I'll usually want to make sure I've gone through the tapes I've put in the 320 and write EOF to each tape, so that the drive 'reformats' it to the full 320. (if the 220 had written it before, the drive will leave it 220) Assuming Bacula has released the drive: #!/bin/sh DRV=overland for i in `seq 1 8`; do echo Loading $i mtx -f /changer/$DRV unload mtx -f /changer/$DRV load $i echo Clearing $i mt -f /tapes/$DRV rewind mt -f /tapes/$DRV weof mt -f /tapes/$DRV rewind done and (IIRC) next time it gets loaded, the drive will treat it as it's default compression level. This will also kill the bacula label on it, so. While I'll admit I've never paid that much attention to it, both Solaris and Linux seem to let the tape set it's default, highest density. Since I have the Media Type defined as SDLT for the 320 and SDLT0 for the 220, they'll never mix in Bacula. If I drop the 220 drive in the future, all those tapes will have to be weof'd as they get recycled. Mark On Wed, Oct 26, 2005 at 11:52:19AM +0200, Kern Sibbald wrote: On Wednesday 26 October 2005 10:36, Arno Lehmann wrote: Hello, On 26.10.2005 09:53, Kern Sibbald wrote: On Tuesday 25 October 2005 22:31, Ryan Novosielski wrote: One other thing to note -- sometimes the tape drive will improperly determine the tape size for whatever reason. I have had experience with a DLT7000 drive that, for whatever reason, initialized a tape to 15GB. After that, I had to manually set the drive to 35GB and re-initialize it. After that, no problem. Interesting. I have never heard of a tape drive that can set the tape size to various values. Can you explain in detail how you manually set the drive to 35GB and re-initialized it? I'm not Ryan, but anyway... Basically, a tape, when initialized, has some sort of carrier data written to it which a drive recognizes. My DLT drive, which is rather normal in that respect, allows setting this by two means: Either load a tape, (must be a BOT), use mt to set the density, and write to the tape. Don't try to read anything before that. Or use the front panel of the changer to select a density (here, for DLT IV tapes in a DLT-4000 drive, 10, 15, 20 GB uncompressed and the corresponding compressed values, optimistically called 20, 30, 40 GB. Yes, I *have* heard of setting the density, but didn't think of that. Normally, on most systems, the density is set by default to the highest value for that drive ... This might be worth mentioning in the manual. After that, the tape is newly initialized like when I load a blank tape, which you recognize by the time it takes until the first byte is actually written - less than a minute with a initialized tape, up to three minutes with initialization. Arno Just stuff to look out for. Anwar Ahmad wrote: Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
On Tue, 18 Oct 2005, Anwar Ahmad wrote: Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? btape's fill command. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] DLT 40/80GB never reaches 40GB
Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. Thanks! Kind Regards, Anwar --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. This may be a silly question, but .. You've stated you have a mixture of DLT1 (20/40GB nominal) and DLT2 (40/80GB nominal) tapes. Are your drives DLT1 or DLT2? A DLT1 drive will only get 20/40GB capacity from a DLT2, DLT3 or even DLT4 tape. -- Phil Stracchino [EMAIL PROTECTED] Renaissance Man, Unix generalist, Perl hacker Mobile: 603-216-7037 Landline: 603-886-3518 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
Hi Phil, No worries, I've checked that both are DLT2 drives. Specifically they are HP SureStore Autoloaders. Both were bough at the same time from HP directly. They were also configured identically. We initially had a bunch of DLT tapes around (10 or so) from our old HP server which had an inbuilt DLT drive. This was DLT1. When we purchased the 2 Autoloaders we wanted to reuse some of the old tapes rather than junk it since we're using bacula as network backup. We also purchased well over 30 DLT 40/80 tapes. Interestingly, I've relabeled a 40/80 tape that was originally in the pool that backed up from pool1 (the one with the problem) and put it into pool2 (working normally) and it works correctly. I thought about the physical tape drive causing the problem but I've nowhere to check? Is there any way to check using software? I'm not certain how this actually works out. Since both autoloader are bought together and are from the same batch, 1 couldn't have been DLT1 while the other DLT2. I ruled out the autoloader as the source of the problem since it's still working. It's unlikely a hardware fault could cause something like that... however I could be wrong. I'd like to explore software configuration issues before accepting the drive is faulty. From my previous experience, the drive either works or don't. I've never encountered an issue where it slows down but still works Thanks! Kind Regards, Anwar Phil Stracchino wrote: Anwar Ahmad wrote: Hi All, I have this problem where I've got a mix of 20/40GB and 40/80GB DLT tapes that are in 1 pool configured to backup using 1 tape drive. The problem is, all of them seem to be acting like 20/40GB tapes including the higher capacity ones. I've not been able to get the 40/80GB tape to store even remotely near 40GB let alone the compressed capacity of 80GB. I was wondering whether anyone had similar problems before... The funny thing is, I've got a another pool that uses another tape drive that all backup correctly. Most backup are close to around 68-72GB, which I believe is fine. I've configured both pools devices similarly but don't know why 1 only backs up to around 34GB (acting like a 20/40). Both tape drives were bough at the same time and are identical models. Is the mix of tapes causing the problem? They are currently listed as /dev/nst0 and /dev/nst1 respectively. Is there any configuration files in outside of bacula-dir that I need to configure or perhaps in Linux system files perhaps, although I don't recall any configuration files other than the bacula conf files where done back during the initial setup. This may be a silly question, but .. You've stated you have a mixture of DLT1 (20/40GB nominal) and DLT2 (40/80GB nominal) tapes. Are your drives DLT1 or DLT2? A DLT1 drive will only get 20/40GB capacity from a DLT2, DLT3 or even DLT4 tape. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] DLT 40/80GB never reaches 40GB
Were the tapes ever used in a DLT1 drive? --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
