toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

restore from dlt is failing
by Dave Toal 22 Jul '99

22 Jul '99

Folks, I've got Veritas NetBackup 3.1.1 running its NDMP extension, controlling full and incremental backups on a netapp running OnTap 5.2.1, using nrst0a as the dump device -- direct connection from the netapp to a DLT7000. I'm trying to do a restore from tapes where the netbackup images have expired. (I did a "phase 1 import" which reads image headers, so I know which files I'd like off the tape; "phase 2 import" which reads files and rebuilds netbackup database info is failing -- this may be a separate issue.) The correct tape is loaded in the dlt. I'm seeing "RESTORE: Could not initialize media." inbox1> mt -f nrst0a rewind inbox1> mt -f nrst0a status Tape drive: Digital DLT7000 Status: ready, write enabled Format: 85937 bpi 70 GB (w/comp) fileno = 0 blockno = 0 resid = 0 inbox1> mt -f nrst0a rewind inbox1> restore tvf nrst0a b 1 s 33 RESTORE: Tape Block size should be 1024, not 64512. RESTORE: Could not initialize media. inbox1> mt -f nrst0a rewind inbox1> restore tvf nrst0a s33 RESTORE: Tape Block size should be 1024, not 64512. RESTORE: Could not initialize media. inbox1> mt -f nrst0a status Tape drive: Digital DLT7000 Status: ready, write enabled Format: 85937 bpi 70 GB (w/comp) fileno = 0 blockno = 1 resid = 31744 inbox1> Any ideas or suggestions? Dave Toal Thomson & Thomson

2 1

Shelf2 SCSI Drives
by John Tatar 22 Jul '99

22 Jul '99

Does anyone know where I can get shelf2 SCSI drives? I didn't realize when Netapp announced that they were discontinuing some products that they were discontinuing their entire line of SCSI products. Now I can't add disks to the shelf2 that I bought partially filled with disks last year. TIA JT -- =================================================================== John J. Tatar Systems & Network Engineering Section Advanced Computer Applications Group Decision & Information Sciences Division Argonne National Laboratory mailto:tatar@dis.anl.gov or john(a)tatar.com Office: 630-252-3242 Fax: 630-252-5128 Pager: 630-266-1063 ===================================================================

1 0

Budtool
by Jay Orr 22 Jul '99

22 Jul '99

A little off subject, has anyone that uses budtool gotten the 4.6.1 upgrade yet? I tried to use the documentation CD and found it had all windows filenames (i.e. blah~1.htm instead of blahblah.htm) and I couldn't use their web based docs and all their subdirectories and files were messed up the same way so it's a pain to even find the .pdf or .ps files I need. I called them up and they told me I MUST be doing something wrong, and they'll send me another CD. Well, the CD is the same, it's just they presume everyone has access to a PC (I don't), which I thought was quite rude. Anyone else run into this? Is there a way to translate the windows long/short filenames into regular long filenames for unix (we're running Solaris 2.5.1)? Ovbiously they don't believe in ISO9660 CD formats... Nice to see our money is going to such a caring comany.... ----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517

2 1

RE: Non-NDMP backup solutions?
by Melvin, Grant 22 Jul '99

22 Jul '99

Hi Shaun, Sorry to see that you've "switched away from NDMP", since this is the strategic direction for backups at Network Appliance. I understand your pain though and there's no doubting that we did have issues in our implementation of the NDMP server within the filer. About 8 or 9 months ago we made a concerted effort to resolve these issues and work harder at syncing up with 3rd party backup management software vendors so that their certification efforts would produce solid product solutions as close to our FCS dates as possible. I believe this effort has paid off and that we have fixed our issues in 5.2.*. For 5.3 we ported the NDMP server to run in the Java Virtual Machine & support V3. Results so far have shown some bugs, reported on toasters, but these have been fixed and we have a very stable product. Regarding certification Legato, Veritas & CommVault are all currently testing our 5.2.3 & 5.3.2 maintenance releases, so we seemed to have closed this loop too. > Lastly, we find that backing up a filer to it's local tape drive to be > substantially slower than backing it up across the net to our SGI Origin > 2000 media server. Not only is it faster, it puts less of a load on the > filer as well. If backing up "over the wire" is faster for you then go for it, especially if it puts less load on the filer. I'd be interested in sysstat output for both solutions. We currently recommend that customers use the DLT 7000 where possible since its much faster than the DLT 4000, so a lot of our data is based on writing to the DLT 7000. > I had a DLT4000 drive attached to my filers (an F540 & an F330) and was > backing them up via NDMP with BudTool. When I replaced the F540 with an > F740, I couldn't move the tape over, as F740 had a different SCSI setup, > so we bagan backing it up across a dedicated 100Mb FD link to our SGI > Origin 2000. We found it to be substantially faster than what the F540 > could do to tape, and it got rid of the NDMP hassles. Mind you, we are > not backing it up over NFS, but using BudTool's dump.NetApp class with > NDMP turned off on the filer, so we're still using the filer's dump and > restore, which means we don't lose any ACLs. If BudTool is using the dump.NetApp class then you *are* still using NDMP, but instead of directing the backup stream to local tape, its going out a socket to your SGI Origin system. Writing to the network can yield a better throughput than writing to a DLT 4000, so perhaps the SGI Origin is able to stream to a DLT 4000 faster. > Yesterday, after upgrading it to 5.2.2P1, I tried backing my F330 up > across the network in the same manner as my F740, and found it to be > incredibly faster. It takes BudTool, via NDMP, to a local drive, 16+ > hours to back up a 12GB directory, but I can back it up, using the same > dump and restore, over the net to my SGI, in 1 hour and 43 minutes. The > SGI is writing the data to yet another DLT4000, so it would appear that > the filers are the bottleneck - that they write to tape horribly slow. > So, I don't think I want to do that any more - not when flinging it > across my net gives me such a huge speed up. This is good info & I agree with your analysis that somehow the data path to a DLT 4000 on a SGI Origin seems to be faster than a locally attached DLT 4000. Cheers, Grant =========== grant(a)netapp.com ========== Grant Melvin === === Mgr, FS Recovery Group === === Network Appliance === |\ | __ ___ /\ __ __ === 495 East Java Drive === | \ | |__ | /__\ |__| |__| === Sunnyvale === | \| |__ | / \ | | (R) === California === === 94089 === === Tel:(408)822-6761 =========== Network Appliance ========== Fax:(408)822-4457/4525/4559 -----Original Message----- From: Shaun T. Erickson [mailto:ste@research.bell-labs.com] Sent: Tuesday, July 20, 1999 5:49 AM To: 'toasters(a)mathworks.com' Subject: Non-NDMP backup solutions? I keep hearing about backup alternatives that use NDMP. What solutions are there if you *don't* want to use NDMP? We have several reasons for not wanting to use it. We have had nothing but grief because we relied on using NDMP. First, NetApp's implementation had a memory leak that caused backup's to fail after the filer had been up for a month and, if not caught quickly & the filer rebooted, would cause NFS to get flaky, in that it would respond to some requests and ignore others, getting progressively worse until the filer would crash. As a result, we had to reboot the filer on a monthly basis. This lasted for over a year, during which time we were repeatedly told to upgrade to the latest version of Ontap, because it was always supposedly fixed in that release. Because of the frequent upgrades, (which continue to happen, but for other reasons) we frequently ran into problems because of incompatibilities between NetApp's implementation of NDMP and BudTool's. Then, when we'd try to get support, we were always told that the version of Ontap we were running wasn't certified with BudTool, so it was always a major pain to get support. To be fair, BudTool broke NDMP on occasion, as well, with their upgrades. The end result was the same, however. Lastly, we find that backing up a filer to it's local tape drive to be substantially slower than backing it up across the net to our SGI Origin 2000 media server. Not only is it faster, it puts less of a load on the filer as well. So, having switched away from NDMP, for the above reasons, I have no burning desire to switch back, and am looking for backup solutions that do not require it. Although not the scope of this list, I need to back up Sun Solaris, IRIX & NT systems, as well. What is there available? -ste -- Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (908) 672-6456

3 2

Clustered Takeover Time
by Jeffrey Skelton 22 Jul '99

22 Jul '99

If I have a clustered pair of 760s, how long does it take for one to take over in the event of a failure of the other? Thanks. --jeff

2 2

RE: Netgroups
by Mohler, Jeff 22 Jul '99

22 Jul '99

I didnt vi edit the file, just forgot the - in the message.. BUT..I found why it did not load. A host in the group was not resolving right, and Ive let the group know who is responsible for it..know. -----Original Message----- From: Gordon Keegan [mailto:lgk011@dma.isg.mot.com] Sent: Thursday, July 22, 1999 9:11 AM To: Mohler, Jeff Cc: toasters(a)mathworks.com Subject: Re: Netgroups > Ive defined some large netgroups to save me some brain twisting in my > /etc/exports file on my 760. > > /vol/volx access=Netgroup > That's basically the syntax that works for us. You may need to do something like: /vol/volx -access=Netgroup (leading "-" in front of list of export options) -- Gordon Keegan, M10-10 Phone: (508) 261-4696 Motorola ING Fax: (508) 261-5757 20 Cabot Boulevard Mansfield, MA 02048 email: lgk011(a)dma.isg.mot.com

1 0

Netgroups
by Mohler, Jeff 22 Jul '99

22 Jul '99

Ive defined some large netgroups to save me some brain twisting in my /etc/exports file on my 760. /vol/volx access=Netgroup Should export to that volume all hosts in group Netgroup...yes? Its not likin what im typin.

2 1

RE: Non-NDMP backup solutions?
by sirbruce＠ix.netcom.com 22 Jul '99

22 Jul '99

On 07/20/99 15:48:35 you wrote: > Sorry to see that you've "switched away from NDMP", > since this is the strategic direction for backups > at Network Appliance. Network Appliance better figure out real quick that NDMP should remain solely *a* strategic direction for backups, not *the* strategic direction. Support for it is still in the early stages and a new standard could come along tomorrow that everyone will want to start using. Too much focus on NDMP will alienate customers and prevent important resources from being allocated to the support and software for other backup strategies, as has happened in the past. I don't mean to jump on your personally if you simply misspoke, Grant, but I think the point had to be made. Bruce

1 0

RE: Non-NDMP backup solutions?
by Benn, Paul 22 Jul '99

22 Jul '99

> Anyone know if the two DLT4000's in a Breece Hill Q7 can be replaced > with two DLT7000's? That would speed things up even further for me. I > suppose I'll have to give Breece Hill a call ... In a past life, I was able to upgrade two of our Q2-15's to DLT-7000. The drives came complete with drive trays making for a painless upgrade. Your reseller should be able to get the drives for you. You may have to get the part numbers form Breece Hill, though. Good Luck Paul Benn Network Appliance

1 0

RE: Clustered Takeover Time
by Watanabe, Steven 21 Jul '99

21 Jul '99

The amount of time can be broken down into two components. First is the failure detection time, currently 60 seconds, which is the amount of time before one node declares the other one down. Secondly is the resource takeover time, the amount of time that it takes to bring the partner's resources online. These include disks, networking, replaying the logs, starting the services for the partner (e.g. cifs). This amount of time is variable based on the load of the node doing the takeover and the configurations/resources of the down node. We are working actively to decrease both of these times in a future release. Steve Watanabe NetApp Cluster Group > -----Original Message----- > From: Jeffrey Skelton [mailto:jss@NET2PHONE.COM] > Sent: Wednesday, July 21, 1999 1:07 PM > To: toasters(a)mathworks.com > Subject: Clustered Takeover Time > > > > If I have a clustered pair of 760s, how long does > it take for one to take over in the event of a > failure of the other? > > Thanks. > --jeff >

1 0

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