toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

Start a nNew thread

subscribe
by Lisa Malgeri 23 Apr '98

23 Apr '98

1 0

chs/mtx
by Kelly Setzer 23 Apr '98

23 Apr '98

This is not directly on-topic, but considering the discussion lately... I am trying to find a utility like chs or mtx that will work under solaris 2 with an ATL P1000. I've had partial success with chs - it will move the robotics and move tapes from slot to slot, but will move a tape from a slot to a drive. 'mtx' is a product of Automated Network Technologies (anthill.com), which has apparently been acquired by Qualix Group. I've not been successful in finding 'mtx', and Qualix does not seem to know anything...grrr. Any info or other options? thanks, Kelly -- Kelly Setzer <setzer(a)telalink.net> The Telalink Corporation (615) 321-9100 x237 Fax: (615) 321-9110

1 0

Re: Budtool to backup netapp
by Jason D. Kelleher 23 Apr '98

23 Apr '98

In message <17AD4E991EBDD111B6E000A0C99DD8350BA1(a)ntmail05.pc.sas.com>, Alan Phoenix writes: >Has anyone tried using Budtool to backup a netapp? Yup. We've been using BudTool to backup our F330 for about 5 months. We spent a month or two working the kinks out of it before we let it touch our filer. Here's what we found: 1) BudTool's reporting is horrible. End of story. Anyone who tells you otherwise is either deranged or hasn't actually used the product. Fortunately, if you know Perl, writing a script to parse the logfile and send out a readable report (and page on fatal errors) is fairly trivial. 2) BudTool's built in scheduling could only have been written by a fool who liked GUIs and never actually had to support a backup solution in a production environment. cron and a small shell script handled this problem. (AMANDA has the best backup scheduling in my opinion. Someday there'll be a vendor who picks up on it.) 3) User level restores aren't supported for NDMP and only work for UNIX clients if your willing to throw security out the window. When doing a restore via NDMP, the destination for the restore has to be on a filer. If your users need to be able to restore data from tape, pick another product. If you're willing to pull stuff off tape for them (the GUIs not bad, but not great either) occasionally, then you'll be ok. 4) Having one BudTool server control a directly connected 100 tape DLT400 jukebox, a 5 tape stacker connected to our F330, and a 5 tape stacker connected to our research departments number cruncher is pretty nifty. Having all the tape and file histories in one place is nice too. 5) BudTool has a utility called btcp which will copy all your most current backup requests (Lev 0s and all necessary incrementals) to a set of tapes for offsite storage. It doesn't just dd a bunch of tapes. Very nice. Unfortunately, btcp is a little brain-dead and tries to copy _all_ the requests to one set of tapes. If you have a couple hundred GB worth of backups, this can take a really long time. Again, a little shell script fixed this problem. All in all, I don't think I've ever been 100% satisfied with any software product. But BudTool gets the job done (with a little help). jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Investment Group All opinions expressed are my own, etc, etc...

1 0

reboot of TLU -> reboot of fileserver
by Menachem Kaiser 23 Apr '98

23 Apr '98

Hi, I wanted to check out the following issue that was brought up in one of the responses to my poll (still waiting for more replies): When a TLU (tape Library Unit) is directly attached to a fileserver, does every reboot of the TLU necesarily mean you must reboot the fileserver? OR Is this only specific to the TLU vendor ( as suggested below). I see this as a serious issue!! I don't want the uptime of my fileserver to be affected by something like this. Manny Kaiser Email : mannyk(a)msil.sps.mot.com Unix System Administrator Phone : 972-9-9522-603 Motorola Semiconductor Israel LTD. Fax : 972-9-9562-990 1 Shenkar St. Industrial Zone Herzelia Herzelia 46120 Israel ============================================================================= ----- Begin Included Message ----- >From alexei(a)cancerman.cimedia.com Thu Apr 23 07:31:50 1998 >Received: from cancerman.cimedia.com (nat-a-29.cimedia.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA22939 for mannyk(a)msil.sps.mot.com; Wed, 22 Apr 98 21:26:58 MST To: Menachem Kaiser (Manny) <mannyk(a)msil.sps.mot.com> Subject: Re: backup and Restore questions Date: Thu, 23 Apr 1998 00:27:08 -0400 From: Alexei Rodriguez <alexei(a)cimedia.com> +--- In a previous state of mind, Menachem (Manny) Kaiser <mannyk(a)msil.sps.mo t.com> wrote: | | First many thanks for participating in this poll. No problem. My pleasure. | Why do you backup using only one stream of data. Actually, that may not be accurate. I think we break all the file systems into chunks and work on single chunks at a time. The main reason that we run a single stream (I need to verify) is that with one drive we did not gain too much. That may be incorrect. | Is this just a problem with your backup software? Don't know. I'll have to ask the backup person. Might be related to our installation. | You mentioned a very interesting note - attaching a jukebox | to the fileserver might mean that you will need to reboot the file | server from time to time. WHY? | When you reboot the tape library juke box - does this force | you to reboot the file server as well? If the stacker/jukebox hangs for whatever reason (robotic arm, etc), and you need to power-cycle the tape device, you cannot do so with the filer on. You run the risk of frying the scsi bus. Now, it could be that the problems I had were related to the specific DLT stacker (an ADIC vls library) we used. I don't know. I have not risked that sort of problem any more. Alexei ----- End Included Message -----

2 1

Re: backup times
by Mark D Simmons 23 Apr '98

23 Apr '98

> On 22 Apr 1998, Mark D Simmons wrote: > > -> > On Mon, 20 Apr 1998, Stephen Manley wrote: > -> > <Old thread stuff snipped> ... > expensive. Going the other route and putting, say, a DLT7000 on each > filer is also nuts. Cost for one of those around here (toronto, > ontario, canada) is something like $12500 plus the cost of a tape > monkey to run around and change tapes daily. We have all the above. It's not prohibitively expensive. The cost of the tape-monkey is amortised over the 100's of other systems he also tends. Don't forget the media costs 300quid/night for a 6dayx13 wk cycle... about 4 times the tape drive cost itself. > > BTW, my english parser keeps croaking over that CIFS statement.. Are > you referring to the lost of CIFS-specific file information by doing, > say, tar's over an NFS mount? If so, why? Doing a netapp-hosted dump > pointing at a remote box with rmt and a tape drive perserves all CIFS > specific information, afaik. Yeees, point, CIFS isn't an obstacle. > > > Why 1000mb ethernet? I'm not sure what filer and tape hardware > you have, but you think you need 128MByte/second throughput??!? In my dreams. As I've said before though, in utter seriousness I *do* want to be able to back up 400GB in about 6 hours. 400GB is 6 hours is 19MB/s sustained. Only atm and Gb-ether can provide that over the network. Locally two F/W SCSI channels will provide it happily. So... > <lots of good case material snipped> Seems like it's just a case of different strokes. > > ------------------------------------------------------------- > Dave Cole (DC1110) | dacole(a)netcom.ca > Systems Administrator | dacole(a)vex.net > | office/~dacole/ > Netcom Canada | www.vex.net/~dacole/ > 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 > Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 >

1 0

Re: reboot of TLU -> reboot of fileserver
by sirbruce＠ix.netcom.com 23 Apr '98

23 Apr '98

On 04/23/98 08:31:55 you wrote: > >Hi, > >I wanted to check out the following issue that was brought up in >one of the responses to my poll (still waiting for more replies): > >When a TLU (tape Library Unit) is directly attached to a fileserver, >does every reboot of the TLU necesarily mean you must reboot the fileserver? No, it doesn't. At least with the TLUs I've used (Quantum DLT-4700, Breece Hill) a reboot of the filer was not necessary if the TLU was power-cycled. However, there was rarely any need the power cycle the TLU in the first place. Note that you can't properly "hot swap" a tape device on an off a filer, but I have seen it work before, although that's not properly supported and probably depends a lot of the specific filer, tape device, OS, and the phase of the moon. :) > >OR > >Is this only specific to the TLU vendor ( as suggested below). I think it's specific to that TLU vendor. >I see this as a serious issue!! >I don't want the uptime of my fileserver to be affected >by something like this. Understandable. I don't think it's different from any other backup server in this regard. >| You mentioned a very interesting note - attaching a jukebox >| to the fileserver might mean that you will need to reboot the file >| server from time to time. WHY? >| When you reboot the tape library juke box - does this force >| you to reboot the file server as well? > >If the stacker/jukebox hangs for whatever reason (robotic arm, etc), >and you need to power-cycle the tape device, you cannot do so with >the filer on. You run the risk of frying the scsi bus. I find this difficult to believe, considering the SCSI bus has to deal with, for example, the power supply on shelf suddenly failing, or the power supply of the stacker itself, etc. If one considers the case of a short power outage, you can't control wheter the filer or the stacker will get power first when it comes back on, so sometimes the filer will be on first. Surely equipment is robust enough to support this. >Now, it could be that the problems I had were related to the specific >DLT stacker (an ADIC vls library) we used. I don't know. I have not >risked that sort of problem any more. The risk, if there is one, would have to be very small. No more than the risk for any other incident relating to power, and the number of SCSI busses fried in those instances must be small. If you have a stacker that is hanging frequently, you're much better off worrying about fixing the stacker's hanging than the small chance of a SCSI bus being fried if you power-cycle. See also my earlier comments about the filer possibly having to be rebooted if you can't abort a dump/restore that was in progress when the stacker hung. But that is a software issue, not a hardware problem. Bruce

1 0

Budtool to backup netapp
by Alan Phoenix 22 Apr '98

22 Apr '98

Has anyone tried using Budtool to backup a netapp? Al

2 1

subscribe
by David West 22 Apr '98

22 Apr '98

1 0

Re: Restoring A LOT from snapshot
by sirbruce＠ix.netcom.com 22 Apr '98

22 Apr '98

On 04/22/98 09:37:47 you wrote: > >In message <199804221400.KAA21557(a)prospero.dma.isg.mot.com>, Christoph Doerbeck > writes: >> Solution 1: use 'find' and 'cpio' and transfer all the data back. this >> would appear to require 2x current capacity of the filer to replicate >> all data out of snapshot. if you're using >50%, this method would >> fail. > >If the files in question have been removed, rather than modified, this >will only copy the files that have been removed. On other files, it >will either refuse to copy because it thinks its copying a file onto >itself. It will complain the whole while (slowing things down), but it >will only add the space consumed by the deleted files. At least that's >what happened when I tried it in my home directory. An interesting observation. One example where having the snapshot FSID the same as the filesystem FSID is actually an advantage. :) Bruce

1 0

Restoring A LOT from snapshot
by Christoph Doerbeck 22 Apr '98

22 Apr '98

Question: When restoring from snapshot, is there a method which will not recreate data in the real data area. Example: Random files are removed throughout the filer. We decide to backtrack to Mondays snapshot. We plan to copy everything out of snapshot back to the real data area. Solution 1: use 'find' and 'cpio' and transfer all the data back. this would appear to require 2x current capacity of the filer to replicate all data out of snapshot. if you're using >50%, this method would fail. Solution 2: use 'find' and 'diff' and 'cpio' to enhance solution 1 with a check. Now only files which differ from the snapshot will be replaced. Solution 3: dump the snapshot to tape, and then restore from tape after removing existing snapshots. Solution 4: boot from floppy, use prev_cp and wack? Has anyone had any experience with 'prev_cp' and 'wack'? We're leaning at #4. Any comments would greatly be appreciated! ######################################## # Christoph Doerbeck # Motorola ISG # email: doerbeck(a)dma.isg.mot.com

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters