Re: Multi-tape question
It didn't complain (and if I'm incorrect in my assumption crowd..please
correct me) planner never takes into account the tape length so that is
why there wasn't any complaints
When taper started writing the dumps to tape and it was determined that
the filesystem exceeded the expected tape size (regardless of hardware
compression) the dumps would fail since the dumps aren't capable of
spanning tapes
You should use the compression device (/dev/rmt/0cn..depending unix
flavor) and adjust your length to be what you expect your compression to be.
Make sense??
If I recollect (had same problem myself) the tapetype doesn't prefer the
compression it gives you the raw length of the tape...so if you had a
tapetype length of 33000 mb (+ or -) then you could set your length to
65000 mb (if using hardware compression.
As a side note make sure that you aren't using software and hardware at
the same time (speaking from experience as an amanda freshmen myself)
Don
Eric Trager wrote:
On Tue, 26 Feb 2002, Don Potter wrote:
What is the length of the tapetypeusing hardware compression you
will need to adjust the length to what you expect your actually
compression ratio to be..if you expect each tape to be about 70gb then
your length would be 7 mbytes.
Ah... so perhaps this is causing the issue?
define tapetype DLTtapeIV {
comment DLTtape IV - 40 GB
length 33706 mbytes
filemark 43 kbytes
speed 1820 kps
}
That was what the tapetype run gave us. So I guess you're saying that
using the cbn device rather than the bn or n device is creating a
conflict?
I'm just wondering why amanda would abandon partitions... it did seem to
properly determine that it had ~70 Gb to work with...
- Eric
Resolved - Multi-tape question
Thank you to those that wrote back yesterday, especially Don. I used the non-compressed device (in this case, /dev/rmt/1n), and amanda did indeed write filesystems until it hit EOT and rewrote that specific interrupted filesystem to the next tape. Does anyone here have a changer working with more than one drive? The 30-slot StorEdge changer I'm working with has two drives installed, and I'm wondering how I can best utilize both of them. - Eric
Re: Resolved - Multi-tape question
Perhaps add another configuration, use the second drive as your tapedev parameter and change the first and last slot number in your changer conf file. So first conf will have slots 1-15 and second conf will control 16-30. Have them backup different filesystem. Althought I dont know if it would work better since we can't have two copies of Amanda running the same changer at the same time, so backup speed wise, it's probably the same. I am not sure if multiple copies of amanda can run the same time, someone please correct me if I'm wrong. - Original Message - From: Eric Trager [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 9:53 AM Subject: Resolved - Multi-tape question Thank you to those that wrote back yesterday, especially Don. I used the non-compressed device (in this case, /dev/rmt/1n), and amanda did indeed write filesystems until it hit EOT and rewrote that specific interrupted filesystem to the next tape. Does anyone here have a changer working with more than one drive? The 30-slot StorEdge changer I'm working with has two drives installed, and I'm wondering how I can best utilize both of them. - Eric
RE: Resolved - Multi-tape question
What I did here is not the second drive with the changer at all -- I change that tape by hand twice a week, and use it to generate an archival level-0 backup (stored in the tape safe) for long-term storage. I can use the tapes in the changer (on drive 1) to restore any file system to any day in the previous 20 days (since I have a 20-slot changer) and then can restore to one-week granularity for any week in our tape safe (which goes back two years). I know it's not using both tape drives WITH the changer exactly, but it works well for our needs. -Ed -Original Message- From: Mark Lin [mailto:[EMAIL PROTECTED]] Sent: 27 February, 2002 08:02 To: Eric Trager; [EMAIL PROTECTED] Subject: Re: Resolved - Multi-tape question Perhaps add another configuration, use the second drive as your tapedev parameter and change the first and last slot number in your changer conf file. So first conf will have slots 1-15 and second conf will control 16-30. Have them backup different filesystem. Althought I dont know if it would work better since we can't have two copies of Amanda running the same changer at the same time, so backup speed wise, it's probably the same. I am not sure if multiple copies of amanda can run the same time, someone please correct me if I'm wrong. - Original Message - From: Eric Trager [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 27, 2002 9:53 AM Subject: Resolved - Multi-tape question Thank you to those that wrote back yesterday, especially Don. I used the non-compressed device (in this case, /dev/rmt/1n), and amanda did indeed write filesystems until it hit EOT and rewrote that specific interrupted filesystem to the next tape. Does anyone here have a changer working with more than one drive? The 30-slot StorEdge changer I'm working with has two drives installed, and I'm wondering how I can best utilize both of them. - Eric
Multi-tape question
Hi, all. I managed to get my changer working with Amanda using chg-scsi. Today I started the first test dump to see what would happen. Using hardware compression, my DLT-IV tapes hold about 70 GB. I set up a dump of several large and small partitions totalling ~88 GB. One was not mounted for the dump so the total was actually 73 GB. I set runtapes to 2 in the amanda.conf file thinking this would tell amanda to use two tapes, but I see this in the amdump log: [snip] INITIAL SCHEDULE (size 73008621): gorge /export/home pri 11747 lev 0 size 16340165 gorge /usr/ pri 11747 lev 0 size 15425329 gorge /usr/oracle2 pri 11747 lev 0 size 12874971 gorge /usr/oracle pri 11747 lev 0 size 7166160 gorge /usr/oracle5 pri 11747 lev 0 size 4502198 gorge /usr/oracle3 pri 11747 lev 0 size 4348242 gorge /usr/oracle4 pri 11747 lev 0 size 4143069 gorge / pri 11747 lev 0 size 3541838 gorge /public pri 11747 lev 0 size 982111 gorge /var pri 11747 lev 0 size 818101 gorge /export/gorge pri 11746 lev 0 size 2865347 gorge /export/mada/yoga pri 11746 lev 0 size 40 DELAYING DUMPS IF NEEDED, total_size 73008621, tape length 69029888 mark 43 planner: FAILED gorge /export/gorge 20020226 0 [dumps too big, but cannot incremental dump new disk] planner: FAILED gorge /var 20020226 0 [dumps too big, but cannot incremental dump new disk] planner: FAILED gorge /public 20020226 0 [dumps too big, but cannot incremental dump new disk] delay: Total size now 68342837. [snip] So it dropped some small partitions until it got to a total it likes. I thought, however, that runtapes tells Amanda to use the changer to fill additional tapes as needed. Am I assuming the wrong thing? Does runtapes mean something else? I have included some snips from my configs. Please shed some light on this if you can. TIA, Eric amanda.conf runtapes 2 # number of tapes to use in a single run of amdump tpchanger /usr//opt/amanda-2.4.3b2/etc/amanda/Othertest/chg-scsi tapedev 0 changerfile /usr//opt/amanda-2.4.3b2/etc/amanda/Othertest/chg-scsi-solaris.conf labelstr ^CMAG-[0-9][0-9]*$ dumpcycle 1 #the number of days in the normal dump cycle bumpdays 1 #minimum days at each level bumpsize 20 Mb #minimum savings (threshold) to bump level 1 - 2 bumpmult 2 #threshold = bumpsize * bumpmult^(level-1) runspercycle 1 # the number of amdump runs in dumpcycle days tapecycle 4 # the number of tapes in rotation chg-scsi-solaris.conf number_configs 1 eject 1 # Tapedrives need an eject command sleep 45 # Seconds to wait until the tape gets ready cleanmax1000# How many times could a cleaning tape get used changerdev /dev/changer # config 0 drivenum0 dev /dev/rmt/1cbn startuse0 # The slots associated with the drive 0 enduse 14 # --
Re: Multi-tape question
What is the length of the tapetypeusing hardware compression you will need to adjust the length to what you expect your actually compression ratio to be..if you expect each tape to be about 70gb then your length would be 7 mbytes. But I would suggest you not go to the limit of your expected compression. Don Eric Trager wrote: Hi, all. I managed to get my changer working with Amanda using chg-scsi. Today I started the first test dump to see what would happen. Using hardware compression, my DLT-IV tapes hold about 70 GB. I set up a dump of several large and small partitions totalling ~88 GB. One was not mounted for the dump so the total was actually 73 GB. I set runtapes to 2 in the amanda.conf file thinking this would tell amanda to use two tapes, but I see this in the amdump log: [snip] INITIAL SCHEDULE (size 73008621): gorge /export/home pri 11747 lev 0 size 16340165 gorge /usr/ pri 11747 lev 0 size 15425329 gorge /usr/oracle2 pri 11747 lev 0 size 12874971 gorge /usr/oracle pri 11747 lev 0 size 7166160 gorge /usr/oracle5 pri 11747 lev 0 size 4502198 gorge /usr/oracle3 pri 11747 lev 0 size 4348242 gorge /usr/oracle4 pri 11747 lev 0 size 4143069 gorge / pri 11747 lev 0 size 3541838 gorge /public pri 11747 lev 0 size 982111 gorge /var pri 11747 lev 0 size 818101 gorge /export/gorge pri 11746 lev 0 size 2865347 gorge /export/mada/yoga pri 11746 lev 0 size 40 DELAYING DUMPS IF NEEDED, total_size 73008621, tape length 69029888 mark 43 planner: FAILED gorge /export/gorge 20020226 0 [dumps too big, but cannot incremental dump new disk] planner: FAILED gorge /var 20020226 0 [dumps too big, but cannot incremental dump new disk] planner: FAILED gorge /public 20020226 0 [dumps too big, but cannot incremental dump new disk] delay: Total size now 68342837. [snip] So it dropped some small partitions until it got to a total it likes. I thought, however, that runtapes tells Amanda to use the changer to fill additional tapes as needed. Am I assuming the wrong thing? Does runtapes mean something else? I have included some snips from my configs. Please shed some light on this if you can. TIA, Eric amanda.conf runtapes 2 # number of tapes to use in a single run of amdump tpchanger /usr//opt/amanda-2.4.3b2/etc/amanda/Othertest/chg-scsi tapedev 0 changerfile /usr//opt/amanda-2.4.3b2/etc/amanda/Othertest/chg-scsi-solaris.conf labelstr ^CMAG-[0-9][0-9]*$ dumpcycle 1#the number of days in the normal dump cycle bumpdays 1 #minimum days at each level bumpsize 20 Mb #minimum savings (threshold) to bump level 1 - 2 bumpmult 2 #threshold = bumpsize * bumpmult^(level-1) runspercycle 1 # the number of amdump runs in dumpcycle days tapecycle 4# the number of tapes in rotation chg-scsi-solaris.conf number_configs 1 eject 1 # Tapedrives need an eject command sleep 45 # Seconds to wait until the tape gets ready cleanmax 1000# How many times could a cleaning tape get used changerdev /dev/changer # config 0 drivenum 0 dev/dev/rmt/1cbn startuse 0 # The slots associated with the drive 0 enduse 14 # --
Re: Multi-tape question
On Tue, 26 Feb 2002, Don Potter wrote:
What is the length of the tapetypeusing hardware compression you
will need to adjust the length to what you expect your actually
compression ratio to be..if you expect each tape to be about 70gb then
your length would be 7 mbytes.
Ah... so perhaps this is causing the issue?
define tapetype DLTtapeIV {
comment DLTtape IV - 40 GB
length 33706 mbytes
filemark 43 kbytes
speed 1820 kps
}
That was what the tapetype run gave us. So I guess you're saying that
using the cbn device rather than the bn or n device is creating a
conflict?
I'm just wondering why amanda would abandon partitions... it did seem to
properly determine that it had ~70 Gb to work with...
- Eric
Re: Multi-tape question
On Tue, 26 Feb 2002, Don Potter wrote:
What is the length of the tapetypeusing hardware compression you
will need to adjust the length to what you expect your actually
compression ratio to be..if you expect each tape to be about 70gb then
your length would be 7 mbytes.
Ah... so perhaps this is causing the issue?
define tapetype DLTtapeIV {
comment DLTtape IV - 40 GB
length 33706 mbytes
filemark 43 kbytes
speed 1820 kps
}
That was what the tapetype run gave us. So I guess you're saying that
using the cbn device rather than the bn or n device is creating a
conflict?
I'm just wondering why amanda would abandon partitions... it did seem to
properly determine that it had ~70 Gb to work with...
- Eric
Re: Multi-tape question
It didn't complain (and if I'm incorrect in my assumption crowd..please
correct me) planner never takes into account the tape length so that is
why there wasn't any complaints
When taper started writing the dumps to tape and it was determined that
the filesystem exceeded the expected tape size (regardless of hardware
compression) the dumps would fail since the dumps aren't capable of
spanning tapes
You should use the compression device (/dev/rmt/0cn..depending unix
flavor) and adjust your length to be what you expect your compression to be.
Make sense??
If I recollect (had same problem myself) the tapetype doesn't prefer the
compression it gives you the raw length of the tape...so if you had a
tapetype length of 33000 mb (+ or -) then you could set your length to
65000 mb (if using hardware compression.
As a side note make sure that you aren't using software and hardware at
the same time (speaking from experience as an amanda freshmen myself)
Don
Eric Trager wrote:
On Tue, 26 Feb 2002, Don Potter wrote:
What is the length of the tapetypeusing hardware compression you
will need to adjust the length to what you expect your actually
compression ratio to be..if you expect each tape to be about 70gb then
your length would be 7 mbytes.
Ah... so perhaps this is causing the issue?
define tapetype DLTtapeIV {
comment DLTtape IV - 40 GB
length 33706 mbytes
filemark 43 kbytes
speed 1820 kps
}
That was what the tapetype run gave us. So I guess you're saying that
using the cbn device rather than the bn or n device is creating a
conflict?
I'm just wondering why amanda would abandon partitions... it did seem to
properly determine that it had ~70 Gb to work with...
- Eric
Re: Multi-tape question
On Tue, 26 Feb 2002, Don Potter wrote: When taper started writing the dumps to tape and it was determined that the filesystem exceeded the expected tape size (regardless of hardware compression) the dumps would fail since the dumps aren't capable of spanning tapes Waitaminit... this I didn't know. Amanda can't run dumps across tapes? Why is the runtapes entry even used at all? So if I use HW compression and set the length at 65 Gb, and I want to do a level 0 dump (say it's the first dump, for example) ... host/filesystem # 40 Gb FS host/filesystem2# 20 Gb FS host/filesystem3# 20 Gb FS ... Amanda will continue to sense a problem and drop one of the filesystems from the lineup? I thought that, using runtapes 2, amanda would put two of the filesystems on one tape, load the next tape, and stick the leftover system on it... ? - Eric
Re: Multi-tape question
On Tue, 26 Feb 2002 at 1:57pm, Eric Trager wrote On Tue, 26 Feb 2002, Don Potter wrote: When taper started writing the dumps to tape and it was determined that the filesystem exceeded the expected tape size (regardless of hardware compression) the dumps would fail since the dumps aren't capable of spanning tapes Waitaminit... this I didn't know. Amanda can't run dumps across tapes? Why is the runtapes entry even used at all? So if I use HW compression and set the length at 65 Gb, and I want to do a level 0 dump (say it's the first dump, for example) ... host /filesystem # 40 Gb FS host /filesystem2# 20 Gb FS host /filesystem3# 20 Gb FS ... Amanda will continue to sense a problem and drop one of the filesystems from the lineup? I thought that, using runtapes 2, amanda would put two of the filesystems on one tape, load the next tape, and stick the leftover system on it... ? The latter is correct. What Don's referring to is the fact that amanda cannot span *a single filesystem* across multiple tapes. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Multi-tape question
I should of stated filesystem.bad Donno soup for me It will put as many filesystems on a tape as possibel (prvoding tape length is calc'd correctly) and then write the remainder on the next tape (if you have specified the dumps to use multiple tapes) Sorry for the confusion..I'll keep my mouth shut from now on Eric Trager wrote: On Tue, 26 Feb 2002, Don Potter wrote: When taper started writing the dumps to tape and it was determined that the filesystem exceeded the expected tape size (regardless of hardware compression) the dumps would fail since the dumps aren't capable of spanning tapes Waitaminit... this I didn't know. Amanda can't run dumps across tapes? Why is the runtapes entry even used at all? So if I use HW compression and set the length at 65 Gb, and I want to do a level 0 dump (say it's the first dump, for example) ... host /filesystem # 40 Gb FS host /filesystem2# 20 Gb FS host /filesystem3# 20 Gb FS ... Amanda will continue to sense a problem and drop one of the filesystems from the lineup? I thought that, using runtapes 2, amanda would put two of the filesystems on one tape, load the next tape, and stick the leftover system on it... ? - Eric
Re: Multi-tape question
On Tue, 26 Feb 2002, Don Potter wrote: It will put as many filesystems on a tape as possibel (prvoding tape length is calc'd correctly) and then write the remainder on the next tape (if you have specified the dumps to use multiple tapes) Understood. That's what I had believed going in, and fortunately, it's true. However, as you pointed out, amanda decided not to do that. Sorry for the confusion..I'll keep my mouth shut from now on Not at all! You told me what was wrong! I'm trying another run now with the original length and no compression so I can see if it works in UNDER three hours... :) - Eric
Re: Multi-tape question
Waitaminit... this I didn't know. Amanda can't run dumps across tapes? Why is the runtapes entry even used at all? Amanda 2.4.2p2 can't spread a single dump image over several tapes. For a whole backup run it can use as many tapes as you like.
Re: Multi-tape question
define tapetype DLTtapeIV {
comment DLTtape IV - 40 GB
length 33706 mbytes
filemark 43 kbytes
speed 1820 kps
}
That's the typical result writing random data and using hardware
compression on a 40 GB tape.
If you'd like Amanda to keep 70 GB per tape in mind during the planning
stage - just tell her about each tape having a capacity of 70 GB.
