tapetype for dell powervault 100T DDS4 drive - using 150m Fuji tape
Hi,
I have just run tapetype for the above drive - it looks like this.
./tapetype -f /dev/nst0
wrote 530067 32kb blocks in 1621 files in 7441 seconds (short write)
wrote 530076 32kb blocks in 3252 files in 7408 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype program"
length 16564 mbytes
filemark 0 kbytes
speed 2284 kps
}
I have used a 150m DG4-150 Fujifilm 4mm tape.
I presume I just include this code in the amanda.conf file.
One question I need help on - does it matter that the tapetype is un-known -
or can I just include it like this:-
define tapetype PV100T-DDS4 {
comment "PowerVault 100T DDS4"
length 16564 mbytes
filemark 0 kbytes
speed 2284 kps
}
Thanks in advance
Kevin Passey
Tapetype claims tape is 8.5 GB when it should be 12 GB
Hi all! I have been trying to set up Amanda to back up our Solaris 8 boxes and one of the first steps was to get a tapetype for our tapes. The taper is reported as "HP DDS-3 4MM DAT" (by `mt status`). I don't know any additonal data about this drive since it is in an unmarked case (unless I crack it open and look around). The tapes are "Sony DGD125M", 125 metres with a native capacity of 12 GB. However, after running tapetype I get a tapetype with a capacity of around 8.5 GB (86xx-87xx mbytes), also with different values for filemarks. Also, the first time I ran it using /dev/rmt/0bn I got a type with a large value for filemark (around 1 mmb) and when running it twice with /dev/rmt/0n I got either 0 or 32 kb (the first one when specifying estimated size to 12 GB and the latter without specifying any estimated size). So, anyone know why I am not getting the expected size?
Re: tapetype for dell powervault 100T DDS4 drive - using 150m Fuji ta pe
Hi,
your assumptions below are correct,
but the size of your tapetype is a little of of what it should be...
a DDS-4 drive with 150m tapes is supposed to hold about 20GB of data.
the values tapetype reports makes me beleave your tapedrive is
using hardware-compression.
This is bad/a no-no for tapetype.
Tapetype writes random data to the tape to mesure the raw capacity.
if you try to compress that data, it will become bigger, and
tapetype will hit eot much earlier then without compression.
By the way, amanda likes to have control over compression, so it's
a good idea to switch hardwarecompression completly of for drives
used by amanda.
Christoph
Kevin Passey wrote:
> Hi,
>
> I have just run tapetype for the above drive - it looks like this.
>
> ./tapetype -f /dev/nst0
> wrote 530067 32kb blocks in 1621 files in 7441 seconds (short write)
> wrote 530076 32kb blocks in 3252 files in 7408 seconds (short write)
>
> define tapetype unknown-tapetype {
> comment "just produced by tapetype program"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2284 kps
> }
>
> I have used a 150m DG4-150 Fujifilm 4mm tape.
>
> I presume I just include this code in the amanda.conf file.
>
> One question I need help on - does it matter that the tapetype is un-known -
> or can I just include it like this:-
>
> define tapetype PV100T-DDS4 {
> comment "PowerVault 100T DDS4"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2284 kps
> }
>
> Thanks in advance
>
> Kevin Passey
>
>
Free Adult Movies
Free Movies Pictures Free SEx Free Pictures Free Full Games Free Download No Dialer No Popup
RE: Free Adult Movies
Don't you think it's about time to start using spam control? I get hardly any unsolicited junk on other mailing lists. It's just this one. Michael Martinez System Administrator (Contractor) Information Systems and Technology Management CSREES - United States Department of Agriculture (202) 720-6223 -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 13, 2002 5:52 AMTo: [EMAIL PROTECTED]Subject: Free Adult Movies No Dialer No Popup
RE: tapetype for dell powervault 100T DDS4 drive - using 150m Fuji tape
Hi again,
Christoph was correct - I dug the manual out and the drive is installed by
default with hardware compression on.
You have to set the first dip switch to off - I'm tapetype - ing as I type.
I will post the results here - if anyone is interested.
Kevin
-Original Message-
From: Christoph Scheeder [mailto:[EMAIL PROTECTED]]
Sent: 13 August 2002 10:33
To: Kevin Passey
Cc: Amanda (E-mail)
Subject: Re: tapetype for dell powervault 100T DDS4 drive - using 150m
Fuji ta pe
Hi,
your assumptions below are correct,
but the size of your tapetype is a little of of what it should be...
a DDS-4 drive with 150m tapes is supposed to hold about 20GB of data.
the values tapetype reports makes me beleave your tapedrive is
using hardware-compression.
This is bad/a no-no for tapetype.
Tapetype writes random data to the tape to mesure the raw capacity.
if you try to compress that data, it will become bigger, and
tapetype will hit eot much earlier then without compression.
By the way, amanda likes to have control over compression, so it's
a good idea to switch hardwarecompression completly of for drives
used by amanda.
Christoph
Kevin Passey wrote:
> Hi,
>
> I have just run tapetype for the above drive - it looks like this.
>
> ./tapetype -f /dev/nst0
> wrote 530067 32kb blocks in 1621 files in 7441 seconds (short write)
> wrote 530076 32kb blocks in 3252 files in 7408 seconds (short write)
>
> define tapetype unknown-tapetype {
> comment "just produced by tapetype program"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2284 kps
> }
>
> I have used a 150m DG4-150 Fujifilm 4mm tape.
>
> I presume I just include this code in the amanda.conf file.
>
> One question I need help on - does it matter that the tapetype is un-known
-
> or can I just include it like this:-
>
> define tapetype PV100T-DDS4 {
> comment "PowerVault 100T DDS4"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2284 kps
> }
>
> Thanks in advance
>
> Kevin Passey
>
>
Re: using Netcat as a wrapper on solaris
Anthony A. D. Talltree wrote: >>On Thursday 08 August 2002 14:07, Adam D. Read wrote: >> >>>Inetd, Xinetd are not options for me to use on my solaris boxen. >> >>Sorry, I missed that solaris thing. > > > Huh? xinetd should run just fine on SunOS 5. I would like to avoid using xinetd as I already ave most other services moved to daemontools and ucspi-tcp. This is also for several boxes, so I would rather not install xinetd. If someone could test this out on a Solaris box and see if netcat + amandad works for them, I would appreciate it. Thanks, Adam Read LocalNet Corp.
Re: tapetype for dell powervault 100T DDS4 drive - using 150m Fuji ta pe
On Tuesday 13 August 2002 04:05, Kevin Passey wrote:
>Hi,
>
>I have just run tapetype for the above drive - it looks like this.
>
>./tapetype -f /dev/nst0
>wrote 530067 32kb blocks in 1621 files in 7441 seconds (short
> write) wrote 530076 32kb blocks in 3252 files in 7408 seconds
> (short write)
>
>define tapetype unknown-tapetype {
>comment "just produced by tapetype program"
>length 16564 mbytes
>filemark 0 kbytes
>speed 2284 kps
>}
>
>I have used a 150m DG4-150 Fujifilm 4mm tape.
>n
>I presume I just include this code in the amanda.conf file.
>
>One question I need help on - does it matter that the tapetype is
> un-known - or can I just include it like this:-
>
>define tapetype PV100T-DDS4 {
>comment "PowerVault 100T DDS4"
>length 16564 mbytes
>filemark 0 kbytes
>speed 2284 kps
>}
The above is the correct format. Or you could remove everything but
the "DDS4", which really says all it needs to say. The comment is
fine as it is since anyone is free to put whatever there.
>Thanks in advance
>
>Kevin Passey
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.11% setiathome rank, not too shabby for a WV hillbilly
Good Teeth
Hello all. Sorry for possibly wasting your time and bandwidth, please be patient for the sake of those this will help, and this appology doesn't extend to the people running this mailling list after that shocker today (Free Adult Movies)! How they don't end up in jail is a mystery to me! David and Ilza, with the help of their two kids, have walked along the vast beaches of Cape Town, South Africa, for many years, searching for fossilized shark teeth. They seem to be the only people there with a true gift of finding these rare sightings. They have decided to share these rare treasures with people around the world. Go to their web page below to see "WHAT GREAT TEETH THEY HAVE". Thanks for reading this, its my contribution to a close friend, and a excellent collection! A friend. See there webpage www.sharkteethsales.co.za or e-mail them [EMAIL PROTECTED] _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
RE: Good Teeth
Spam control Michael Martinez System Administrator (Contractor) Information Systems and Technology Management CSREES - United States Department of Agriculture (202) 720-6223 > -Original Message- > From: Candice Fraser [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 9:16 AM > To: [EMAIL PROTECTED] > Subject: Good Teeth > > > Hello all. > > Sorry for possibly wasting your time and bandwidth, please be > patient for > the sake of those this will help, and this appology doesn't > extend to the > people running this mailling list after that shocker today > (Free Adult > Movies)! How they don't end up in jail is a mystery to me! > > David and Ilza, with the help of their two kids, have walked > along the vast > beaches of Cape Town, South Africa, for many years, searching > for fossilized > shark teeth. They seem to be the only people there with a > true gift of > finding these rare sightings. They have decided to share these rare > treasures with people around the world. Go to their web page > below to see > "WHAT GREAT TEETH THEY HAVE". > > Thanks for reading this, its my contribution to a close friend, and a > excellent collection! > > A friend. > > See there webpage www.sharkteethsales.co.za > or e-mail them [EMAIL PROTECTED] > > > > > _ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com >
Re: tapetype for dell powervault 100T DDS4 drive - using 150m Fuj i tape
On Tuesday 13 August 2002 08:20, Kevin Passey wrote:
>Hi again,
>
>Christoph was correct - I dug the manual out and the drive is
> installed by default with hardware compression on.
>
>You have to set the first dip switch to off - I'm tapetype - ing
> as I type.
>
>I will post the results here - if anyone is interested.
>
>Kevin
>
>-Original Message-
From: Christoph Scheeder [mailto:[EMAIL PROTECTED]]
>Sent: 13 August 2002 10:33
>To: Kevin Passey
>Cc: Amanda (E-mail)
>Subject: Re: tapetype for dell powervault 100T DDS4 drive - using
> 150m Fuji ta pe
>
>
>Hi,
>your assumptions below are correct,
>but the size of your tapetype is a little of of what it should
> be... a DDS-4 drive with 150m tapes is supposed to hold about
> 20GB of data. the values tapetype reports makes me beleave your
> tapedrive is using hardware-compression.
>This is bad/a no-no for tapetype.
>Tapetype writes random data to the tape to mesure the raw
> capacity. if you try to compress that data, it will become
> bigger, and tapetype will hit eot much earlier then without
> compression. By the way, amanda likes to have control over
> compression, so it's a good idea to switch hardwarecompression
> completly of for drives used by amanda.
>Christoph
>
>Kevin Passey wrote:
>> Hi,
>>
>> I have just run tapetype for the above drive - it looks like
>> this.
>>
>> ./tapetype -f /dev/nst0
>> wrote 530067 32kb blocks in 1621 files in 7441 seconds (short
>> write) wrote 530076 32kb blocks in 3252 files in 7408 seconds
>> (short write)
>>
>> define tapetype unknown-tapetype {
>> comment "just produced by tapetype program"
>> length 16564 mbytes
>> filemark 0 kbytes
>> speed 2284 kps
>> }
>>
>> I have used a 150m DG4-150 Fujifilm 4mm tape.
>>
>> I presume I just include this code in the amanda.conf file.
>>
>> One question I need help on - does it matter that the tapetype
>> is un-known
>
>-
>
>> or can I just include it like this:-
>>
>> define tapetype PV100T-DDS4 {
>> comment "PowerVault 100T DDS4"
>> length 16564 mbytes
>> filemark 0 kbytes
>> speed 2284 kps
>> }
>>
>> Thanks in advance
>>
>> Kevin Passey
I'd wondered about that myself as I would have expected maybe 19.xx
gigs if it was off, but only 12 or 13 if it was on.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.11% setiathome rank, not too shabby for a WV hillbilly
Re: Tapetype claims tape is 8.5 GB when it should be 12 GB
On Tuesday 13 August 2002 04:32, Conny Gyllendahl wrote: >Hi all! > >I have been trying to set up Amanda to back up our Solaris 8 boxes > and one of the first steps was to get a tapetype for our tapes. > >The taper is reported as "HP DDS-3 4MM DAT" (by `mt status`). I > don't know any additonal data about this drive since it is in an > unmarked case (unless I crack it open and look around). > >The tapes are "Sony DGD125M", 125 metres with a native capacity of > 12 GB. > >However, after running tapetype I get a tapetype with a capacity > of around 8.5 GB (86xx-87xx mbytes), also with different values > for filemarks. Also, the first time I ran it using /dev/rmt/0bn I > got a type with a large value for filemark (around 1 mmb) and > when running it twice with /dev/rmt/0n I got either 0 or 32 kb > (the first one when specifying estimated size to 12 GB and the > latter without specifying any estimated size). > >So, anyone know why I am not getting the expected size? The drives compression is turned on? Using hardware compression in the drive confuses the heck out of amanda in the first place as she then has no idea how much the tape can actually hold. Amanda counts bytes *after* whatever compression is specified in the dumptype. Second, tapetype uses /dev/urandom as the data source. urandom data, because it is so random, isn't compressible by any dumb 2-7 RLL hardware compressor, and will in fact grow larger by quite a bit as it attempts to compress it, hence the low detected capacity. So turn off the drives compression, amanda can do a far better job of compressing things anyway. Note that this can be difficult to do because the compression flag is in a 'you can't see it' tape header and even though the drives switches have been turned off, the tape recognition phase the drive goes thru when new tape is inserted will turn it back on if that tape has been written to with the compression turned on. The only reliable method I've found to fix that is to dd the tape label to a scratch file, rewind the tape, turn off all compression with mt, then feed it (useing dd) sufficient data from /dev/zero (10 megs or so, eg more than the drives buffer) in order to force it to re-write this hidden header that saves the current settings as it flushes the 'about to overflow' buffer to tape. Once thats done, the tape is then rewound again and dd is used to restore the tapes label block from that scratch file, using the rewinding device this time which will force the buffer flush, thereby actually writing the label. Any data that *was* on the tape is of course lost by doing this, but short of reading the whole tape out to a holding area big enough to hold it, doing the above, then re-writeing the holding area back to the tape, I don't know of a way to prevent this data loss. In the normal course of daily backups, that data will be saved again shortly anyway. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
DLT tapes
I thought if you pressed the "eject" button, then waited for the tape to rewind, then it beeps and the light for "remove" comes on, that you had to physically take out the tape and put it back in. Not so. Last night amanda actually ran, and dumped the holding disks to tape, AFTER I'd hit the eject button. oops. Just an FYI! wab
RE: Free Adult Movies
And the issue is - if you inadvertently open it and your boss see's it you're dead meat. I set my e-mail client to open the next mail when scanning thru these. SPAM FILTERS PLEASE. keywords adult,teeth,sex Cheers Kevin -Original Message-From: Martinez, Michael - CSREES/ISTM [mailto:[EMAIL PROTECTED]]Sent: 13 August 2002 12:48To: [EMAIL PROTECTED]Subject: RE: Free Adult Movies Don't you think it's about time to start using spam control? I get hardly any unsolicited junk on other mailing lists. It's just this one. Michael Martinez System Administrator (Contractor) Information Systems and Technology Management CSREES - United States Department of Agriculture (202) 720-6223 -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 13, 2002 5:52 AMTo: [EMAIL PROTECTED]Subject: Free Adult Movies No Dialer No Popup
RE: Tapetype claims tape is 8.5 GB when it should be 12 GB
Problem I had was I had to change some dip switches - which means power off, covers off, tape drive out, screwdriver out. You get the picture. Check the tech manual of your drive - you may have to do the same as me. Good luck. Kevin -Original Message- From: Gene Heskett [mailto:[EMAIL PROTECTED]] Sent: 13 August 2002 14:35 To: Conny Gyllendahl; [EMAIL PROTECTED] Subject: Re: Tapetype claims tape is 8.5 GB when it should be 12 GB On Tuesday 13 August 2002 04:32, Conny Gyllendahl wrote: >Hi all! > >I have been trying to set up Amanda to back up our Solaris 8 boxes > and one of the first steps was to get a tapetype for our tapes. > >The taper is reported as "HP DDS-3 4MM DAT" (by `mt status`). I > don't know any additonal data about this drive since it is in an > unmarked case (unless I crack it open and look around). > >The tapes are "Sony DGD125M", 125 metres with a native capacity of > 12 GB. > >However, after running tapetype I get a tapetype with a capacity > of around 8.5 GB (86xx-87xx mbytes), also with different values > for filemarks. Also, the first time I ran it using /dev/rmt/0bn I > got a type with a large value for filemark (around 1 mmb) and > when running it twice with /dev/rmt/0n I got either 0 or 32 kb > (the first one when specifying estimated size to 12 GB and the > latter without specifying any estimated size). > >So, anyone know why I am not getting the expected size? The drives compression is turned on? Using hardware compression in the drive confuses the heck out of amanda in the first place as she then has no idea how much the tape can actually hold. Amanda counts bytes *after* whatever compression is specified in the dumptype. Second, tapetype uses /dev/urandom as the data source. urandom data, because it is so random, isn't compressible by any dumb 2-7 RLL hardware compressor, and will in fact grow larger by quite a bit as it attempts to compress it, hence the low detected capacity. So turn off the drives compression, amanda can do a far better job of compressing things anyway. Note that this can be difficult to do because the compression flag is in a 'you can't see it' tape header and even though the drives switches have been turned off, the tape recognition phase the drive goes thru when new tape is inserted will turn it back on if that tape has been written to with the compression turned on. The only reliable method I've found to fix that is to dd the tape label to a scratch file, rewind the tape, turn off all compression with mt, then feed it (useing dd) sufficient data from /dev/zero (10 megs or so, eg more than the drives buffer) in order to force it to re-write this hidden header that saves the current settings as it flushes the 'about to overflow' buffer to tape. Once thats done, the tape is then rewound again and dd is used to restore the tapes label block from that scratch file, using the rewinding device this time which will force the buffer flush, thereby actually writing the label. Any data that *was* on the tape is of course lost by doing this, but short of reading the whole tape out to a holding area big enough to hold it, doing the above, then re-writeing the holding area back to the tape, I don't know of a way to prevent this data loss. In the normal course of daily backups, that data will be saved again shortly anyway. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
Free Porno Movies
Free Movies Free Pictures Free Full Games Free Download No Dialer No Popup
set up tape server host
Hi Good Morning, My name is Charles Xiong from Dallas, TX. I have questions for configuration. 1, In the Amanda installation notes - 2.1.B, after I copy the example/ files to /usr/local/etc/amanda/confname/ , what I should do ( which files I need to change and how to change them )? 2, I currently do not have Tape drive. Can I dump files from one diretory to other place on the disk. I am looking forward to your quick reply. Thank you in advance. Your help on the matter is very appreciated. Best Regards, Charles Xiong
dumps too bigggg.....
Hi group, I finally got SCO unix to perform a dump via amanda client. Thank you everyone for your help. Now that the first dump somewhat worked I have more questions. Two of the file systems had errors dumping. I am attempting to backup 2x 45GB and 2x 9 GB file systems. I'm using a DLT tape changer. The errors came backs as: *hostname* /u lev 0 FAILED [dumps too big, but cannot incremental dump new disk] *hostname* /u5 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] These are one one of each size file system (/u=9GB, /u5=45GB) so amanda did dump both a 9GB and a 45GB file system to the tape. I was hoping that amanda would load the another tape to finnish the dump but only one tape was used. The report emailed to me said that only 60% of the tape was used. Why didn't the one of the other two tapes get used? If you need my "tape type" configuration or any other info I'll send it. thanks, chris
Re: tapetype for dell powervault 100T DDS4 drive - using 150m Fuji ta pe
On Tue, Aug 13, 2002 at 09:05:02AM +0100, Kevin Passey wrote:
> Hi,
>
> I have just run tapetype for the above drive - it looks like this.
>
> ./tapetype -f /dev/nst0
> wrote 530067 32kb blocks in 1621 files in 7441 seconds (short write)
> wrote 530076 32kb blocks in 3252 files in 7408 seconds (short write)
>
> define tapetype unknown-tapetype {
> comment "just produced by tapetype program"
> length 16564 mbytes
> filemark 0 kbytes
> speed 2284 kps
> }
>
> I have used a 150m DG4-150 Fujifilm 4mm tape.
>
> I presume I just include this code in the amanda.conf file.
>
> One question I need help on - does it matter that the tapetype is un-known -
> or can I just include it like this:-
There can be multiple "tapetype definitions" in amanda.conf. There is also
one that is used, specified with the "tapetype ..." directive.
If you want to specify "tapetype unknown-tapetype" then you can include
the above definition as is. :))
My recollection of dds4 format is approximately 20GB uncompressed capacity.
More like 19.6 when actually measured by tapetype. However if you run
tapetype with hardware compression turned on, then the "apparent" capacity
of the tape decreases to about 70-90 percent of uncompressed capacity.
Your 16.5GB measurement suggests to me that HW compression was on during
the tapetype run.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Free Porno Movies
Free Movies Free Pictures Free Full Games Free Download No Dialer No Popup
Re: Free Adult Movies
On Tue, Aug 13, 2002 at 02:53:35PM +0100, Kevin Passey wrote: > And the issue is - if you inadvertently open it and your boss see's it > you're dead meat. > Unless you happen to be at the receiving end of '[EMAIL PROTECTED]' ;) "Nope, I was just following up on this complaint from user47... seems as though someone's spamming our network sir... just trying to track down who. " "Oh, ok then, good job". Other than that, I just delete all HTML mail outright - saves a lot of headaches. j
spamming
I've alerted [EMAIL PROTECTED] -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Tapetype claims tape is 8.5 GB when it should be 12 GB
On Tue, Aug 13, 2002 at 11:32:20AM +0300, Conny Gyllendahl wrote: > Hi all! > > I have been trying to set up Amanda to back up our Solaris 8 boxes and one > of the first steps was to get a tapetype for our tapes. > > The taper is reported as "HP DDS-3 4MM DAT" (by `mt status`). I don't know > any additonal data about this drive since it is in an unmarked case > (unless I crack it open and look around). > > The tapes are "Sony DGD125M", 125 metres with a native capacity of 12 GB. > > However, after running tapetype I get a tapetype with a capacity of around > 8.5 GB (86xx-87xx mbytes), also with different values for filemarks. Also, > the first time I ran it using /dev/rmt/0bn I got a type with a large value > for filemark (around 1 mmb) and when running it twice with /dev/rmt/0n I > got either 0 or 32 kb (the first one when specifying estimated size to 12 > GB and the latter without specifying any estimated size). In addition to the excellent advice from Gene and Kenny, just a note about Solaris and devices. Which device, of the many in /dev/rmt, turns on and off compression depends on the name and is controlled by a file "st.conf" in the directory /kernel/drv/. BTW some parts of amanda seem happier when used without the "b" in the device name. Generally they are on the recovery side, not the create tapes side. Here is a brief rundown on the entries in MY st.conf for your drive (similar to mine, though mine is a loader). Use your mt status report to find the entry for your drive. I don't have an exact match for your mt status report, so I'll use a close one. You can wade through the "prtconf -v" output to determine exactly which entry the device drive is using. "HP C1537A", "HP DDS3 DAT", "HPdds3", ^^^^^ mt output should match label Next scan further in the same st.conf file for the label. HPdds3 = 1, 0x34, 0, 0x0D639,4, 0x00, 0x13, 0x24, 0x03, 3; ^^ N 0 1 2 3D not germain to this keys to discription below N) number of densities the drive (or driver) will respond to. 0-3) codes to supply to the driver to invoke a specific density I have no idea what the codes mean to the driver or drive, but they correspond to device names. 0 is "l" (ell), 1 is "m", 2 is "h" and 3 is "c and u". If you swap numbers around, like put the 0x03 in position 1 and 0x13 in position 3, then device 0c will act like 0m does now and visa versa. D) which of the 4 entries is the "default", corresponding to drive 0 with no additional letters except "b" or "n". I.e. no l,m,h,c,u. For this entry, drive 0 is the same as 0c (or 0u)** On my system, l is no HW compression, c/u is forced HW compression. The drive "m" leaves the drive in whatever state it was. I haven't figured out "h". ** I have no clue as to why they have two names, c and u, that always correspond to the same density. I strongly suspect, as you are using device "0n", that you have specified the compression on device by default. Only by checking YOUR st.conf can you be sure. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Free Adult Movies
> Don't you think it's about time to start using spam control? I get > hardly any unsolicited junk on other mailing lists. It's just this > one. There are some spam constraints in place. One of the biggest ones that's not in there is restriction of posting to the list to members-only. Generally, amanda-users sees about 50% of it's traffic from non-members. I see a similar amount of spam on other lists I'm on that are as old as amanda-users. Most (all?) of the "standard" mail controls are in place on the servers amanda-users is housed on although I do stop at using the various open-relay maps since I've had problems with them in the past. This is probably the difference you're seeing compared to other lists. -Todd
Re: dumps too bigggg.....
On Tue, Aug 13, 2002 at 09:19:05AM -0500, Chris Johnson wrote: > Hi group, >I finally got SCO unix to perform a dump via amanda client. Thank > you everyone for your help. >Now that the first dump somewhat worked I have more questions. >Two of the file systems had errors dumping. I am attempting to > backup 2x 45GB and 2x 9 GB file systems. I'm using a DLT tape changer. > The errors came backs as: > > *hostname* /u lev 0 FAILED [dumps too big, but cannot incremental dump new > disk] *hostname* /u5 lev 0 FAILED [dumps too big, but cannot incremental > dump new disk] > > These are one one of each size file system (/u=9GB, /u5=45GB) so amanda > did dump both a 9GB and a 45GB file system to the tape. I was hoping > that amanda would load the another tape to finnish the dump but only one > tape was used. The report emailed to me said that only 60% of the tape > was used. Why didn't the one of the other two tapes get used? If you > need my "tape type" configuration or any other info I'll send it. BTW I'm guessing that your 9 and 45 refer to allocated size, not amount of data on the disk. Who cares about how big the disk is, it is the amount of data on the disk that matters. Does amanda know you have a changer? What changer configuration have you set up. Is it working with the amtape command to load specific slots, next slot, eject, taper, ... Does amanda know it is allowed to use more than one tape? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: dumps too bigggg.....
Jon,
The disks are all raid arrays and are between 75-90% full.
I have the changer configured in the 'amanda.conf' .
The tape changer is working as far as I know ('amlabel [config]
slot [slot num] ' works and amcheck cycles through the different tapes.)
I'm not sure If amanda knows to use more than one tape.
If I increase 'runtapes' in the amanda.conf will it always use
that many even if the dump dosen't require it?
thanks,
chrisj
Jon LaBadie wrote:
>On Tue, Aug 13, 2002 at 09:19:05AM -0500, Chris Johnson wrote:
>
>>Hi group,
>> I finally got SCO unix to perform a dump via amanda client. Thank
>>you everyone for your help.
>> Now that the first dump somewhat worked I have more questions.
>> Two of the file systems had errors dumping. I am attempting to
>>backup 2x 45GB and 2x 9 GB file systems. I'm using a DLT tape changer.
>>The errors came backs as:
>>
>>*hostname* /u lev 0 FAILED [dumps too big, but cannot incremental dump new
>>disk] *hostname* /u5 lev 0 FAILED [dumps too big, but cannot incremental
>>dump new disk]
>>
>>These are one one of each size file system (/u=9GB, /u5=45GB) so amanda
>>did dump both a 9GB and a 45GB file system to the tape. I was hoping
>>that amanda would load the another tape to finnish the dump but only one
>>tape was used. The report emailed to me said that only 60% of the tape
>>was used. Why didn't the one of the other two tapes get used? If you
>>need my "tape type" configuration or any other info I'll send it.
>>
>
>BTW I'm guessing that your 9 and 45 refer to allocated size, not amount
>of data on the disk. Who cares about how big the disk is, it is the
>amount of data on the disk that matters.
>
>Does amanda know you have a changer?
>
>What changer configuration have you set up.
>
>Is it working with the amtape command to load
>specific slots, next slot, eject, taper, ...
>
>Does amanda know it is allowed to use more than one tape?
>
Re: META mailing list policy....
[ On Tuesday, August 13, 2002 at 11:34:23 (-0400), Todd Kover wrote: ] > Subject: Re: Free Adult Movies > > There are some spam constraints in place. One of the biggest > ones that's not in there is restriction of posting to the list to > members-only. Generally, amanda-users sees about 50% of it's traffic > from non-members. Perhaps there should be an "amanda-bugs" and/or "amanda-info" list(s) which are open to non-members and "amanda-users" should be for members only. That way new users could post bug reports and request basic info, etc., and the regular crowd could avoid most (or at least more) spam. Real people need not even subscribe to the open lists -- the bug reports could be filtered and forwarded to a mail gateway for the bug tracking system on sourceforge, and the info list could basically be a semi-smart autoresponder. > I see a similar amount of spam on other lists I'm on that are as old as > amanda-users. I'd say amanda-users is better than many other "open" lists, but then again I've unsubscribed to many other "open" lists because of spam problems :-) How many subscribers are there now? -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>
Re: META mailing list policy....
> [ On Tuesday, August 13, 2002 at 11:34:23 (-0400), Todd Kover wrote: ] > > Subject: Re: Free Adult Movies > > > > There are some spam constraints in place. One of the biggest > > ones that's not in there is restriction of posting to the list to > > members-only. Generally, amanda-users sees about 50% of it's traffic > > from non-members. > > Perhaps there should be an "amanda-bugs" and/or "amanda-info" list(s) > which are open to non-members and "amanda-users" should be for members > only. That way new users could post bug reports and request basic info, > etc., and the regular crowd could avoid most (or at least more) spam. > Real people need not even subscribe to the open lists -- the bug reports > could be filtered and forwarded to a mail gateway for the bug tracking > system on sourceforge, and the info list could basically be a semi-smart > autoresponder. amanda-users is documented all over the place as the place to go for help for amanda so it would make more sense to fan traffic to other lists, however this sounds somewhat onerous for people to interact on the mailing list. I'd like to set things up so non-members get pased through a different set of rules (possibly the message gets run through spamassassin somehow) and/or the relay maps and the like, and if it's suspicious enough, making the sender acknowledge the message somehow (as with subscriptions). Is anyone aware of packages that do this sort of thing before I consider writing one? (please respond to be privately, this is already a bit off topic). > > I see a similar amount of spam on other lists I'm on that are as old as > > amanda-users. > > I'd say amanda-users is better than many other "open" lists, but then > again I've unsubscribed to many other "open" lists because of spam > problems :-) yeah, ever since I've started using spamassassin, I've seen it cut down in all lists. :) > How many subscribers are there now? 1592 amanda-announce 494 amanda-hackers 1086 amanda-users remember that amanda-users is also on amanda-announce. -Todd
Re: dumps too bigggg.....
On Tue, Aug 13, 2002 at 09:19:05AM -0500, Chris Johnson wrote: > Now that the first dump somewhat worked I have more questions. > Two of the file systems had errors dumping. I am attempting to > backup 2x 45GB and 2x 9 GB file systems. I'm using a DLT tape changer. > The errors came backs as: > > *hostname* /u lev 0 FAILED [dumps too big, but cannot incremental dump new disk] > *hostname* /u5 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] The "usual" way to cold start an amanda config with totaldisk > tapesize is to start with disklist mostly commented out, then uncomment a few each day. In your case, assuming your disk usage is "normal" (< 10% new files/day, say) you've got enough tape for your 4 file systems once you get into the rotation, and you could have commented out 1x9 and 1x45 the first night and uncommented them today. Moot point now, though. :-) Amanda will catch up tonight and start balancing the level0 rotation tomorrow night, without you intervening at all. > did dump both a 9GB and a 45GB file system to the tape. I was hoping > that amanda would load the another tape to finnish the dump but only one > tape was used. If you set 'runtapes 2', it'll use two tapes. I did that once in a cold-start situation, instead of the uncommenting trick, and it worked great. Deleted the runtapes entry the next day. > The report emailed to me said that only 60% of the tape > was used. Why didn't the one of the other two tapes get used? Because runtapes defaults to 1. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
patched-up version of tar.
Hi folks. I have a lot of log files that change in size almost constantly, and i understand that when tar returns an error while trying to archive a file whose size has changed, the entire dump of the filesystem fails (i understand this problem exists regardless of what version of tar you are using, but please correct me if i am wrong). Does anyone how to prevent tar from returning this error (whether a particular version of tar + flag, a hack, a patch, or whatever), and can you please send me the URL to this version/doc? I have tried using dump instead of tar, but i suppose this will result in the same problem and it doesn't work anyway for reasons best addressed in a seperate e-mail. I tried "googling" this problem, but to no avail. cheers, john.
missing results when using gnutar
amcheck runs fine and I can use dump perfectly but i'd like to use tar. I'm using amanda 2.4.3b3 on redhat 7.3 machines. Here's the outputs: Hopefully someone has seen this issue and has an idea how to fix it. I'd like to avoid using dump if possible. Also let me know if there's other stuff you need to see to attempt to riddle out why gnutar appears to not be doing what it's supposed to. #--SNIP servers amandad debug file amandad: debug 1 pid 11559 ruid 3105 euid 3105 start time Tue Aug 13 19:25:05 20 02 amandad: version 2.4.3b3 amandad: build: VERSION="Amanda-2.4.3b3" amandad:BUILT_DATE="Mon Aug 12 20:53:18 CDT 2002" amandad:BUILT_MACH="Linux backup.sistina.com 2.4.18-3 #1 Thu Apr 18 07:3 7:53 EDT 2002 i686 unknown" amandad:CC="gcc" amandad:CONFIGURE_COMMAND="'./configure' '--with-gnu-ld' '--with-gnutar= /bin/tar' '--with-rundump' '--with-buffered-dump' '--with-gnutar-listdir=/etc/am anda/gnutar-lists/' '--with-portrange=5,501000' '--with-udpportrange=850,859 ' '--with-user=backup' '--with-group=disk' '--sysconfdir=/etc'" amandad: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" amandad:libexecdir="/usr/local/libexec" mandir="/usr/local/man" amandad:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" amandad:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/" amandad:RDEV_PREFIX="/dev/" DUMP="/sbin/dump" amandad:RESTORE="/sbin/restore" GNUTAR="/bin/tar" amandad:COMPRESS_PATH="/bin/gzip" UNCOMPRESS_PATH="/bin/gzip" amandad:MAILER="/usr/bin/Mail" amandad:listed_incr_dir="/etc/amanda/gnutar-lists/" amandad: defs: DEFAULT_SERVER="backup.sistina.com" amandad:DEFAULT_CONFIG="DailySet1" amandad:DEFAULT_TAPE_SERVER="backup.sistina.com" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS USE_RUNDUMP amandad:CLIENT_LOGIN="backup" FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" got packet: Amanda 2.4 REQ HANDLE 000-28E60708 SEQ 1029284705 SECURITY USER backup SERVICE sendsize OPTIONS maxdumps=1;hostname=backup.sistina.com; GNUTAR /var 0 1970:1:1:0:0:0 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar GNUTAR /var 1 2002:8:13:2:2:2 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar GNUTAR /var 2 2002:8:13:20:26:1 -1 exclude-list=/etc/amanda/DailySet1/exclude.gt ar GNUTAR /usr 0 1970:1:1:0:0:0 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar GNUTAR /usr 1 2002:8:13:2:10:52 -1 exclude-list=/etc/amanda/DailySet1/exclude.gt ar GNUTAR /usr 2 2002:8:13:23:6:8 -1 exclude-list=/etc/amanda/DailySet1/exclude.gta r GNUTAR / 0 1970:1:1:0:0:0 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar GNUTAR / 1 2002:8:13:2:3:4 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar GNUTAR / 2 2002:8:13:20:28:1 -1 exclude-list=/etc/amanda/DailySet1/exclude.gtar sending ack: Amanda 2.4 ACK HANDLE 000-28E60708 SEQ 1029284705 bsd security: remote host backup.sistina.com user backup local user backup amandahosts security check passed amandad: running service "/usr/local/libexec/sendsize" amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-28E60708 SEQ 1029284705 OPTIONS maxdumps=1; amandad: got packet: Amanda 2.4 ACK HANDLE 000-28E60708 SEQ 1029284705 amandad: pid 11559 finish time Tue Aug 13 19:25:05 2002 # SNIP server's sendsize debug file sendsize: debug 1 pid 11560 ruid 3105 euid 3105 start time Tue Aug 13 19:25:05 2 002 /usr/local/libexec/sendsize: version 2.4.3b3 sendsize: calculating for amname '/', dirname '/' sendsize: getting size via gnutar for / level 0 #-SNIP Clients' amandad debug amandad: debug 1 pid 32161 ruid 34 euid 34 start time Tue Aug 13 14:18:30 2002 amandad: version 2.4.3b3 amandad: build: VERSION="Amanda-2.4.3b3" amandad:BUILT_DATE="Mon Aug 12 16:05:49 CDT 2002" amandad:BUILT_MACH="Linux samba2.sistina.com 2.4.18-3 #1 Thu Apr 18 07:3 7:53 EDT 2002 i686 unknown" amandad:CC="gcc" amandad:CONFIGURE_COMMAND="'./configure' '--with-udpportrange=850,859' ' --with-portrange=5,501000' '--with-user=backup' '--with-group=disk' '--sysco nfdir=/etc' '--without-server' '--with-index-server=backup.sistina.com' '--with- gnu-ld' '--with-gnutar=/bin/tar' '--with-rundump' '--with-buffered-dump' '--with -gnutar-listdir=/etc/amanda/gnutar-lists/'" amandad: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" amandad:libexecdir="/usr/local/libexec" mandir="/usr/local/man" amandad:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" amandad:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/" amandad:RDEV_PREFIX="/dev/" DUMP="/sbin/dump" amandad:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient" amandad:GNUTAR="
hardware compression...
OK I know that's a bad thing to say around here BUT... I'm backing up some Solaris 2.6 machines and need to be able to do a restore with nothing but the O/S CD-ROM. Since it doesn't have gzip or any other compression software on the ROM I am just doing straight ufsdumps (level 0 every night) to tape using amanda. My question is, since the drive is handling the compression what tape length should I be specifying in my tapetype definitions? For example should I use 35000 mbytes or 7 mbytes for a DLT-7000 with 35GB of native capacity? Or maybe something in between just to make sure I don't run out f tape? Thanks everyone! -- Scott Sanders Systems Administrator Concepts Direct, Inc. 2950 Colorful Ave. Longmont, CO 80504
Re: hardware compression...
On Tue, 13 Aug 2002 at 1:38pm, Scott Sanders wrote > OK I know that's a bad thing to say around here BUT... No, not really. > ufsdumps (level 0 every night) to tape using amanda. My question is, > since the drive is handling the compression what tape length should I be > specifying in my tapetype definitions? For example should I use 35000 > mbytes or 7 mbytes for a DLT-7000 with 35GB of native capacity? Or > maybe something in between just to make sure I don't run out f tape? Everybody's favorite answer -- it depends. How compressible is your data? Our /home partitions here compress on average about 50% in software. Our raw RF data on the RAID does *not* hardware compress in my AIT1 drive. Start with some compression estimate based on your data, and lower the length if you consistently hit EOT. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
backing up multi-boot system
Just a withful thinking question. I have a multi-boot laptop, Solaris, Linux, and w2k. Individually I can backup systems running any of these OS's, but how can I handle a system that might be currently booted in any one? If nothing else, the disklists are different. Anyone played with this type of situation? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: hardware compression...
Here is a typical amanda report using software compression so do you think 40% is safe? HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - hacksaw / 0 1146303 454464 39.6 8:40 874.3 0:2816222.2 hacksaw /var 0 89887 75936 84.5 1:041178.9 0:107392.5 puffer / 0 530047 270016 50.9 2:211909.1 0:387160.6 puffer /opt0 346710 136224 39.3 7:55 287.0 0:0816364.1 puffer /u200 0 7352220 821696 11.2 79:27 172.4 1:1311224.6 puffer /usr0 855007 306496 35.8 3:171559.3 0:2611951.2 puffer /var0 152383 101152 66.4 1:131392.6 0:0911841.4 Joshua Baker-LePain wrote: > On Tue, 13 Aug 2002 at 1:38pm, Scott Sanders wrote > > > OK I know that's a bad thing to say around here BUT... > > No, not really. > > > ufsdumps (level 0 every night) to tape using amanda. My question is, > > since the drive is handling the compression what tape length should I be > > specifying in my tapetype definitions? For example should I use 35000 > > mbytes or 7 mbytes for a DLT-7000 with 35GB of native capacity? Or > > maybe something in between just to make sure I don't run out f tape? > > Everybody's favorite answer -- it depends. How compressible is your data? > Our /home partitions here compress on average about 50% in software. Our > raw RF data on the RAID does *not* hardware compress in my AIT1 drive. > > Start with some compression estimate based on your data, and lower the > length if you consistently hit EOT. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University -- Scott Sanders Systems Administrator Concepts Direct, Inc. 2950 Colorful Ave. Longmont, CO 80504 (303) 682-7110 Phone (303) 682-7140 Fax
Re: hardware compression...
On Tue, 13 Aug 2002 at 1:55pm, Scott Sanders wrote > Here is a typical amanda report using software compression so do you think 40% > is safe? It's as good a guess as any. You'll know you're being too optimistic if you hit EOT. :) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: missing results when using gnutar
On Tue, Aug 13, 2002 at 02:23:29PM -0500, Ben Lutgens wrote: By the way my tar version is: [backup@backup DailySet1]$ tar --version tar (GNU tar) 1.13.25 Same on all machines. Could it be a tar bug? -- Ben Lutgens | http://people.sistina.com/~blutgens/ System Administrator | http://www.sistina.com/ Sistina Software Inc. | "If you love something set it free, if it doesn't come back to you hunt it down and set it on fire" -- George Carlin msg14150/pgp0.pgp Description: PGP signature
Re: hardware compression...
On Tue, Aug 13, 2002 at 01:38:14PM -0600, Scott Sanders wrote:
> OK I know that's a bad thing to say around here BUT...
Not around me. I'm the lone HW compression advocate (in the right time
and place)...
> I'm backing up some Solaris 2.6 machines and need to be able to do a
> restore with nothing but the O/S CD-ROM. Since it doesn't have gzip or
> any other compression software on the ROM I am just doing straight
> ufsdumps (level 0 every night) to tape using amanda. My question is,
> since the drive is handling the compression what tape length should I be
> specifying in my tapetype definitions? For example should I use 35000
> mbytes or 7 mbytes for a DLT-7000 with 35GB of native capacity? Or
> maybe something in between just to make sure I don't run out f tape?
If you're otherwise happy with SW compression, your protocol could
easily be:
1) HW compression for the OS partitions.
2) SW compression on everything else.
You boot CDROM, restore 1), reboot and restore 2). (AFAIK, you have to
do something like this if you're going to run VxVM or Disksuite,
anyway.)
You definitely do not want to use 70GB for tapetype length, you
will not get that much on OS partitions.
Until recently, I was running a DLT-7000, HW compression, Solaris 2.6,
and I used:
define tapetype DLT-7000HC {
comment "DLTtape IV half-inch cartridge for DLT-7000, hardware compression"
# assume compression ratio 0.58, length = 35000/.58 mbytes
length 60344 mbytes
filemark 8 kbytes
# speed = 5000/.58 kbytes
speed 8620 kbytes
}
This was tweaked to the max (I was stalling for as long as I possibly
could before buying a fancy new changer), and did roll off the end a
couple times in 6 months. If I were you, and I was close to fitting on
35GB, I would use 35/.7 = 50GB.
(FWIW, I've tested the LTO drive I'm using now (HP) on the same data,
and it gets a little better than 2X (.5) compression. Definitely
better compression HW there than on the old DLT-7000.
--
Jay Lessert [EMAIL PROTECTED]
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA(fax)1.503.466.9472
Re: patched-up version of tar.
On Tue, Aug 13, 2002 at 02:53:59PM -0400, John D. Bickle wrote: > Hi folks. > > I have a lot of log files that change in size almost constantly, and i understand >that when tar returns an error while trying to archive a file whose size has changed, >the entire dump of the filesystem fails (i understand this problem exists regardless >of what version of tar you are using, but please correct me if i am wrong). > > Does anyone how to prevent tar from returning this error (whether a particular >version of tar + flag, a hack, a patch, or whatever), and can you please send me the >URL to this version/doc? > > I have tried using dump instead of tar, but i suppose this will result in the same >problem and it doesn't work anyway for reasons best addressed in a seperate e-mail. > > I tried "googling" this problem, but to no avail. > Is this a problem you are having or just something you understand? I believe that when amanda runs gnutar it uses the "--ignore-failed-read" option. This option has the effect of allowing that file to be skipped but continues the dump. At the end, gnutar exits with an non-zero exit status if the option was used AND a file had read errors. On most of my systems this non-zero status is not a problem. On my cygwin client it did cause problems so I modified tar's source code to force a zero exits status. Depending on the system you are using, you may be able to make a readonly "snapshot" of the file system before the dump/tar. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
ADIC Scalar 100 & amanda-2.4.2p2
Greetings all; We recently acquired an ADIC Scalar 100 library with 3 x SuperDLT drives. Its connected to a multi-processor Sun Ultra2 running Solaris 8. I've dowloaded and compiled amanda-2.4.2p2. Using amanda, I can backup the Ultra itself to a single drive in the library. Now I want to try and get the library robotics working in conjuction with the other two drives. Has anyone ever set up amanda for use with this make/model of tape library. If so, could you please give me a hint as to what changer and changer configuration file to use? Thanks in advance -- George A. Kofoed Systems Administration Parsons 905-943-4915
Re: Tapetype claims tape is 8.5 GB when it should be 12 GB
On Tue, 13 Aug 2002, Jon LaBadie wrote: ... > In addition to the excellent advice from Gene and Kenny, just a note about > Solaris and devices. Which device, of the many in /dev/rmt, turns on and > off compression depends on the name and is controlled by a file "st.conf" > in the directory /kernel/drv/. ... > HPdds3 = 1, 0x34, 0, 0x0D639,4, 0x00, 0x13, 0x24, 0x03, 3; > ^^ N 0 1 2 3D >not germain to this keys to discription below ... > D) which of the 4 entries is the "default", corresponding to drive 0 >with no additional letters except "b" or "n". I.e. no l,m,h,c,u. >For this entry, drive 0 is the same as 0c (or 0u)** Thanks for digging this up and presenting it so clearly. -- Ulrik Sandberg
Re: Tapetype claims tape is 8.5 GB when it should be 12 GB
On Tue, Aug 13, 2002 at 11:43:57PM +0200, Ulrik Sandberg wrote: > On Tue, 13 Aug 2002, Jon LaBadie wrote: > > In addition to the excellent advice from Gene and Kenny, just a note about > > Solaris and devices. Which device, of the many in /dev/rmt, turns on and > > off compression depends on the name and is controlled by a file "st.conf" > > in the directory /kernel/drv/. > > ... > > > HPdds3 = 1, 0x34, 0, 0x0D639,4, 0x00, 0x13, 0x24, 0x03, 3; > > ^^ N 0 1 2 3D > >not germain to this keys to discription below > > ... > > Thanks for digging this up and presenting it so clearly. After doing it about 8 times already you'd think I'd can it in file and send it as an attachment :) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Run and dump cycle recommendations?
Good afternoon, This being the first time I've been responsible for doing backups, I'm a bit lost and sure could use some enlightening with regard to run and dump cycles and general rules of thumb. Basically, I'm a backup newbie. We've got an external Compaq eight cassette 20/40Gb DAT autoloader hanging off of one of our linux boxes with seven tapes and one cleaner. There are 10 other machines (linux and Solaris) that will have to have various filesystems backed up, but I need to figure out how often to back up and what's the best way to cycle the tapes and whatnot. Is the general rule of thumb to use one tape for a respective day -- one that gets used repeatedly on Mondays, another for Tuesdays, etc.? And when the tape comes back into use, does the previous data get overwritten or is it appended to the previous dump? Like I said, I'm pretty much a complete newbie with respect to backups, so I apologise if these are "dumb questions" that any schmuck should know. But I'd sure appreciate any suggestions and recommendations. Thanks in advance, -Charlie
Re: Run and dump cycle recommendations?
On Tue, Aug 13, 2002 at 03:18:30PM -0700, Charlie Bebber wrote: > Good afternoon, > > This being the first time I've been responsible for doing backups, I'm a > bit lost and sure could use some enlightening with regard to run and > dump cycles and general rules of thumb. Basically, I'm a backup newbie. > > We've got an external Compaq eight cassette 20/40Gb DAT autoloader > hanging off of one of our linux boxes with seven tapes and one cleaner. > There are 10 other machines (linux and Solaris) that will have to have > various filesystems backed up, but I need to figure out how often to > back up and what's the best way to cycle the tapes and whatnot. > > Is the general rule of thumb to use one tape for a respective day -- one > that gets used repeatedly on Mondays, another for Tuesdays, etc.? And > when the tape comes back into use, does the previous data get > overwritten or is it appended to the previous dump? Like I said, I'm > pretty much a complete newbie with respect to backups, so I apologise if > these are "dumb questions" that any schmuck should know. But I'd sure > appreciate any suggestions and recommendations. Do not consider the following discussion of amanda to be typical of backup software. Amanda does have some unique aspects. Tapes are not assigned to specific days, types of backups, or whatever. Each is labeled uniquely and for human consumption the uniqueness comes from sequentially numbering them. But they could just as well be labeled Huey, Dewey, and Louie. Once in use they will probably be used in the same order each time. Amanda never adds a second dump session to a tape. Each use overwrites what was on the tape previously. You have 11 machines, the tape server and 10 clients. Say on average each has 4 file systems. You would then have 44 items (host/filesystem) to backup. These would each be listed in a file called "disklist". Backups, called dumps regardless of the backup program (dump or tar) are performed at "levels". A full dump (everything on a disklist entry) is a level 0 (zero). Others levels are known as incrementals, level 1 means everything changed since the last level 0. Level 2 dumps are everything changed since the last level 1. Traditional backup strategy says do all level 0's on the same day taking a huge amount of tape and time. Then on other days do incrementals running much faster and using a small amount of tape. Amanda changes this by mixing on each day, level 0's of some disklist entries, incrementals of others. The aim is to use the same amount of tape and time each day. You will have to decide your "dumpcycle", how long amanda is allowed to go between level 0's. I use 1 week, but if my data were more critical I might consider reducing that. As it is, my data is not super-critical and if need be I'd bump it up to make everything fit on one tape. Next you will need to decided how often you will run amanda dumps (amdump program). Many sites run amdump every day. I only do it 6 days a week because my tape changer holds 6 tapes (I clean manually as needed so all slots hold backup tapes). This is specified as runspercycle (dumpcycle) so my 1 week dumpcycle gets 6 runs of amdump. You must also decide how many tapes you are willing to devote to your backup scheme. Don't be stingy. Particularly as you are using relatively inexpensive tapes. I keep 24 tapes in rotation. Since they are used 6 per dumpcycle (1 week) I have 4 weeks worth of dumps available. I picked that number because my drive uses cartridges holding 6 tapes each and I had 5 cartridges. Leaving 1 for general use, 4 were available for amanda. Now over each weekend I just swap cartridges. The number of tapes in service is specified as tapecycle. All this info is collected in a file called amanda.conf. With this as a starting point, get the source code, and in a directory called docs are many information documents. An important one is INSTALLATION. Also see the example amanda.conf file for all its comment remarks. Hope amanda treats you well. jon -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
SUMMARY: SGI IRIX xfsrestore
On an SGI IRIX 6.5.5m system, the following command will perform a cumulative xfsrestore in the current directory, with verbose output. The verbose output is useful, and is not all that verbose (as compared to trace). The tape needs to be positioned correctly at the beginning of the amanda dump file. dd if=/dev/rmt/tps2d5nrnsvc bs=32k skip=1 | /sbin/xfsrestore -r -v verbose - . Thanks to Jon LaBadie, Brian Cuttler, and Jean-Francois Malouin. Also from jf: (but not tried in this restore) rsh -n -l amrestore -p \ [] [] | xfsrestore -ib 2 - . where should all be replaced with proper values. Values in brakets are not mandatory. The xfsrestore flags have to be typed *exactly as shown*. Don't forget to position the tape head correctly! Note that in the original post below, -f (source) and - (standard in) are mutually exclusive. The restore command was taken from the inter-dump record on the tape: AMANDA: FILE 20020721 ajax /export/home6 lev 1 comp N program /sbin/xfsdump To restore, position tape at start of file and run: dd if= bs=32k skip=1 | /sbin/xfsrestore -f... - >The header at the beginning of the amanda dump file says >to restore use >dd if= bs=32k skip=1 | /sbin/xfsrestore -f... - > >However, this is producing errors from xfsrestore. > >If you have used a dd into a piped xfsrestore under >SGI IRIX, could you email me the command? > >amanda 2.4.1p1
Re: missing results when using gnutar
Hi Ben, I've noticed a similar problem on my system. I think I may have traced the problem to a bug in the 'exclude' lists for amanda (2.4.3b3) dumptypes, although I'm still trying to debug the problem a bit more. I noticed in your previous e-mail that you had and exclude list in your call to tar, and so thought this might be relevant. Basically, whenever I put 'exclude' in any format in a dumptype definition, that particular dump fails exactly how you've listed in your message (the sendsize fails). To see if you've hit the same bug (?) try removing the 'exclude' from your dumptype and see what happens... J. -- ++ John Ouellette | Ph: 212-313-7919 Department of Astrophysics | Fax: 212-769-5007 American Museum of Natural History | e-mail: [EMAIL PROTECTED] Central Park West at 79th St. | http://research.amnh.org/astrophysics New York, NY 10024-5192 | ++
first amdump failing
I set up a new amanda backup set. It consits of about 20 servers each with about 3 or 4 filesystms to dump. I've configured amanda correctly (I think), and when i ran the first dump using "amdump Dailyset1" it came back with errors for every filesystem saying it cant do incrementals. I know why this is occuring. Since its the first time Im dumping the filesystems it need a full dump of the filesystems before it can do incrementals. My questions are these: What do I need to do to get the fist amdump to work? - ie. do I have to force a level 0 dump on all filesystems. If this is the case, wouildnt there be too much data to put to tape if a level 0 dump of everything was necessary. And if thats the case, I would have to wait a day or too before all filesystems had a chance to to a level 0 dump. Any info would be appreciated. Thanks.
Simultaneous write to two drives?
Hi, I've got an autoloader with two tape drives in it. Is it possible to have amanda write to two drives simultaneously? In otherwords, run two 'taper' processes which are dumping different filesystems to different tapes for the same Amanda config? My guess is no, but I thought I'd ask Thx, J. -- ++ John Ouellette | Ph: 212-313-7919 Department of Astrophysics | Fax: 212-769-5007 American Museum of Natural History | e-mail: [EMAIL PROTECTED] Central Park West at 79th St. | http://research.amnh.org/astrophysics New York, NY 10024-5192 | ++
Re: Simultaneous write to two drives?
J, I think in this case, its highly unlikely that you would be able to do this with a single autoloader. besides, you'd have to move tapes around too much, that it would increase the time necessary to run the backup. On the otherhand, if you have two different autoloaders, (or two different tape drives), you could set each one with a different configuration and a separate cron process. This would allow you to run taper twice, you would have to tune the configurations really good and probably run them at separate times to have a really reliable and efficient setup. -- Chris ___ ITechusa Networks, New Orleans - Unleash the Technology Within (504) 464-4610 fax: 464-0801 http://www.itech-usa.com On Tuesday 13 August 2002 07:53 pm, John Ouellette wrote: > Hi, > > I've got an autoloader with two tape drives in it. Is it possible to have > amanda write to two drives simultaneously? In otherwords, run two 'taper' > processes which are dumping different filesystems to different tapes for > the same Amanda config? My guess is no, but I thought I'd ask > > Thx, > J.
Re: first amdump failing
On Tue, Aug 13, 2002 at 07:59:19PM -0500, Benjamin Herbert wrote: > I set up a new amanda backup set. It consits of about 20 servers each > with about 3 or 4 filesystms to dump. I've configured amanda correctly (I > think), and when i ran the first dump using "amdump Dailyset1" it came > back with errors for every filesystem saying it cant do incrementals. I > know why this is occuring. Since its the first time Im dumping the > filesystems it need a full dump of the filesystems before it can do > incrementals. My questions are these: > > What do I need to do to get the fist amdump to work? > > - ie. do I have to force a level 0 dump on all filesystems. Walk before leaping. In your disklist, comment out all entries but the tape host, and maybe only 2 or 3 entries for that. Run amdump. Does that work successfully? I.e., can you backup anything. Then add (uncomment) a couple of hosts, a couple of fs's each. Run another amdump. Could even be the same day by hand. Nothing says it has to run out of crontab. Does that run successfully? I.e., can you backup over the network. Add one, maybe 2 fs's from each remaining host. Run another amdump. Does that run successfully? I.e., is each host configured as a client properly? By now, about 1/2 of your fs's are past the initial level 0 and into incrementals. Uncomment the remaining fs's over the next couple of regular dumps. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: first amdump failing
On Tuesday 13 August 2002 20:59, Benjamin Herbert wrote: >I set up a new amanda backup set. It consits of about 20 servers > each with about 3 or 4 filesystms to dump. I've configured > amanda correctly (I think), and when i ran the first dump using > "amdump Dailyset1" it came back with errors for every filesystem > saying it cant do incrementals. I know why this is occuring. > Since its the first time Im dumping the filesystems it need a > full dump of the filesystems before it can do incrementals. My > questions are these: > >What do I need to do to get the fist amdump to work? > > - ie. do I have to force a level 0 dump on all filesystems. > > If this is the case, wouildnt there be too much data to put to >tape if a level 0 dump of everything was necessary. > > And if thats the case, I would have to wait a day or too before >all filesystems had a chance to to a level 0 dump. > >Any info would be appreciated. Thanks. The usual method is to comment out almost everything in the disklist, leaving about what would fit on one tape. Do an amdump, which should be successfull. The next day, uncomment about that much more of the disklist and do an amdump. Continue this over several days until the disklist is fully exposed. Amanda will then attempt to adjust the backup levels each night in order to achieve some level of consistency to the amount of tape used each night. If you have the tape, and still are having capacity failures, one can (if using a changer that is) allow more than 1 tape to be used per nights runs by adjusting the 'runtapes' value in amanda.conf. Bear in mind that when amanda hits an EOT, that filesystem save that just failed is restarted from scratch on the next tape, a gentle warning that one filesystem thats larger than a tape will use up all the tapes it can use per run and still fail. This is an implied limit to the size of the entry in the disklist. In other words, you must break large entries into individual subdir entries that will each fit on one tape. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
